Pag-publish ng port ng Docker at mga pinagmumulan ng VPN: dalawang tugma na namimiss mo
Ang IP ng VPN server ay hindi laging pinagmumulan na nakikita ng Docker, at ang port pagkatapos ng DNAT ay hindi ang na-publish. Itugma ang dalawang katotohanan sa tunay na landas.
Sinasabi ng tuntunin na payagan ang address ng VPN server patungo sa na-publish na serbisyo, at pumuputol pa rin ang koneksyon. Karaniwan ang resultang iyon, at hindi ito bug ng Docker. Dalawang magkahiwalay na tugma ang mali: ang pinagmumulang isinulat mo ay maaaring hindi ang pinagmumulang natatanggap ng host, at ang port na isinulat mo ay maaaring hindi ang port na nakikita ng filter. Ang pag-aayos ng dalawa ay nangangailangan ng pagtingin sa landas ng packet sa halip na diagram ng serbisyo.
Ang mito: payagan ang VPN server at tapos na
Ang naka-route na VPN ay maaaring mapanatili ang address ng tunnel ng kliyente hanggang sa host ng Docker. Ang gateway na gumagawa ng pagsasalin ng pinagmulan ay maaaring palitan ang address na iyon ng sarili nito. Pareho ang mga disenyo ay lehitimo, at gumagawa sila ng magkaibang pinagmumulan para sa parehong aksyon ng user.
Kaya ang pariralang IP ng VPN server ay naglalarawan ng palagay, hindi ng obserbasyon. Hanggang hindi mo alam kung alin sa dalawang disenyo ang nasa harap mo, ang tuntunin ay isang hula.
Pinagmulan: pool ng kliyente o naisaling gateway
Tingnan ang apat na bagay sa pagkakasunod-sunod. Una, ang pool ng address ng kliyente, halimbawa 10.90.0.0/24. Ikalawa, kung isinasalin ng gateway ang pool na iyon bago ito makarating sa host. Ikatlo, ang pinagmumulang talagang naoobserbahan ng host para sa isang bagong koneksyon. Ikaapat, kung pinaghiwalay ng pagpapatotoo ng application ang mga indibidwal na user, dahil hindi ito kaya ng pinagsasaluhang naisaling address.
Kung mapanatili ang pool, ang tuntuning tumutugma lamang sa pampublikong address ng gateway ay namimiss ang bawat kliyente. Kung sadyang nagsasalin ang gateway, ang pagpayag sa naisaling address ay tumatanggap sa bawat user sa likod nito, na maaaring katanggap-tanggap para sa serbisyong may sariling pag-login at hindi katanggap-tanggap para sa anupamang iba.
Port: binabago ng DNAT ang numerong itinutugma mo
Sa karaniwang pag-publish sa tulay ng Linux gamit ang iptables ng Docker, ang pagmamapa ng host mula 8443 patungo sa port ng container 443 ay isinasalin bago tumakbo ang filter ng pagpapasa. Dumarating ang packet sa filter na may destinasyong port 443. Ang tuntuning tumutugma sa 8443 sa puntong iyon ay hindi kailanman nag-aactivate, kahit 8443 ang itina-type ng kliyente.
Umiiral pa rin ang na-publish na port sa pagsubaybay ng koneksyon, kaya doon maaaring itugma ang orihinal na destinasyon kapag talagang kailangan mo ito.
Magpasya kung aling numero ang nagpapahayag ng layunin. Itugma ang port ng container pagkatapos ng DNAT kapag pinoprotektahan ng tuntunin ang serbisyo sa loob ng container. Itugma ang orihinal na destinasyon gamit ang opsyon na conntrack kapag dapat ilarawan ng tuntunin ang hiniling ng kliyente, at tanggapin ang karagdagang gastos sa pagtutugma at ang pag-iingat sa pagkakasunod-sunod ng tuntunin na kasama nito.
Chain: DOCKER-USER, hindi INPUT
Inilalagay ng gabay sa iptables ng Docker ang patakaran sa pagpapasa ng user sa chain na DOCKER-USER, na sinusuri bago ang sariling mga tuntunin sa pagpapasa ng Docker. Ang tuntuning kinopya mula sa serbisyo ng host patungo sa chain na INPUT ay nagsasala ng trapikong nakadirekta sa host, hindi ang trapikong ipinapasa sa container. Ang pagkakamaling iyon ay gumagawa ng tuntuning mukhang tama at walang epekto sa landas ng container.
Panatilihing magkasama sa isang tuntunin ang saklaw ng pinagmulan, ang epektibong destinasyong port, ang protocol at ang papasok na interface. Ang pagpayag na nakabatay lamang sa pinagmulan para sa bawat ipinapasang destinasyon ay mas malawak kaysa sa pagpayag sa isang na-publish na serbisyo.
I-verify gamit ang mga bagong koneksyon
Subukan ang dalawang direksyon gamit ang mga bagong koneksyon: isang pinapayagang kliyente ng VPN at isang pinagmumulang dapat manatiling tinanggihan. Ang umiiral na estado ng koneksyon ay maaaring magpanatili ng sesyon na buhay pagkatapos magbago ang patakaran, kaya walang pinatutunayan ang lumang koneksyon tungkol sa bagong tuntunin. Pagkatapos tingnan ang landas ng tugon, dahil kailangan pa ring mag-route ng container pabalik sa pinagmumulang nakikita nito.
Ang pagkakasunod-sunod ng chain at ang pag-uugali ng pagsasalin ng port sa likod ng mga pagsusuring ito ay dokumentado sa gabay sa iptables ng Docker. Basahin ito bago kopyahin ang isang recipe, at tiyakin kung aling backend ang ginagamit ng naka-install na Docker, dahil iba ang pagsasama ng patakaran ng backend na nftables.