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 до портата на мостот не е тест за прифаќање на услугата.

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

Поврзани статии