А проблема как раз в том, что тут терминология важна как никогда. Если бы у вас была маска /16, то серверы фактически должны видеть друг друга без помощи маршрутизатора и настраивать никакие маршруты не нужно. Если бы была маска /24 (например), то нужно использовать маршрутизатор. В большинстве случаев это обслуживает тот же маршрутизатор по умолчанию, и тогда никаких дополнительных маршрутор настраивать не нужно. Но если в вашем DC это не машрутизатор по умполчанию, то адрес нужного вам маршрутизатора здесь никто не придумает.
Элементарно достать, значит, что если у вас есть строковая константа в исходнике флеша, то она будет и в .swf файле. Если генерируете пароль программно — никаких проблем, запускаем декомпилятор флеша и реверсим ваш алгоритм.
Вот именно, только в случае когда любой запрос, который можно сделать через ваш флешевый интерфейс к mysql вернёт только общедоступные данные, только тогда это можно делать.
Если что-то делает ваша программа на флеше, моя может делать то же самое. Это значит, что если ваша может аутентифицироваться, то сможет и моя. Потому что у меня, на клиентской стороне будут все необходимые для этого данные. Пароль? Хеш пароля? Они же в флеш-ролике будут зашиты! Их оттуда можно элементарно достать. Любая аутентификация будет сломана, так как программа выполняется у меня на компьютере под моим контролем и все данные (пароли, хеши) тоже находятся у меня. Попробуйте предложите такую схему, которую выполнит флеш, но не выполню я.
Даже если у вас сольют базу без паролей, это всё равно очень плохо. Например, на форуме тогда можно читать чужие личные сообщения. Или например, если уметь делать произвольные запросы к базе онлайн игры, то игроки смогут узнать те игровые величины и параметры, которые позволят им играть нечестно. Например, координаты сооружений других игроков или неисследованую часть карты.
Запрос GET или POST тоже можно подделать. Но ведь обработчики этих запросов рассчитаны на то, чтобы отсекать плохие входные данные, верно? И реализовать эти проверки довольно просто, так как формат запроса GET или POST довольно простой и диктуется семантикой запрашиваемого действия. А если пытаться фильтровать произвольные SQL запросы, то придётся для начала написать полноценный парсер SQL, а потом очень много логики собственно для анализа. Даже пусть вы напишете парсер, что дальше? Что искать в запросе, чтобы определить, что он плохой? Как узнать, что это именно игрок пытается играть нечестно, а не эти данные нужны логике вашего флеша? В результате вы придёте к набору шаблонов запросов, которые может отправлять ваш флеш. А если есть готовые шаблоны, то проще со стороны сервера просто реализовать соответствующие API вызовы для выполнения этих разрешённых запросов по шаблонам.
Флеш плеер же с клиентской машины как-то отправляет (точнее не как-то, а как реализуете), значит и я смогу написать программу, которая делает то же самое. Аутентификация — туда же. Даже селекты могут навредить: можно слить базу.