Die gasheer bereik die IPsec-portuur, die Docker-houer nie

Jy ping die afgeleë gasheer vanaf die Linux-boks en dit antwoord, so die tonnel werk. Die houer langs jou keer steeds uit, en die natuurlike volgende stap is om Docker te herbegin. ’n Houer op ’n brugnetwerk begin gewoonlik met ’n ander bronadres en kom by die gasheer in via stuur in plaas van via die gasheerprogram se eie uitvoerpad, dus het die geslaagde toets ’n ander pakket gemeet. Vir ’n beleidsgebaseerde strongSwan-tonnel is ’n gewone roete na die afgeleë subnet nie genoeg wanneer die gestuurde pakket nie by die geïnstalleerde IPsec-beleid pas nie.

Die deurloop hier onder volg een bestemming oor twee bronne en lees eers die toestand voordat iets verander word.

Begin by een bestemming en twee bronne

Kies eers ’n bekende diens volgens IP, sodat jy nie terselfdertyd DNS ontfout nie. Teken drie feite aan: die houer se brugvoorvoegsel, die bronadres van die gasheerversoek wat gewerk het, en die onderhandelde plaaslike en afgeleë verkeerskeurders vir die tonnel. Daardie drie getalle verduidelik byna elke geval van hierdie simptoom.

Herhaal dan die mislukte versoek van binne die houer en vang die bron wat dit werklik gebruik. As daardie adres nie deur die plaaslike keurder gedek word nie, weet jy reeds die uitkoms, en geen herskeping van die houer sal dit verander nie.

Lees die beleide voordat jy Docker aanraak

Slegs-lees-gasheerkontroles dek die roetebesluite, die beleidsdatabasis en die reëls wat tussen hulle kies:

ip rule show
ip route show table all
ip xfrm policy

Die beleidslys wys keurders en rigting sonder om ’n IPsec-toestandstrooiing vol sleutelmateriaal nodig te hê, en daarom is dit veilig om in ’n kaartjie te plak. Soek ’n plaaslike keurder wat die gasheeradres dek maar nie die brugvoorvoegsel nie. Kyk ook vir oorvleueling: ’n houerroete wat die afgeleë bestemming as plaaslik behandel, sal nooit die gestuurde pakket lewer wat jy verwag nie, en die tonnel kry die skuld. Stoor daardie lys langs die houer se bronadres, want daardie twee saam is die hele vergelyking.

As die houervoorvoegsel ontbreek, stop en besluit die argitektuur voordat jy iets anders wysig. Die res van hierdie deurloop aanvaar dat julle ooreengekom het watter bronadres op die draad moet verskyn.

Kontroleer filtering en vertaling in volgorde

Docker se Linux-brugfirewall kan stuur onafhanklik van IPsec blokkeer. Met die iptables-agterkant, ondersoek die FORWARD-pad en die DOCKER-USER-besluite, en onthou dat ’n reël wat ná ’n vroeëre uitspraak bygevoeg is, miskien nooit loop nie. Die nftables-agterkant integreer anders, so moenie ’n DOCKER-USER-ketting skep net omdat ’n iptables-voorbeeld dit genoem het nie; kyk watter agterkant jou daemon werklik gebruik.

Kontroleer dan bronvertaling. ’n Breë MASQUERADE-reël kan ’n pakket wat voorheen by ’n IPsec-keurder gepas het, in een verander wat nie meer pas nie, en die fout lyk presies soos ’n roeteprobleem. Die strongSwan-stuurgids dokumenteer die NAT-vrystelling wat nodig is voor sulke vertaling vir verkeer wat reeds by ’n beleid pas.

Daardie vrystelling is nie ’n manier om ’n ongedekte houerbron by die tonnel te voeg nie. Dit beskerm net verkeer wat reeds by die ontwerp pas, so besleg eers die keurder- en terugpad-vrae, en maak dan NAT en filtering met die antwoord eens. As jy die vrystelling eerder verbreed, is die keurder die ding om te verander, nie die NAT-reël nie.

Besluit dan gerouteer of vertaal

’n Gerouteerde houersubnet vereis dat beide kante daardie subnet aanvaar en ’n afgeleë terugpad daarheen, wat gewoonlik ’n keurderverandering aan beide kante beteken en ’n gesprek met wie die verre kant besit. ’n Doelbewus vertaalde ontwerp moet eerder ’n adres voorhou wat deur die beleid gedek word in die betrokke naslaanstadium, wat gewoonlik ’n nou, gedokumenteerde reël beteken eerder as ’n verstek-MASQUERADE.

Geen van die twee reëlings volg outomaties uit die gasheer se werkende tonnel nie, en om tussen hulle te kies is ’n ontwerpbesluit met ’n eienaar. Skryf neer watter een jy gekies het, want die volgende ingenieur sal dit anders uit die firewall-tellers herlei.

Pas ook op vir die hibriede fout: die helfte van die reëlstel vertaal en die helfte nie, wat wisselvallige sukses lewer wat van die bestemmingspoort afhang eerder as van enigiets aan die netwerk.

Verifieer met ’n nuwe verbinding, nie ’n herbegin nie

Gebruik ’n nuwe programverbinding terwyl jy nou firewall-tellers en die afgeleë ontvanger dop, sodat elke waarneming ’n bron het. ’n Docker-herbegin kan reëltoestand verander en sal ook werkverrigting ontwrig, wat jou die skoon sein kos wat jy wou kry.

Die blywende resultaat is vier stellings wat jy kan wys: die houerbron, die bypassende beskermde pad, toegelate stuur, en ’n antwoord wat terugkom. Wanneer al vier geld, bereik die houer die portuur om dieselfde rede as die gasheer.