Resursdators sasniedz IPsec partneri, Docker konteiners ne

Jūs pingojat attālo resursdatoru no Linux mašīnas, un tas atbild, tātad tunelis strādā. Blakus esošais konteiners joprojām nokļūst taimautā, un dabiskais nākamais solis ir restartēt Docker. Tilta tīkla konteiners parasti sākas ar citu avota adresi un nokļūst resursdatorā caur pāradresāciju, nevis pa pašas resursdatora programmas izejas ceļu, tāpēc veiksmīgais tests izmērīja citu paketi. Uz politiku balstītam strongSwan tunelim parasts maršruts uz attālo apakštīklu nav pietiekams, ja pāradresētā pakete neatbilst instalētajai IPsec politikai.

Zemāk esošā gaita seko vienam mērķim cauri diviem avotiem, nolasot stāvokli pirms kaut kā maiņas.

Sāciet ar vienu mērķi un diviem avotiem

Vispirms izvēlieties zināmu pakalpojumu pēc IP, lai vienlaikus nedebugotu DNS. Pierakstiet trīs faktus: konteinera tilta prefiksu, strādājušā resursdatora pieprasījuma avota adresi un saskaņotos vietējos un attālos trafika selektorus tunelim. Šie trīs skaitļi izskaidro gandrīz katru šī simptoma gadījumu.

Pēc tam atkārtojiet neizdevušos pieprasījumu konteinera iekšienē un fiksējiet avotu, ko tas faktiski izmanto. Ja vietējais selektors šo adresi neaptver, iznākumu jau zināt, un nekāda konteinera atkārtota izveide to nemainīs.

Izlasiet politikas pirms Docker aizskaršanas

Tikai lasāmas resursdatora pārbaudes aptver maršrutēšanas lēmumus, politiku datubāzi un noteikumus, kas starp tiem izvēlas:

ip rule show
ip route show table all
ip xfrm policy

Politiku saraksts rāda selektorus un virzienu bez IPsec stāvokļa izdrukas, kas pilna ar atslēgu materiālu, tāpēc to droši ielīmēt biļetenā. Meklējiet vietējo selektoru, kas aptver resursdatora adresi, bet ne tilta prefiksu. Pārbaudiet arī pārklāšanos: konteinera maršruts, kas attālo mērķi uzskata par vietēju, nekad neradīs gaidīto pāradresēto paketi, un tunelis tiek vainots. Saglabājiet šo sarakstu blakus konteinera avota adresei, jo abi kopā ir viss salīdzinājums.

Ja konteinera prefiksa nav, apstājieties un izlemiet arhitektūru pirms kaut kā cita labošanas. Pārējā gaita pieņem, ka esat vienojušies, kurai avota adresei jāparādās tīklā.

Pārbaudiet filtrēšanu un tulkošanu pēc kārtas

Docker Linux tilta ugunsmūris var bloķēt pāradresāciju neatkarīgi no IPsec. Ar iptables aizmuguri pārbaudiet FORWARD ceļu un DOCKER-USER lēmumus, atceroties, ka noteikums, kas pievienots pēc iepriekšēja sprieduma, var nekad neizpildīties. nftables aizmugure integrējas citādi, tāpēc neveidojiet DOCKER-USER ķēdi tikai tāpēc, ka iptables piemērs to tā nosauca; pārbaudiet, kuru aizmuguri jūsu dēmons faktiski izmanto.

Pēc tam pārbaudiet avota tulkošanu. Plašs MASQUERADE noteikums var pārvērst paketi, kas iepriekš atbilda IPsec selektoram, tādā, kas vairs neatbilst, un kļūme izskatās tieši kā maršrutēšanas problēma. strongSwan pāradresācijas rokasgrāmata dokumentē NAT izņēmumu, kas nepieciešams pirms šādas tulkošanas jau politikai atbilstošam trafikam.

Šis izņēmums nav veids, kā tunelim pievienot neaptvertu konteinera avotu. Tas aizsargā tikai trafiku, kas jau atbilst projektam, tāpēc vispirms atrisiniet selektora un atgriešanās ceļa jautājumus, tad saskaņojiet NAT un filtrēšanu ar atbildi. Ja sākat paplašināt izņēmumu, maināmais ir selektors, nevis NAT noteikums.

Pēc tam izlemiet maršrutētu vai tulkotu

Maršrutēts konteinera apakštīkls prasa, lai abi partneri pieņemtu šo apakštīklu un būtu attāls atgriešanās ceļš uz to, kas parasti nozīmē selektora maiņu abos galos un sarunu ar tālās puses īpašnieku. Apzināti tulkots projekts tā vietā atbilstošajā meklēšanas posmā uzrāda politikas aptvertu adresi, kas parasti nozīmē šauru, dokumentētu noteikumu, nevis noklusējuma MASQUERADE.

Neviens no abiem izkārtojumiem automātiski neizriet no resursdatora strādājošā tuneļa, un izvēle starp tiem ir projektēšanas lēmums ar īpašnieku. Pierakstiet, kuru izvēlējāties, jo citādi nākamais inženieris to atkal atvasinās no ugunsmūra skaitītājiem.

Vērojiet arī hibrīda kļūmi: puse noteikumu kopas tulkota un puse nē, kas dod periodisku panākumu, kurš atkarīgs no galamērķa porta, nevis no kaut kā tīklā.

Pārbaudiet ar jaunu savienojumu, nevis restartu

Izmantojiet jaunu programmas savienojumu, vērojot šaurus ugunsmūra skaitītājus un attālo uztvērēju, lai katram novērojumam būtu avots. Docker restarts var mainīt noteikumu stāvokli un arī traucēs darba slodzes, kas atņem jums to tīro signālu, ko gribējāt iegūt.

Ilgtspējīgais rezultāts ir četri apgalvojumi, ko varat parādīt: konteinera avots, atbilstošais aizsargātais ceļš, atļautā pāradresācija un atbilde, kas atgriežas. Kad visi četri ir spēkā, konteiners sasniedz partneri tā paša iemesla dēļ kā resursdators.