Naabot ng host ang IPsec peer, hindi ng Docker container

Ping mo ang remote host mula sa Linux machine at sumasagot ito, kaya gumagana ang tunnel. Nag-timeout pa rin ang container sa tabi mo, at ang natural na susunod na hakbang ay i-restart ang Docker. Ang container sa bridge network ay karaniwang nagsisimula sa ibang source address at pumapasok sa host sa pamamagitan ng forwarding kaysa sa sariling output path ng application sa host, kaya sinukat ng matagumpay na test ang ibang packet. Para sa policy-based na strongSwan tunnel, hindi sapat ang ordinaryong ruta patungo sa remote subnet kapag hindi tumutugma ang forwarded packet sa naka-install na IPsec policy.

Sinusundan ng gabay sa ibaba ang isang destinasyon sa dalawang source, binabasa ang estado bago baguhin ang anuman.

Magsimula sa isang destinasyon at dalawang source

Pumili muna ng kilalang serbisyo ayon sa IP, para hindi ka sabay na nagde-debug ng DNS. Itala ang tatlong katotohanan: ang bridge prefix ng container, ang source address ng host request na gumana, at ang napagkasunduang local at remote traffic selector para sa tunnel. Ipinapaliwanag ng tatlong numerong iyon ang halos lahat ng kaso ng sintomas na ito.

Pagkatapos ulitin ang nabigong request mula sa loob ng container at dakpin ang source na aktwal nitong ginagamit. Kung hindi sakop ng local selector ang address na iyon, alam mo na ang resulta, at walang muling paglikha ng container ang makakabago nito.

Basahin ang mga policy bago hawakan ang Docker

Saklaw ng read-only na host check ang mga desisyon sa routing, ang policy database at ang mga rule na pumipili sa pagitan nila:

ip rule show
ip route show table all
ip xfrm policy

Ipinapakita ng listahan ng policy ang mga selector at direksyon nang hindi kailangan ang IPsec state dump na puno ng key material, kaya ligtas itong i-paste sa ticket. Maghanap ng local selector na sumasaklaw sa address ng host pero hindi sa bridge prefix. Suriin din ang overlap: ang ruta ng container na itinuturing na local ang remote destination ay hindi kailanman maglalabas ng inaasahang forwarded packet, at ang tunnel ang sinisisi. Itabi ang listahang iyon sa tabi ng source address ng container, dahil ang dalawa mismo ang buong paghahambing.

Kung wala ang container prefix, huminto at magpasya sa arkitektura bago i-edit ang anupaman. Ipinapalagay ng natitirang gabay na napagkasunduan ninyo kung aling source address ang dapat lumitaw sa network.

Suriin ang filtering at pagsasalin nang sunod-sunod

Maaaring harangan ng Linux bridge firewall ng Docker ang forwarding nang hiwalay sa IPsec. Sa iptables backend, siyasatin ang FORWARD path at ang mga desisyon sa DOCKER-USER, tandaan na ang rule na idinagdag pagkatapos ng naunang verdict ay maaaring hindi kailanman tumakbo. Iba ang integrasyon ng nftables backend, kaya huwag gumawa ng DOCKER-USER chain dahil lang pinangalanan ito ng isang iptables example; suriin kung aling backend ang aktwal na ginagamit ng daemon mo.

Pagkatapos suriin ang pagsasalin ng source. Maaaring gawing iba ng malawak na MASQUERADE rule ang packet na dating tumutugma sa IPsec selector, at ang pagkasira ay mukhang problema sa routing nang eksakto. Ang gabay sa forwarding ng strongSwan ay nagdodokumento ng NAT exemption na kailangan bago ang ganoong pagsasalin para sa traffic na tumutugma na sa isang policy.

Ang exemption na iyon ay hindi paraan para magdagdag ng hindi sakop na container source sa tunnel. Pinoprotektahan lang nito ang traffic na umaayon na sa disenyo, kaya ayusin muna ang mga tanong sa selector at return path, pagkatapos gawing pareho ang NAT at filtering sa sagot. Kung napapalawak mo ang exemption sa halip, ang selector ang dapat baguhin, hindi ang NAT rule.

Pagkatapos magpasya kung routed o translated

Ang routed container subnet ay nangangailangan na tanggapin ng dalawang peer ang subnet na iyon at may remote return path pabalik dito, na karaniwang nangangahulugan ng pagbabago ng selector sa dalawang dulo at pakikipag-usap sa may-ari ng malayong panig. Ang sadyang isinalin na disenyo ay dapat magpakita ng address na sakop ng policy sa kaugnay na yugto ng lookup, na karaniwang nangangahulugan ng makitid at dokumentadong rule kaysa default na MASQUERADE.

Wala sa dalawang kaayusan ang awtomatikong sumusunod mula sa gumaganang tunnel ng host, at ang pagpili sa pagitan nila ay desisyon sa disenyo na may may-ari. Isulat kung alin ang pinili mo, dahil kung hindi ay muli itong kukunin ng susunod na engineer mula sa mga counter ng firewall.

Abangan din ang hybrid na pagkasira: kalahati ng rule set ay isinalin at kalahati ay hindi, na nagdudulot ng pana-panahong tagumpay na nakadepende sa destination port at hindi sa anuman sa network.

I-verify gamit ang bagong koneksyon, hindi restart

Gumamit ng bagong application connection habang pinapanood ang makitid na firewall counter at ang remote receiver, para may source ang bawat obserbasyon. Ang Docker restart ay maaaring magbago ng estado ng rule at makakaabala rin sa workloads, na nag-aalis sa iyo ng malinis na signal na sinusubukan mong makuha.

Ang matibay na resulta ay apat na pahayag na maipapakita mo: ang source ng container, ang tugmang protected path, ang pinapayagang forwarding, at ang sagot na bumabalik. Kapag hawak ang apat, naaabot ng container ang peer sa parehong dahilan ng host.