Selectoarele de trafic IPsec: ce acoperă și ce nu acoperă

Selectoarele de trafic numesc traficul interior pe care îl protejează un acord IPsec, iar perechea este negociată, nu presupusă. Două capete se pot autentifica perfect reciproc și totuși să nu fie de acord cu privire la ce pachete aparțin interiorului tunelului. Această dezacord este invizibil în starea conexiunii, care de obicei raportează un tunel sănătos. Citirea selectoarelor de la ambele capete și apoi urmărirea unei destinații îl găsește mai repede decât orice cantitate de editare a politicii.

Citește-le de la ambele capete

Fiecare capăt descrie propria parte ca locală și cealaltă parte ca la distanță. Aceeași pereche de prefixe apare deci inversată în cele două configurații, și acest lucru este corect, nu contradictoriu. Inversarea perspectivei este primul lucru de făcut atunci când un acord funcțional pare greșit pe hârtie. Compararea a două fișiere unul lângă altul fără a le inversa produce o nepotrivire care nu există.

Valorile nu sunt întotdeauna subrețele unice. Selectoarele IKEv2 pot transporta intervale de adrese, numere de protocol și intervale de porturi, și astfel o politică protejează un serviciu în locul unei întregi rețele. Un selector mai îngust decât traficul dorit produce un tunel care transportă unele destinații și le exclude în tăcere pe altele.

Scrie ambele părți într-un singur tabel înainte de a schimba ceva. Exercițiul rezolvă de obicei întrebarea fără a atinge un fișier de configurare.

Îngustarea este decizia respondantului

Inițiatorul propune, iar respondantul poate accepta doar o submulțime. IKEv2 permite respondantului să îngusteze selectoarele de trafic oferite, iar rezultatul îngustat este ceea ce se instalează efectiv. Citirea configurației inițiatorului descrie deci o ofertă, nu acordul.

De aceea o subrețea adăugată la client poate produce un tunel funcțional care totuși refuză noua destinație. Serverul a îngustat oferta până la ce permite politica sa, în timp ce fișierul clientului încă listează intervalul mai larg. Doar starea negociată arată adevărul: pe Linux, ip xfrm policy și lista child SA din documentația IKEv2 a strongSwan raportează ce a fost instalat, nu ce a fost cerut. Când cele două nu sunt de acord, politica respondantului este cea care trebuie schimbată.

O ofertă respinsă este un simptom diferit de una îngustată. Respingerea apare în jurnalul de negociere și nu lasă nicio asociere child.

Urmărește o destinație de la un capăt la altul

Alege o destinație reală plus adresa sursă pe care clientul ar folosi-o pentru ea, apoi urmărește perechea prin trei decizii independente. Ruta alege o cale, selectorul decide dacă acea cale este protejată, iar paravanul decide dacă pachetul este permis. Fiecare poate eșua singur, iar un selector larg nu repară niciunul dintre celelalte.

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

Interogarea rutei numește interfața și adresa sursă care ar transporta pachetul. Lista de politici arată dacă există o politică de tunel potrivită pentru acea pereche, inclusiv direcția și nivelul. Lista SA arată selectoarele child negociate împreună cu contoarele, așa că o asociere child cu zero pachete după ce s-a încercat trafic este semnătura selectoarelor care exclud ce se trimite. Trei comenzi, trei răspunsuri diferite, și doar unul dintre ele explică o cădere tăcută.

Dacă contoarele child se mișcă în timp ce aplicația încă eșuează, problema se află dincolo de tunel. Asta mută investigația către ascultătorul sau paravanul gazdei îndepărtate și nu către selectoare.

Ține cele două obiective separate

Protejarea unei subrețele de birou și trimiterea întregii navigări printr-o ieșire la distanță sunt cerințe diferite cu selectoare diferite. Un profil construit pentru una se potrivește rar celeilalte, iar amestecarea lor produce fie o scurgere, fie o divizare ruptă. Lărgirea intervalului protejat înseamnă schimbarea ambelor capete și a politicii lor de redirecționare, pentru că o modificare unilaterală devine o ofertă respinsă. Acesta este cel mai obișnuit mod în care un tunel funcțional încetează să funcționeze după o mică modificare.

Selectoarele descriu acoperirea criptografică, rutele aleg căi, iar aplicațiile își impun propriile permisiuni. Un tunel care acoperă tot nu poate ajunge la un serviciu legat de loopback, iar o rută în tunel are în continuare nevoie de un selector care include destinația. Verifică toate trei pe aceeași cerere de test, iar nepotrivirea se numește singură.