TCP-трафик на порт 1433 заблокирован правилами NAT
У нас есть SQL-сервер, размещенный на AWS, SQL-сервер, к которому нет прямого доступа в Интернете, он использует блок NAT для маршрутизации трафика к нему.
Мы пытаемся настроить связанный SQL-сервер с этого сервера на другой за пределами AWS, для этого требуется, чтобы два SQL-сервера общались друг с другом через порт 1433 TCP.
Соответствующие разделы из iptable выглядят так:
целевой источник дохода назначение
DNAT udp в любом месте udp dpt: ms-sql-m to: 172.10.10.10: 1434
DNAT tcp в любом месте где угодно tcp dpt: ms-sql-s to: 172.10.10.10: 1433
Из нашего собственного тестирования мы знаем, что можем связать любой сервер с сервером на AWS, но не наоборот.
Что-то не так? Проблема начала возникать, когда наш инженер Intfra «удалил и добавил им те же правила». Есть ли в этом какие-то зацепки? Релевантен ли порядок?
С помощью tracetcp мы обнаружили следующее:
Выполнение этой команды на сервере aws sql 'tracetcp.exe 183.23.53.22 1433', где IP-адрес другого сервера, размещенного на внешнем сервере, приведет к достижению пункта назначения за 1 переход, но он также будет делать то же самое независимо от любых случайных ip адрес мы пробовали.
Где, как если бы мы выполняли ту же команду, но на другом порту, отличном от 1433, он сначала попадал в поле NAT, а затем выполнял много переходов
Возможно, у вас есть работающий прокси-сервер на порту 1433, который может вызвать поведение, подобное описанному вами. Прокси-сервер сразу же принимает соединение с внутренней машиной, поэтому вы получаете такой короткий ответ в 2 мс.
Также хорошим индикатором того, что ваши пакеты не покидали вашу локальную сеть, является такое короткое время ответа (1-4 мс). Попробуйте установить флажок NAT, если вы случайно запустили какой-либо прокси-процесс, а если нет, попробуйте отключить правило DNAT для порта 1433 (tcp), чтобы проверить, сохраняется ли проблема.
Кроме того, это утверждение «не доступен напрямую в Интернете, он полагается на блок NAT для маршрутизации трафика к нему» противоречит, поскольку машина доступна в Интернете, но через определенный порт, через который выполняется преобразование NAT. , право?
Если вы действительно хотите защитить свой сервис от внешнего мира, может быть, было бы разумно подумать о какой-то VPN? Или, если вам нужно более простое решение (но не такое безопасное, как VPN), вы можете просто разрешить доступ к этому NAT-порту с известного удаленного IP-адреса (который злоумышленник может в некоторых случаях подделать).
Проверьте свои правила iptables с помощью iptables-save и повторно разместите их. Убедитесь, что в ваших правилах DNAT есть метод исключения трафика, исходящего изнутри сети, например -i <extif>, ! -i <intif>, или ! -s 172.10.10.10. Я сильно подозреваю, что он повторно отправляет ваши пакеты обратно на внутренний сервер-источник.