DNAT у VPN контејнеру: прослеђивање, а не INPUT

Након DNAT-а захтев за адресу тунела постаје прослеђени саобраћај. Сузите правило прослеђивања, прочитајте Docker ланац и свесно изаберите повратни пут.

Захтев стиже адресиран на IP адресу тунела и напушта исти контејнер адресиран на суседну услугу. Између та два тренутка DNAT је преписао одредиште, и пакет је престао да буде улаз за VPN контејнер. Сада је то прослеђени саобраћај, о коме суди друго правило. Та промена објашњава зашто правило заштитног зида које изгледа исправно за адресу тунела нема ефекта на преведену везу.

Пратите пакет након превођења

Узмите скуп клијената 10.90.0.0/24 и адресу тунела 10.90.0.1. Два контејнера стоје на једном мосту: 192.0.2.2 покреће VPN, а 192.0.2.3 покреће апликацију. Клијент се повезује на 10.90.0.1:8080, и правило DNAT у простору имена VPN контејнера то преписује на стварну адресу и порт апликације. Затим рута шаље пакет преко моста. Те адресе су илустративне, нису рецепт за распоређивање.

Порт на ком апликација заиста слуша може се разликовати од било ког порта објављеног на хосту. Прочитајте слушаоца унутар контејнера уместо да претпоставите да се оба броја поклапају.

Дозвола припада путу прослеђивања

VPN контејнеру треба прослеђивање IP-а и одлука о прослеђивању ограничена на скуп клијената, адресу апликације и предвиђени порт. Успостављени одговори траже сопствену дозволу. Правило које одговара оригиналној адреси тунела неће одговарати након DNAT-а, јер се одредиште већ променило. Дозвола INPUT је погрешна кука за саобраћај који више није адресиран на овај хост.

Држите обим уским: један опсег извора, једно одредиште, једна услуга. Попустљиво правило прослеђивања лакше је написати и много теже касније бранити.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Docker ланци нису ланци вашег контејнера

Правила унутар простора имена контејнера нису правила Docker хоста. Када саобраћај пређе са интерфејса тунела на мост, заштитни зид моста на хосту може донети другу одлуку. Са iptables backend-ом Docker-а, документовани ланци прослеђивања и тачке подударања након DNAT-а место су где се та одлука појављује.

Docker референца за заштитни зид описује те ланце и подударање након DNAT-а. Не поправљајте недостајуће прихватање искључивањем Docker-овог управљања заштитним зидом или чинећи сваки ланац попустљивим, јер то уклања границу коју покушавате да користите.

Учините повратни пут свесним избором

Ако је изворна адреса сачувана, апликација види 10.90.0.x и мора да усмери одговоре назад кроз VPN контејнер. Иначе ће их њен уобичајени Docker гејтвеј послати на хост, који не поседује тунел. Алтернатива је уско ограничено превођење извора на VPN контејнеру, које поједностављује одговор али скрива клијента од апликације. Изаберите свесно и запишите коју сте опцију изабрали.

Тестирајте нову дозвољену везу са обичног клијента, затим потврдите да неповезани портови остају затворени. Када пакет нестане, прегледајте VPN простор имена, простор имена апликације и сопствени дневник апликације. Ping на гејтвеј моста није тест прихватања за услугу.

Држите правила у подржаној почетној конфигурацији контејнера, јер интерактивне измене нестају када се он поново направи. Објављивање порта на хосту је други пут излагања и није потребно само зато што је услуга доступна кроз тунел.

Повезани чланци