Извините, если заголовок и теги немного расплывчаты, я пока не могу определить правильные термины для этого. Посоветуйте, пожалуйста, и я его изменю.
Я реализую сервер STUN, упакованный в контейнер Docker, который размещен на Kubernetes Google Container Engine. В проекте используются балансировщики нагрузки (правила пересылки на GCE) для отправки внешних запросов на соответствующие порты в модуле / контейнере,
Я перенаправил весь трафик, поступающий в eth0, на 2 виртуальных интерфейса (eth0: 1, eth0: 2) через:
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 61214 -j DNAT --to-destination 172.26.0.6
(для полноты картины второй пункт назначения - 172.26.0.7)
Клиентское приложение без проблем доходит до него, и определение NAT продолжается. Это, однако, резко останавливается, когда серверу STUN необходимо создать сокет и вернуться к клиентскому приложению, поскольку полученный исходный IP-адрес является внутренним IP-адресом экземпляра виртуальной машины хоста в Kubernetes (например, 10.128.0.4). Поскольку соединение не было установлено, время ожидания сокетов клиента и сервера истекает.
Есть ли способ сохранить фактический адрес источника до тех пор, пока он не достигнет моего серверного приложения? Я готов отказаться от текущей настройки, если мой запрос достигнет сервера и сервер сможет установить обратное соединение с клиентом.
Спасибо.
Я рад узнать, что это один из тех редких случаев в нашей работе, когда решение существует, и был предоставлен своевременно (т.е. только что стал бета-версией).
К сожалению, это относится только к нашему контексту, то есть Kubernetes по GCE / GKE. На момент написания этой статьи пользователям других платформ (например, AWS) потребуется использовать другие решения.