Modul trap din strongSwan: de ce tunelul IPsec așteaptă trafic

În ieșirea de stare nu apare niciun CHILD SA, tunelul pare mort, iar apoi un ping către subrețeaua îndepărtată îl ridică. Într-o configurație IPsec la cerere, această secvență este proiectul, nu o defecțiune. O politică trap instalează un selector și așteaptă, iar primul pachet care se potrivește pornește IKE și negocierea CHILD SA.

O parte a confuziei ține de vocabular: „up” este folosit pentru două stări diferite. Configurația este încărcată și politica kernelului există, dar asocierea de date nu. Un monitor care numără doar SA active va raporta un site sănătos ca indisponibil atât timp cât nimeni nu trimite trafic către el.

Un tunel inactiv la cerere nu are niciun CHILD SA de arătat

O intrare trap nu autentifică nimic prin ea însăși. Cere kernelului să țină o politică pentru traficul selectat și să ridice o acquisition atunci când un pachet are nevoie de acea politică. Daemonul primește acquisition, o potrivește cu definiția child și negociază de acolo. Până atunci nu există nici IKE SA de arătat, de aceea ambele liste pot fi goale simultan.

Această ordine face logurile lizibile. Mai întâi vine acquisition, apoi IKE_SA_INIT și IKE_AUTH, apoi CHILD SA. Dacă logul se termină imediat după acquisition, declanșatorul a funcționat. Negocierea a eșuat, iar următoarea întrebare este despre acreditări, propuneri sau accesibilitate, nu despre trap.

Cu backendul kernelului Linux poți vedea politica înainte ca vreun SA să existe. Rulează ip xfrm policy și caută selectorul cu direcția out și un șablon care indică conexiunea. Acea intrare este starea la cerere, iar prezența ei este primul lucru de confirmat.

start_action decide dacă ceva așteaptă măcar

Fiecare child din swanctl.conf are un start_action. start pornește când se încarcă configurația, trap instalează politica și așteaptă, iar none lasă inițierea altcuiva. Doar trap produce comportamentul „ping și urcă” descris mai sus.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

Cei doi selectori de trafic definesc ce contează ca interesant, iar un pachet de la un host din afara acestor prefixe nu declanșează trap; este rutat ca de obicei. Lărgirea selectorilor pentru un declanșator mai dornic lărgește și domeniul pe care tunelul susține că îl protejează, așa că derivă-i din traficul pe care chiar vrei să-l criptezi.

Referința swanctl.conf enumeră valorile acceptate, împreună cu acțiunile separate close și DPD care guvernează ce se întâmplă odată ce SA există.

Află dacă declanșatorul a fost declanșat

Începe cu swanctl --list-conns și confirmă că child este încărcat cu acțiunea dorită. Apoi trimite un pachet de la un host din local_ts către o adresă din remote_ts și urmărește swanctl --list-sas. Dacă ieșirea nu se schimbă, nicio acquisition nu a ajuns la daemon.

Două motive obișnuite pentru un trap tăcut: pachetul a trecut prin source-NAT înainte de a atinge politica și nu mai corespunde cu local_ts, sau conexiunea nu s-a încărcat niciodată din cauza unei erori de sintaxă sau de acreditări. Rulează din nou swanctl --load-all și citește ieșirea înainte de a atinge selectorii. O conexiune care nu s-a încărcat nu instalează nicio politică, așa că nu există nimic pentru trafic să declanșeze.

Și direcția contează: un trap instalat pentru trafic de ieșire nu pornește pe un pachet de intrare. Dacă partea îndepărtată trebuie să ridice tunelul, are nevoie de propriul trap, sau această parte are nevoie de start.

A aștepta primul pachet nu este întotdeauna schimbul corect

Sesiunile interactive simt costul configurării. Prima cerere plătește schimbul IKE și negocierea CHILD, iar un client cu termen scurt poate renunța înainte ca SA să existe. Un start proactiv elimină acea întârziere a primului pachet. Dar ține un tunel ridicat pentru trafic care poate nu va sosi niciodată.

Trei fapte decid alegerea: cât de des este folosită calea, dacă prima cerere are un termen strâns și dacă peer-ul este accesibil la pornire. Traficul ocazional în loturi și un peer care poate fi offline la pornire favorizează ambele trap. Un client sensibil la latență și un peer mereu accesibil favorizează start. Dacă ambele părți pot iniția, stabiliți cine deține declanșatorul, ca să nu aveți negocieri duplicate.

O politică instalată nu este nici garanție împotriva scurgerilor. Dacă cerința este fail-closed, firewallul trebuie să elimine traficul fără SA, iar acea regulă trăiește în afara definiției child.

Notează cele trei linii care încheie următoarea discuție

Scrie selectorii, acțiunea de pornire și ieșirea comenzii care arată politica prezentă fără SA. Acele trei linii separă „la cerere și inactiv” de „nu se încarcă” data viitoare când cineva raportează tunelul ca indisponibil. Durează un minut să le capturezi. Fără ele, aceeași investigație reîncepe de la zero.

Testează de pe un host care este cu adevărat în interiorul selectorului. Un ping de pe routerul însuși urmează adesea o altă cale și nu dovedește nimic despre politica ce protejează subrețeaua din spatele lui.