Mazgas pasiekia IPsec partnerį, Docker konteineris – ne

Jūs pinginate nuotolinį mazgą iš Linux mašinos ir jis atsako, vadinasi, tunelis veikia. Šalia esantis konteineris vis dar praleidžia laiką, o natūralus kitas žingsnis – perkrauti Docker. Tilto tinklo konteineris paprastai pradeda su kitu šaltinio adresu ir patenka į mazgą per persiuntimą, o ne per pačios mazgo programos išėjimo kelią, todėl sėkmingas testas išmatavo kitą paketą. Politika pagrįstam strongSwan tuneliui įprasto maršruto į nuotolinį potinklį nepakanka, kai persiunčiamas paketas neatitinka įdiegtos IPsec politikos.

Toliau pateiktas vadovas seka vieną tikslą per du šaltinius ir skaito būseną prieš ką nors keisdamas.

Pradėkite nuo vieno tikslo ir dviejų šaltinių

Pirmiausia pasirinkite žinomą paslaugą pagal IP, kad tuo pačiu metu nederintumėte DNS. Užrašykite tris faktus: konteinerio tilto prefiksą, sėkmingo mazgo užklausos šaltinio adresą ir suderintus vietinius bei nuotolinius srauto selektorius tuneliui. Tie trys skaičiai paaiškina beveik kiekvieną šio simptomo atvejį.

Tada pakartokite nepavykusią užklausą konteinerio viduje ir užfiksuokite šaltinį, kurį jis iš tikrųjų naudoja. Jei vietinis selektorius to adreso neapima, rezultatą jau žinote, ir joks konteinerio atkūrimas to nepakeis.

Perskaitykite politikas prieš liesdami Docker

Tik skaitymo mazgo patikros apima maršrutizavimo sprendimus, politikos duomenų bazę ir taisykles, kurios tarp jų pasirenka:

ip rule show
ip route show table all
ip xfrm policy

Politikų sąrašas rodo selektorius ir kryptį be IPsec būsenos išrašo, pilno raktų medžiagos, todėl saugu jį įklijuoti į bilietą. Ieškokite vietinio selektoriaus, kuris apima mazgo adresą, bet ne tilto prefiksą. Patikrinkite ir persidengimą: konteinerio maršrutas, kuris nuotolinį tikslą laiko vietiniu, niekada nesukurs laukiamo persiunčiamo paketo, ir tunelis dėl to kaltinamas. Išsaugokite tą sąrašą šalia konteinerio šaltinio adreso, nes abu kartu yra visas palyginimas.

Jei konteinerio prefikso nėra, sustokite ir nuspręskite architektūrą prieš redaguodami ką nors kita. Likusi vadovo dalis daro prielaidą, kad sutarėte, kuris šaltinio adresas turi pasirodyti tinkle.

Patikrinkite filtravimą ir vertimą iš eilės

Docker Linux tilto ugniasienė gali blokuoti persiuntimą nepriklausomai nuo IPsec. Su iptables pagrindu patikrinkite FORWARD kelią ir DOCKER-USER sprendimus, atsimindami, kad taisyklė, pridėta po ankstesnio nuosprendžio, gali niekada neveikti. nftables pagrindas integruojamas kitaip, todėl nekurkkite DOCKER-USER grandinės vien todėl, kad iptables pavyzdys ją taip pavadino; patikrinkite, kurį pagrindą jūsų demonas tikrai naudoja.

Tada patikrinkite šaltinio vertimą. Plati MASQUERADE taisyklė gali paversti paketą, kuris anksčiau atitiko IPsec selektorių, tokiu, kuris nebeatitinka, o gedimas atrodo lygiai kaip maršrutizavimo problema. strongSwan persiuntimo vadovas dokumentuoja NAT išimtį, reikalingą prieš tokį vertimą jau politiką atitinkančiam srautui.

Ta išimtis nėra būdas pridėti neapimtą konteinerio šaltinį prie tunelio. Ji saugo tik srautą, kuris jau atitinka projektą, todėl pirmiausia išspręskite selektoriaus ir grįžimo kelio klausimus, o tada suderinkite NAT ir filtravimą su atsakymu. Jei imate plėsti išimtį, keisti reikia selektorių, o ne NAT taisyklę.

Tada nuspręskite: maršrutizuota ar versta

Maršrutizuotas konteinerio potinklis reikalauja, kad abu partneriai priimtų tą potinklį ir būtų nuotolinis grįžimo kelias į jį, o tai paprastai reiškia selektoriaus pakeitimą abiejuose galuose ir pokalbį su tolimos pusės savininku. Sąmoningai verstas projektas vietoj to turi pateikti politikos apimtą adresą atitinkamame paieškos etape, o tai paprastai reiškia siaurą, dokumentuotą taisyklę, o ne numatytąją MASQUERADE.

Nė vienas iš šių sprendimų automatiškai neišplaukia iš veikiančio mazgo tunelio, o pasirinkimas tarp jų yra projektinis sprendimas su savininku. Užsirašykite, kurį pasirinkote, nes kitaip kitas inžinierius jį vėl išves iš ugniasienės skaitiklių.

Atkreipkite dėmesį ir į hibridinį gedimą: pusė taisyklių rinkinio išversta, pusė ne, o tai duoda protarpinę sėkmę, kuri priklauso nuo paskirties prievado, o ne nuo ko nors tinkle.

Patikrinkite nauju ryšiu, o ne perkrovimu

Naudokite naują programos ryšį stebėdami siaurus ugniasienės skaitiklius ir nuotolinį imtuvą, kad kiekvienas stebėjimas turėtų šaltinį. Docker perkrovimas gali pakeisti taisyklių būseną ir taip pat sutrikdys darbines apkrovas, o tai atima švarų signalą, kurio norėjote.

Ilgalaikis rezultatas yra keturi teiginiai, kuriuos galite parodyti: konteinerio šaltinis, atitinkamas apsaugotas kelias, leistas persiuntimas ir atsakymas, kuris grįžta. Kai visi keturi galioja, konteineris pasiekia partnerį dėl tos pačios priežasties kaip ir mazgas.