Приложение AWS Proxy Protocol v2, нарушающее работу приложения из-за отсутствия флага PSH
У меня есть сетевое приложение, созданное с использованием Netty. Приложение стоит за балансировщиком сетевой нагрузки Amazon.
Теперь я хочу получить исходный IP-адрес клиента, поэтому я включил параметр Proxy Protocol v2 в балансировщике сетевой нагрузки.
К сожалению, это нарушает работу приложения.
С приложением можно взаимодействовать через терминал, используя что-то вроде nc или telnet.
При подключении к приложению пользователь обычно получает приветственное сообщение, а затем приглашение ввести запрос для взаимодействия с приложением.
Когда протокол Proxy Protocol v2 включен, при подключении приветственное сообщение больше не записывается клиенту, вместо этого клиент видит что-то вроде этого:
telnet -4 app.host 43
Trying <IP ADDRESS>...
Connected to some_network_lb.elb.eu-west-1.amazonaws.com.
Escape character is '^]'.
захватив сетевой пакет, я заметил разницу между отключением прокси-протокола v2 (приложение работает нормально) и включенным (приложение не работает нормально)
Когда протокол Proxy v2 выключен, взаимодействие пакетов можно резюмировать следующим образом:
No. Time Source Destination Protocol Length Info port
1 0.000000 SOURCE-IP DEST-IP TCP 78 57059 → 43 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1158853985 TSecr=0 SACK_PERM=1 43
No. Time Source Destination Protocol Length Info port
2 0.034526 DEST-IP SOURCE-IP TCP 74 43 → 57059 [SYN, ACK] Seq=0 Ack=1 Win=26847 Len=0 MSS=1420 SACK_PERM=1 TSval=3185991482 TSecr=1158853985 WS=128 57059
No. Time Source Destination Protocol Length Info port
3 0.034556 SOURCE-IP DEST-IP TCP 66 57059 → 43 [ACK] Seq=1 Ack=1 Win=132352 Len=0 TSval=1158854019 TSecr=3185991482 43
No. Time Source Destination Protocol Length Info port
4 0.067278 DEST-IP SOURCE-IP TCP 264 43 → 57059 [PSH, ACK] Seq=1 Ack=1 Win=26880 Len=198 TSval=3185991515 TSecr=1158854019 [TCP segment of a reassembled PDU] 57059
No. Time Source Destination Protocol Length Info port
5 0.067301 SOURCE-IP DEST-IP TCP 66 57059 → 43 [ACK] Seq=1 Ack=199 Win=132096 Len=0 TSval=1158854051 TSecr=3185991515 43
А когда включен протокол Proxy v2, взаимодействие пакетов можно резюмировать следующим образом:
No. Time Source Destination Protocol Length Info port
1 0.000000 SOURCE-IP DEST-IP TCP 78 55871 → 43 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1158086997 TSecr=0 SACK_PERM=1 43
No. Time Source Destination Protocol Length Info port
2 0.040204 DEST-IP SOURCE-IP TCP 74 43 → 55871 [SYN, ACK] Seq=0 Ack=1 Win=26847 Len=0 MSS=1420 SACK_PERM=1 TSval=3185217396 TSecr=1158086997 WS=128 55871
No. Time Source Destination Protocol Length Info port
3 0.040227 SOURCE-IP DEST-IP TCP 66 55871 → 43 [ACK] Seq=1 Ack=1 Win=132352 Len=0 TSval=1158087035 TSecr=3185217396 43
Как видно выше, когда включен протокол прокси v2, обмен пакетами останавливается на третьем обмене, и сервер никогда не отправляет 4-й обмен пакетами, который содержит, когда протокол прокси v2 выключен.
Есть идеи, почему это происходит? Почему так, пакет с
1 ответ
Нам пришлось обратиться в службу поддержки AWS, чтобы помочь установить атрибут целевой группы.
proxy_protocol_v2.client_to_server.header_placement to on_first_ack в целевой группе NLB.
Для нас это было связано с характером нашего приложения, в котором данные не отправляются от клиента после того, как соединение установлено, и это не работает из коробки, потому что заголовки помещаются лениво.
Вы можете прочитать эту ссылку для получения дополнительной информации об этом поведении