La gastiganto atingas la IPsec-partneron, la Docker-ujo ne

Vi pingas la malproksiman gastiganton el la Linuksa maŝino kaj ĝi respondas, do la tunelo funkcias. La ujo apud vi ankoraŭ tempas for, kaj la natura sekva paŝo estas restartigi Docker. Ponta ujo kutime komenciĝas kun alia fontadreso kaj eniras la gastiganton per plusendado anstataŭ per la propra elira vojo de la gastiganta aplikaĵo, do la sukcesa testo mezuris alian paketon. Por policy-bazita strongSwan-tunelo, ordinara itinero al la malproksima subreto ne sufiĉas kiam la plusendita paketo ne kongruas kun la instalita IPsec-policy.

La sekva irado sekvas unu celon tra du fontoj, legante la staton antaŭ ol ŝanĝi ion ajn.

Komencu per unu celo kaj du fontoj

Unue elektu konatan servon laŭ IP, por ke vi ne samtempe sencimigu DNS. Notu tri faktojn: la pontan prefikson de la ujo, la fontadreson de la gastiganta peto kiu funkciis, kaj la intertraktitajn lokajn kaj malproksimajn trafikajn selektilojn de la tunelo. Tiuj tri nombroj klarigas preskaŭ ĉiun kazon de ĉi tiu simptomo.

Poste ripetu la fiaskintan peton el interne de la ujo kaj kaptu la fonton kiun ĝi efektive uzas. Se tiu adreso ne estas kovrita de la loka selektilo, vi jam scias la rezulton, kaj neniu rekreado de la ujo ŝanĝos ĝin.

Legu la policy-ojn antaŭ ol tuŝi Docker

Nurlegaj gastigantaj kontroloj kovras la itinerajn decidojn, la policy-datumbazon kaj la regulojn kiuj elektas inter ili:

ip rule show
ip route show table all
ip xfrm policy

La policy-listo montras selektilojn kaj direkton sen bezoni IPsec-statan elprenaĵon plenan de ŝlosilmaterialo, kaj tial estas sekure alglui ĝin en bileton. Serĉu lokan selektilon kiu kovras la gastigantan adreson sed ne la pontan prefikson. Kontrolu ankaŭ overlapon: uja itinero kiu traktas la malproksiman celon kiel lokan neniam produktos la atendatan plusenditan paketon, kaj la tunelo ricevas la kulpon. Konservu tiun liston apud la fontadreso de la ujo, ĉar ambaŭ kune estas la tuta komparo.

Se la uja prefikso mankas, haltu kaj decidu la arkitekturon antaŭ ol redakti ion alian. La resto de ĉi tiu irado supozas ke vi interkonsentis kiun fontadreson oni devus vidi en la reto.

Kontrolu filtradon kaj tradukadon laŭvice

La Linuksa ponta fajroŝirmilo de Docker povas bloki plusendadon sendepende de IPsec. Kun la iptables-motoro, kontrolu la FORWARD-vojon kaj la DOCKER-USER-decidaĵojn, memorante ke regulo aldonita post pli frua verdikto eble neniam ruliĝos. La nftables-motoro integriĝas alie, do ne kreu DOCKER-USER-ĉenon nur ĉar iptables-ekzemplo nomis ĝin; kontrolu kiun motoron via daemon efektive uzas.

Poste kontrolu fontan tradukadon. Larĝa MASQUERADE-regulo povas ŝanĝi paketon kiu antaŭe kongruis al IPsec-selektilo en unu kiu ne plu kongruas, kaj la fiasko aspektas precize kiel itinera problemo. La plusenda gvidilo de strongSwan dokumentas la NAT-escepton bezonatan antaŭ tia tradukado por trafiko kiu jam kongruas al policy.

Tiu escepto ne estas maniero aldoni nekovritan ujan fonton al la tunelo. Ĝi protektas nur trafikon kiu jam konvenas al la dezajno, do solvu unue la demandojn pri selektilo kaj revena vojo, poste igi NAT kaj filtrado konsenti kun la respondo. Se vi anstataŭe komencas larĝigi la escepton, la selektilo estas tio kion ŝanĝi, ne la NAT-regulo.

Poste decidu ĉu itinita ĉu tradukita

Itinita uja subreto postulas ke ambaŭ partneroj akceptu tiun subreton kaj malproksiman revenan vojon al ĝi, kio kutime signifas selektilan ŝanĝon ĉe ambaŭ finoj kaj interparolon kun la posedanto de la malproksima flanko. Intence tradukita dezajno devas anstataŭe prezenti adreson kovritan de la policy en la koncerna serĉa stadio, kio kutime signifas mallarĝan, dokumentitan regulon anstataŭ defaŭlta MASQUERADE.

Neniu el la du aranĝoj sekvas aŭtomate el la funkcianta tunelo de la gastiganto, kaj elekti inter ili estas dezajna decido kun posedanto. Notu kiun vi elektis, ĉar alie la sekva inĝeniero rederivos ĝin el la fajroŝirmilaj nombriloj.

Atentu ankaŭ la hibridan fiaskon: duono de la regulnombro tradukita kaj duono ne, kio produktas intermitan sukceson kiu dependas de la cela pordo kaj ne de io ajn en la reto.

Kontrolu per freŝa konekto, ne per restartigo

Uzu freŝan aplikaĵan konekton dum vi observas mallarĝajn fajroŝirmilajn nombrilojn kaj la malproksiman ricevilon, por ke ĉiu observo havu fonton. Docker-restartigo povas ŝanĝi regulstaton kaj ankaŭ perturbos laborŝarĝojn, kio kostas al vi la puran signalon kiun vi volis.

La daŭra rezulto estas kvar asertoj kiujn vi povas montri: la uja fonto, la kongrua protektita vojo, permesita plusendado, kaj respondo kiu revenas. Kiam ĉiuj kvar validas, la ujo atingas la partneron pro la sama kialo kiel la gastiganto.