Peer IPsec de intrare fără profil potrivit? Verificați patru câmpuri

Peer-ul dumneavoastră raportează că tunelul este activ, partea dumneavoastră nu arată nicio asociere de securitate, iar fișierul de configurare conține clar un nume de conexiune potrivit. Toate trei afirmațiile pot fi adevărate simultan. O negociere de intrare este comparată cu configurația în execuție, folosind adresa peer-ului, identitatea pe care o prezintă și traficul pe care îl propune. Un fișier de pe disc care nu a fost niciodată încărcat, o identitate care nu corespunde valorii așteptate sau o pereche de selectoare deplasată cu un prefix vor produce fiecare tăcere. Parcurgeți cele patru grupuri de câmpuri în ordinea pe care o urmează responder-ul.

Începeți cu pachetul, nu cu fișierul

Responder-ul primește o cerere IKE, caută o definiție care poate accepta acest peer și apoi continuă cu autentificarea și selecția traficului. Dacă în primul pas nu corespunde nicio definiție încărcată, negocierea se termină înainte ca vreo eroare utilă să ajungă la utilizator.

De aceea „configurația pare corectă” nu este o dovadă. Întrebarea este ce a încărcat serviciul în execuție și ce intrare a selectat pentru această încercare. O listă de stare răspunde la asta cu o singură comandă, în timp ce buffer-ul editorului răspunde la altă întrebare. Verificați lista înainte de a modifica din nou fișierul.

Primul grup de câmpuri: definiția care este într-adevăr încărcată

Verificați starea în execuție cu instrumentul care deține daemonul: o comandă de stare care listează conexiunile încărcate, nu buffer-ul editorului. Confirmați că intrarea așteptată există, este activată pentru comportamentul de pornire dorit și a fost încărcată după ultima modificare pe care ați făcut-o. Un fișier salvat dar neîncărcat din nou este cauza cea mai frecventă a expresiei „am reparat și nimic nu s-a schimbat”.

Confirmați și ce fișier citește serviciul. Distribuțiile diferă, iar o conexiune scrisă în includerea greșită este ignorată în tăcere în loc să fie respinsă. Dacă lista de stare nu arată deloc intrarea dumneavoastră, suspectați calea de includere înainte de sintaxă.

Al doilea grup de câmpuri: punctele de capăt nu sunt identități

Adresa de la care se conectează peer-ul și identitatea cu care se autentifică sunt câmpuri separate. Un nume de gazdă, un nume distinctiv, un identificator de cheie și o adresă pot servi toate ca identitate IKE în funcție de configurație și nu trebuie deloc să semene cu adresa publică.

Potrivirea punctelor de capăt poate implica și o vedere NAT: adresa văzută în rețea poate diferi de adresa pe care peer-ul crede că o are. În modelul de conexiuni al libreswan, left și right sunt etichete pentru cei doi participanți, nu o ordine fixă de local și la distanță, motiv pentru care copierea unei configurații funcționale din altă locație cu schimbarea adreselor nu este o traducere fiabilă.

Notați identitatea așteptată a ambelor părți și acreditarea care o validează. Dacă cele două rânduri nu sunt de acord, nicio ajustare a adreselor nu va produce o potrivire.

Al treilea grup de câmpuri: traficul protejat

Selectoarele descriu intervalele interne de sursă și destinație, familia lor de adrese și orice restricție de protocol sau port. O propunere pentru adresa unei singure gazde nu este aceeași cerere ca pentru o subrețea întreagă, iar un responder configurat pentru subrețea o poate refuza sau restrânge.

Când cele două capete nu sunt de acord, comparați fluxul intenționat din ambele perspective în loc să lărgiți fiecare selector ca să se conecteze ceva. Întrebați fiecare administrator ce flux crede că protejează, apoi comparați cele două răspunsuri. Discrepanța este de obicei un prefix de gazdă pe o parte și o subrețea pe cealaltă. Un tunel care se potrivește pentru că acum protejează tot este o altă decizie de securitate și una pe care nimeni nu a aprobat-o.

Al patrulea grup de câmpuri: citiți o singură implementare

Libreswan, vechiul Openswan și strongSwan au instrumente de administrare diferite, sintaxă de configurare diferită și ordine de potrivire diferită. Un exemplu funcțional dintr-unul nu spune nimic precis despre prioritatea de selecție a profilului sau formularea erorilor celuilalt, așa că verificați cu documentația daemonului de pe această gazdă.

Corelați o încercare de la un capăt la altul: adresa sursă a inițiatorului, identitatea oferită și selectoarele propuse — față de mesajul de selecție al responder-ului și intrarea încărcată pe care o numește. Contoarele de încapsulare și decapsulare la zero spun doar că asocierile observate nu au transportat acele pachete; nu numesc punctul de capăt care a respins propunerea și nu dovedesc că exista o intrare potrivită în acel moment.

După o corecție coordonată, confirmați profilul și asocierea selectate, apoi testați serviciul efectiv permis și calea sa de răspuns. O potrivire de profil permite negocierea, iar negocierea nu este ultima verificare de acces.