IPsec cu mai multe subrețele pierde traficul de retur? Numărați reqid-urile

Traficul pleacă dintr-un sediu și nu se mai întoarce, ambele gateway-uri raportează o negociere finalizată, iar singurul indiciu este o grămadă de pachete de ieșire fără răspunsuri. Pe un endpoint Linux, cauza obișnuită nu este puterea criptării, MTU-ul sau un tabel de rutare. Este granularitatea intrărilor de politică și numărul care leagă fiecare politică de o asociere de securitate. Procedura de mai jos citește acele două baze înainte de a atinge orice altceva.

Separați simptomul înainte de a schimba ceva

O defecțiune într-o singură direcție cu o negociere IKE finalizată reduce problema la calea de date. Fie politica de ieșire se potrivea și răspunsul a fost eliminat, fie răspunsul nu a ajuns niciodată pentru că cealaltă parte nu avea prin ce să-l trimită. Dintr-o aplicație ambele cazuri arată la fel, iar bazele xfrm le disting.

Nu începeți cu MTU-ul. Un MTU greșit produce blocaje și simptome de fragmentare, nu o separare curată a direcției cu contoare de ieșire în creștere.

Citiți baza de politici și baza de stări

În Linux criptarea este decisă de intrările de politică, așa că o politică potrivită, nu o rută, este ceea ce pune un pachet în tunel. Rulați ip xfrm policy pentru a vedea selectorii, direcția, prioritatea și șablonul fiecărei intrări, și ip xfrm state pentru a vedea asocierile stabilite cu reqid-urile lor. Politica și asocierea sunt unite prin acel reqid.

Priviți toate trei direcțiile. Ieșire și intrare acoperă traficul către și de la acest host; direcția de înaintare contează când hostul rutează pentru alții. O intrare lipsă sau nepotrivită într-o direcție explică un rezultat într-o singură direcție fără nicio defecțiune criptografică.

Asimetria clasică: un reqid pentru mai multe subrețele

O defecțiune frecventă vine de la un peer care instalează politici pentru toate subrețelele negociate sub un singur reqid, ceea ce se întâmplă cu generate_policy require de la racoon. Traficul iese atunci prin asocierea stabilită ultima, în timp ce cealaltă parte păstrează o asociere separată pentru fiecare subrețea. Răspunsurile sosesc pe o asociere al cărei reqid nu identifică politica ce ar trebui să le accepte, iar nucleul le elimină după decriptare.

Corectarea este o schimbare de configurație, nu o regulă de firewall: generate_policy unique; dă fiecărei politici propriul reqid, astfel încât asocierile pe politică ale peer-ului să aibă parteneri corespunzători. Aplicați-o, renegociați și numărați reqid-urile distincte pentru subrețelele așteptate înainte de a declara succesul.

Dacă două subrețele împart încă un reqid în timp ce cealaltă parte așteaptă două, ați găsit asimetria. Notați maparea, pentru că este dovada că următoarea schimbare a corectat-o sau a păstrat-o.

Selectorii vin din negociere, nu din configurația dumneavoastră

Intervalele protejate sunt ceea ce au convenit ambele capete, nu ceea ce a cerut una dintre părți. Un client care oferă o pereche de hosturi împotriva unui interval remot larg primește versiunea îngustată a gateway-ului, iar clientul nu o poate lărgi. Citiți selectorii instalați în loc de cei din fișierul local.

Când obiectivul este opusul, păstrarea unei destinații în afara tunelului, adăugați o politică de ocolire cu un număr de prioritate mai mic, astfel încât să învingă intrarea instalată automat. O politică fără șablon permite text clar, ceea ce o face o excepție deliberată pentru un registru de modificări în loc de un pas de depanare.

Verificați în această ordine și știți cum să reveniți

Listați politicile pentru fiecare subrețea în ambele direcții, inclusiv înaintarea dacă hostul rutează. Numărați reqid-urile distincte și confirmați unul pe politică pe partea care îl așteaptă. Comparați selectorii instalați cu cei negociați. Recitiți contoarele pe asociere după o reînnoire de cheie, pentru că asocierea inspectată poate fi deja dispărută. Verificați rutele la final, deoarece o rută lipsă către subrețeaua îndepărtată produce un simptom similar într-o singură direcție cu contoare de politică curate.

Înainte de a schimba peer-ul, salvați ieșirea curentă a ambelor comenzi xfrm. Dacă noua setare nu restabilește direcția de retur, restaurarea acelei ieșiri este o revenire mai rapidă decât reconstruirea tunelului din memorie și păstrează comparația onestă.