☰

Проблема iptables NAT с соединениями, включающими пакеты RST

tag-icon • tag-icon linux vpn iptables nat
Проблема iptables NAT с соединениями, включающими пакеты RST

У меня есть установка, которая выглядит примерно так.

Приложение > Локальный сервер > VPN > Удаленный VPN-сервер > Сервер лицензий

Приложение и локальный сервер находятся в моей локальной сети. Локальный сервер подключается через VPN к корпоративному VPN-серверу, и именно так локальный сервер может видеть корпоративный сервер лицензий.

Я указываю своему приложению найти лицензию на моем локальном сервере и добавляю следующие правила iptables на мой локальный сервер.

iptables -F
iptables -t nat -F
iptables -X

licServer=$(host licserver | awk '/has address/ { print $4 ; exit }')
iptables -t nat -A PREROUTING -p tcp --dport 1642 -j DNAT --to-destination $licServer:1642
iptables -t nat -A PREROUTING -p tcp --dport 57109 -j DNAT --to-destination $licServer:57109

iptables -t nat -A POSTROUTING -j MASQUERADE

Кажется, это работает, и приложение успешно получит лицензию. Однако переговоры идут очень медленно по сравнению с локальной сессией (которая не использует мои правила).

Если я посмотрю на wireshark, то увижу, что приложение отправляет какие-то необычные сообщения. Пакеты FIN никогда не отправляются, вместо этого приложение отправляет пакеты RST. Я заметил, что каждый раз, когда оно отправляет один из этих пакетов RST, происходит почти точное 10-секундное ожидание перед отправкой следующего сообщения. Я не думаю, что это совпадение, поскольку тайм-аут CLOSE_WAIT составляет 10 секунд.

Типичные переговоры начинаются примерно так:

t=0 Application:A > Local Server:1642 [SYN]
t+0.1 Local Server:1642 > Application:A [SYN, ACK]
t+0.1 Application:A > Local Server:1642 [ACK]
t+0.1 Application:A > Local Server:1642 [PSH, ACK]
t+0.2 Local Server:1642 > Application:A [PSH, ACK]
t+0.2 Application:A > Local Server:1642 [RST, ACK]   (10 second wait here)
t+10.2 Application:B > Local Server:57109 [SYN]

... и т. д. Всякий раз, когда есть RST, он ждет еще 10 секунд.

Если приложение является локальным по отношению к серверу лицензий, отправляются те же сообщения, но 10-секундная задержка после отправки пакета [RST, ACK] отсутствует.

Поэтому у меня вопрос: что делает NAT на моем сервере, что может привести к зависанию моего приложения на 10 секунд после отправки пакета RST?

решение1

Ничего страшного, оказалось, что проблема была совершенно не связана с NAT.

Сервер лицензий отправлял свое собственное имя хоста как часть полезной нагрузки предыдущего пакета. Очевидно, что это имя хоста было недоступно для приложения, поэтому 10 секунд берутся из какого-то тайм-аута в приложении. Я предполагаю, что он пробует имя хоста, затем через 10 секунд пробует первый адрес, который у него был (в конечном итоге так это и работает).

После того, как я добавил имя хоста сервера лицензий в файл hosts на клиентской машине, все заработало.

Чувствую себя королевским идиотом. Спасибо всем, кто посмотрел.

Связанный контент