DNAT sa container ng VPN: pagpapasa, hindi INPUT

Dumarating ang kahilingan na naka-address sa IP ng tunnel at lumalabas sa parehong container na naka-address sa karatig na serbisyo. Sa pagitan ng dalawang sandaling iyon binago ng DNAT ang destinasyon, at tumigil ang packet na maging input para sa container ng VPN. Ngayon ito ay ipinasang trapiko, hinuhusgahan ng ibang patakaran. Ipinapaliwanag ng pagbabagong iyon kung bakit walang epekto sa isinalin na koneksyon ang isang patakaran ng firewall na mukhang tama para sa address ng tunnel.

Sundan ang packet pagkatapos ng pagsasalin

Kumuha ng pool ng kliyente na 10.90.0.0/24 at address ng tunnel na 10.90.0.1. May dalawang container sa isang bridge: pinapatakbo ng 192.0.2.2 ang VPN at pinapatakbo ng 192.0.2.3 ang aplikasyon. Kumokonekta ang isang kliyente sa 10.90.0.1:8080, at isinusulat muli ng patakaran ng DNAT sa namespace ng container ng VPN iyon sa tunay na address at port ng aplikasyon. Pagkatapos ay ipinapadala ng isang ruta ang packet sa bridge. Ang mga address na iyon ay halimbawa lamang, hindi resipe ng deployment.

Ang port na talagang pinakikinggan ng aplikasyon ay maaaring iba sa anumang port na inilathala sa host. Basahin ang listener sa loob ng container sa halip na ipalagay na tugma ang dalawang numero.

Ang pahintulot ay nasa daan ng pagpapasa

Kailangan ng container ng VPN ang pagpapasa ng IP at desisyon sa pagpapasa na limitado sa pool ng kliyente, address ng aplikasyon at nilalayong port. Ang mga naitatag na tugon ay kailangan ng sarili nilang pahintulot. Ang patakarang tumutugma sa orihinal na address ng tunnel ay hindi tutugma pagkatapos ng DNAT, dahil nagbago na ang destinasyon. Ang pahintulot na INPUT ay maling sabitan para sa trapikong hindi na naka-address sa host na ito.

Panatilihing makitid ang saklaw: isang hanay ng pinagmulan, isang destinasyon, isang serbisyo. Ang maluwag na patakaran sa pagpapasa ay mas madaling isulat at mas mahirap ipagtanggol mamaya.

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

Ang mga chain ng Docker ay hindi ang mga chain ng iyong container

Ang mga patakaran sa loob ng namespace ng container ay hindi ang mga patakaran ng host ng Docker. Kapag tumatawid ang trapiko mula sa interface ng tunnel patungo sa bridge, maaaring gumawa ng ibang desisyon ang firewall ng bridge sa host. Sa backend na iptables ng Docker, ang mga nakadokumentong chain ng pagpapasa at ang mga punto ng pagtutugma pagkatapos ng DNAT ang lugar kung saan lumilitaw ang desisyong iyon.

Ang sanggunian ng firewall ng Docker ay naglalarawan ng mga chain na iyon at ng pagtutugma pagkatapos ng DNAT. Huwag ayusin ang kulang na pagtanggap sa pamamagitan ng pag-off ng pamamahala ng firewall ng Docker o paggawa ng bawat chain na maluwag, dahil inaalis nito ang hangganang sinusubukan mong gamitin.

Gawing sadyang pagpili ang daan ng pagbabalik

Kung mapapanatili ang address ng pinagmulan, nakikita ng aplikasyon ang 10.90.0.x at kailangang i-ruta ang mga tugon pabalik sa container ng VPN. Kung hindi, ipapadala sila ng karaniwang gateway ng Docker nito sa host, na hindi nagmamay-ari ng tunnel. Ang alternatibo ay makitid na isinalin na pinagmulan sa container ng VPN, na nagpapasimple ng tugon ngunit nagtatago ng kliyente sa aplikasyon. Sadyang pumili at isulat kung alin ang pinili mo.

Subukan ang bagong pinahihintulutang koneksyon mula sa ordinaryong kliyente, pagkatapos ay tiyakin na nananatiling sarado ang mga walang kaugnayang port. Kapag nawala ang isang packet, suriin ang namespace ng VPN, ang namespace ng aplikasyon at ang sariling log ng aplikasyon. Ang ping sa gateway ng bridge ay hindi test ng pagtanggap para sa serbisyo.

Panatilihin ang mga patakaran sa sinusuportahang pagsisimula na configuration ng container, dahil nawawala ang interaktibong pag-edit kapag muling nilikha ito. Ang paglalathala ng port sa host ay ibang daan ng paglantad at hindi kailangan dahil lamang naaabot ang serbisyo sa pamamagitan ng tunnel.