Politica IPsec îți înghite traficul local: cum îți dai seama

Imprimanta de pe birou nu mai răspunde în momentul în care tunelul se ridică, iar nimic din configurația tunelului nu menționează imprimanta. Ce s-a întâmplat de obicei este că un interval protejat a fost scris suficient de larg încât să o includă, așa că mașina încearcă acum să cripteze trafic care ar fi trebuit să rămână pe segmentul local. Citirea politicii instalate explică capturarea; restrângerea ei în locul potrivit menține traficul la distanță protejat. Drumul de la cererea care eșuează la politica potrivită durează câteva minute.

Urmează fluxul înainte de a schimba un selector

Pornește de la cererea care eșuează și notează patru valori: adresa sursă pe care o folosește mașina, destinația exactă, ruta pe care o alege kernelul și politica ce corespunde acelei perechi.

Aceste patru fapte decid dacă capturarea este deliberată sau accidentală. O destinație care se află în selectorul la distanță este protejată prin proiectare, chiar dacă proiectarea a fost greșită. O destinație din afara lui care este totuși capturată înseamnă că se potrivește altceva, iar schimbarea selectorului nu va ajuta. Ambele cazuri sunt frecvente și sunt distinse de o singură comandă.

Fă asta înainte de a edita ceva, pentru că cazul interesant este subrețeaua locală care se suprapune peste un interval privat pe care conexiunea îl protejează. Prefixe cunoscute precum 192.168.0.0/16 apar în multe rețele, iar un selector scris pentru unul dintre ele poate acoperi în liniște al tău.

Trei feluri de local care se comportă diferit

O destinație atribuită acestui host, o destinație pe același link și o destinație în spatele altei interfețe sunt trei cazuri diferite. Kernelul le tratează diferit pe fiecare când decide dacă traficul are nevoie de protecție.

Nici traficul generat de gateway însuși nu este același lucru cu traficul redirecționat de la un client. O politică ce pare corectă pentru traficul redirecționat poate captura propria sesiune de administrare a gatewayului, și așa pierde un administrator accesul în timp ce repară tunelul.

Obiceiul util este să numești cazul cu voce tare: pachetul acesta vine de la mine, merge la linkul meu sau trece prin mine? Fiecare răspuns indică un loc diferit de restrâns. Notarea cazului împiedică și următoarea persoană să refacă aceeași muncă.

Când intervalul protejat este un întreg spațiu privat, toate trei cazurile pot cădea în el deodată, iar simptomul devine o mașină care nu ajunge la nimic în afară de capătul tunelului.

Citește politica instalată, nu fișierul

Fișierele de configurare descriu intenția; kernelul deține politicile care se potrivesc efectiv. Afișează ambele și tratează o nepotrivire ca prima constatare.

Aceste comenzi arată ruta aleasă pentru destinație și politicile instalate în fiecare direcție:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

Ruta îți spune ce interfață ar folosi pachetul. Lista politicilor îți spune dacă apoi se aplică un șablon pe acel pachet, iar lista conexiunilor arată ce selectori crede daemonul că a instalat. Dacă destinația apare într-un selector la distanță, ai găsit capturarea fără să ghicești.

Restrânge selectorul sau ocolește destinația

Există două reparații acceptate și răspund la întrebări diferite. Restrângerea selectorului spune că această conexiune protejează doar un interval mai mic, ceea ce este corect când intervalul mai larg a fost o greșeală. Adăugarea unei excepții spune că această destinație anume nu trebuie niciodată protejată, ceea ce este corect când intervalul protejat este într-adevăr larg și o destinație este excepția.

Alege-o pe prima când poți, pentru că un selector mai mic este mai ușor de raționat și apare în definiția conexiunii. Alege-o pe a doua când intervalul larg este intenționat și excepția este un singur host sau o subrețea pe care o poți numi.

Ambele aparțin configurației care deține conexiunea. O regulă de runtime adăugată manual dispare la următoarea reconectare, iar defecțiunea revine într-un moment în care nimeni nu-și mai amintește soluția temporară.

Excepții sigure la reinstalare

După modificare, repetă aceeași cerere inofensivă și uită-te la aceiași contori. Destinația locală ar trebui să răspundă, iar destinația la distanță dorită ar trebui să arate în continuare trafic criptat.

Aceste două verificări confirmă că excepția a supraviețuit și că protecția nu:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Apoi deconectează și reconectează tunelul în mod deliberat și repetă ambele. O excepție care funcționează înainte de reconectare și eșuează după a fost aplicată la nivelul greșit, iar acesta este cel mai obișnuit mod în care problema revine.