Мы хотели бы использовать проверку работоспособности TCP на порту 21 для аварийного переключения Route 53 пары FTP-серверов, работающих на экземплярах EC2 с эластичными IP-адресами.
Проблема в том, что у нас есть FTP-серверы в группе безопасности, которая разрешает соединения только из небольшого белого списка блоков CIDR (FTP - это плохо, но широко открытый FTP - это страшно).
Группа безопасности блокирует подключения от средств проверки работоспособности Route 53. Я знаю, что есть способы опросить текущий список средств проверки работоспособности, и теоретически вы могли бы соответствующим образом обновить свою группу безопасности, но это кажется довольно хакерским.
Поэтому я даже попытался создать небольшую страницу статуса HTTP через PHP, которая будет подключаться к порту 21 (и теоретически может даже передать файл, чтобы убедиться, что все работает). Я подумал, что могу сделать так, чтобы Route 53 попал на эту страницу статуса (которая, к сожалению, должна быть открыта для всего мира, но это все же лучше, чем оставлять FTP-сервер полностью открытым).
Поскольку я не знаю IP-адрес экземпляра EC2 заранее, я настраиваю группу безопасности, чтобы разрешить соединения со всех хостов в группе безопасности.
Но, очевидно, если вы попытаетесь подключиться к эластичному IP-адресу, настройки группы безопасности не будут преобразованы (что имеет смысл, но это выбивает мой подход из окна).
Так что идеи у меня заканчиваются. У кого-нибудь есть хорошие подходы для решения общей проблемы проверки работоспособности TCP на экземпляре, который ограничивает доступ блоком CIDR?
Отслеживание истории AWS опубликовал диапазоны IP-адресов с 2015-07 (самый ранний снимок, который у меня есть в системе, которую я запрашивал ниже) по 2017-03 (последний, который у меня есть) - за период более полутора лет - вы обнаружите, что было ровно нулевые изменения в диапазоны адресов IPv4 для средств проверки работоспособности Route 53.
Белый список их в вашей группе безопасности кажется вполне разумной стратегией.
Есть два небольших блока адресов IPv4, выделенных для проведения проверок работоспособности, в каждой из 8 областей, из которых Route 53 может проверять источники. (Route 53 не отправляет проверки из всех регионов AWS).
Для каждого региона, который тестирует вашу конечную точку (по умолчанию все они тестируют вашу конечную точку), ваша проверка работоспособности будет связана с одной проверкой в каждом блоке из каждого региона ... и когда вы посмотрите на «Проверки работоспособности» в консоли вы можете увидеть результаты, сообщаемые чекерами по отдельности, включая IP-адрес чекера (который, конечно же, будет отображаться в журналах сервера).
Это выдержка из соответствующих значений:
+-------------------+----------------+
| ip_prefix | region |
+-------------------+----------------+
| 54.183.255.128/26 | us-west-1 |
| 54.228.16.0/26 | eu-west-1 |
| 54.232.40.64/26 | sa-east-1 |
| 54.241.32.64/26 | us-west-1 |
| 54.243.31.192/26 | us-east-1 |
| 54.244.52.192/26 | us-west-2 |
| 54.245.168.0/26 | us-west-2 |
| 54.248.220.0/26 | ap-northeast-1 |
| 54.250.253.192/26 | ap-northeast-1 |
| 54.251.31.128/26 | ap-southeast-1 |
| 54.252.79.128/26 | ap-southeast-2 |
| 54.252.254.192/26 | ap-southeast-2 |
| 54.255.254.192/26 | ap-southeast-1 |
| 107.23.255.0/26 | us-east-1 |
| 176.34.159.192/26 | eu-west-1 |
| 177.71.207.128/26 | sa-east-1 |
+-------------------+----------------+
У меня не было причин отслеживать сторону IPv6, поэтому я не могу однозначно сказать, что то же самое верно, но само собой разумеется, что такая же ситуация будет применяться и там.
Вы также можете использовать такую службу, как dyn-dns, для предоставления статических имен динамическим адресам. Каждый раз, когда хост активируется на новом IP-адресе, агент, запущенный в сеансе, обновляет сервер dyn-DNS с правильным динамическим адресом.
Мы обнаружили, что это увеличивает скорость повторного подключения некоторых из наших отображений конечных точек vpn.