Gazda ajunge la partenerul IPsec, containerul Docker nu

Faceți ping către gazda îndepărtată de pe mașina Linux și răspunde, deci tunelul funcționează. Containerul din apropiere încă expiră, iar pasul următor natural este repornirea Docker. Un container într-o rețea punte pornește de obicei cu altă adresă sursă și intră în gazdă prin forwarding, nu prin calea de ieșire proprie a aplicației de pe gazdă, deci testul reușit a măsurat alt pachet. Pentru un tunel strongSwan bazat pe politici, o rută obișnuită către subrețeaua îndepărtată nu este suficientă când pachetul redirecționat nu se potrivește cu politica IPsec instalată.

Parcursul de mai jos urmărește o destinație prin două surse, citind starea înainte de a schimba ceva.

Începeți cu o destinație și două surse

Alegeți mai întâi un serviciu cunoscut după IP, ca să nu depanați DNS în același timp. Notați trei fapte: prefixul punte al containerului, adresa sursă a cererii din gazdă care a funcționat și selectorii de trafic locali și îndepărtați negociați pentru tunel. Acele trei numere explică aproape fiecare caz al acestui simptom.

Apoi repetați cererea eșuată din interiorul containerului și capturați sursa pe care o folosește efectiv. Dacă adresa nu este acoperită de selectorul local, știți deja rezultatul, și nicio recreare a containerului nu îl va schimba.

Citiți politicile înainte de a atinge Docker

Verificările de gazdă doar în citire acoperă deciziile de rutare, baza de politici și regulile care aleg între ele:

ip rule show
ip route show table all
ip xfrm policy

Lista politicilor arată selectorii și direcția fără a avea nevoie de o descărcare de stare IPsec plină de material de cheie, de aceea este sigur să o lipiți într-un tichet. Căutați un selector local care acoperă adresa gazdei dar nu prefixul punte. Verificați și suprapunerea: o rută de container care tratează destinația îndepărtată ca locală nu va produce niciodată pachetul redirecționat așteptat, iar tunelul este învinuit. Păstrați lista lângă adresa sursă a containerului, pentru că cele două împreună sunt întreaga comparație.

Dacă lipsește prefixul containerului, opriți-vă și decideți arhitectura înainte de a edita orice altceva. Restul parcursului presupune că ați convenit ce adresă sursă trebuie să apară în rețea.

Verificați filtrarea și traducerea în ordine

Firewallul punte Linux al Docker poate bloca forwardingul independent de IPsec. Cu backendul iptables, inspectați calea FORWARD și deciziile DOCKER-USER, ținând cont că o regulă adăugată după un verdict anterior poate să nu ruleze niciodată. Backendul nftables se integrează diferit, așa că nu creați un lanț DOCKER-USER doar pentru că un exemplu iptables l-a numit așa; verificați ce backend folosește de fapt daemonul vostru.

Apoi verificați traducerea sursei. O regulă MASQUERADE largă poate transforma un pachet care corespundea anterior unui selector IPsec într-unul care nu mai corespunde, iar defecțiunea arată exact ca o problemă de rutare. Ghidul de forwarding strongSwan documentează excepția NAT necesară înainte de o astfel de traducere pentru traficul care corespunde deja unei politici.

Acea excepție nu este o cale de a adăuga la tunel o sursă de container neacoperită. Protejează doar traficul care se potrivește deja proiectului, așa că rezolvați mai întâi întrebările despre selector și calea de întoarcere, apoi faceți NAT și filtrarea să fie de acord cu răspunsul. Dacă începeți să lărgiți excepția, selectorul este cel care trebuie schimbat, nu regula NAT.

Apoi decideți rutat sau tradus

O subrețea de container rutată cere ca ambii parteneri să accepte acea subrețea și o cale de întoarcere îndepărtată către ea, ceea ce înseamnă de obicei o schimbare de selector la ambele capete și o discuție cu proprietarul părții îndepărtate. Un proiect tradus deliberat trebuie în schimb să prezinte o adresă acoperită de politică la etapa de căutare relevantă, ceea ce înseamnă de obicei o regulă îngustă și documentată în loc de un MASQUERADE implicit.

Niciuna dintre cele două aranjamente nu decurge automat din tunelul funcțional al gazdei, iar alegerea între ele este o decizie de proiect cu un proprietar. Notați pe care ați ales-o, altfel următorul inginer o va deduce din nou din contoarele firewallului.

Urmăriți și defecțiunea hibridă: jumătate din setul de reguli tradus și jumătate nu, ceea ce produce succes intermitent care depinde de portul destinație și nu de ceva din rețea.

Verificați cu o conexiune nouă, nu cu o repornire

Folosiți o conexiune nouă a aplicației urmărind contoare înguste ale firewallului și receptorul îndepărtat, astfel încât fiecare observație să aibă o sursă. O repornire Docker poate schimba starea regulilor și va perturba și sarcinile de lucru, ceea ce vă costă semnalul curat pe care încercați să îl obțineți.

Rezultatul durabil sunt patru afirmații pe care le puteți arăta: sursa containerului, calea protejată corespunzătoare, forwardingul permis și un răspuns care se întoarce. Când toate patru sunt valabile, containerul ajunge la partener din același motiv ca gazda.