A ajunge la un client IKEv2 la IP-ul său virtual atribuit

O poartă trebuie să inițieze o conexiune către un laptop conectat la ea prin IKEv2, folosind adresa virtuală atribuită acelui client. Tunelul este activ, clientul ajunge la tot ce se află în spatele porții, iar direcția inversă tot eșuează. Această asimetrie este normală: politica negociată descrie ce adrese pot vorbi, nu care parte poate iniția. Trei lucruri trebuie să se alinieze înainte ca o cerere inițiată de poartă să funcționeze.

Tunelul nu corectează adresa sursă

Un CHILD SA acoperă o pereche de selectori de trafic, câte unul pe fiecare parte, și permite trafic în ambele direcții ale acelei perechi. Nu spune nimic despre care parte a deschis prima schimbul IKE. O poartă care inițial asculta pentru tunel poate trimite în continuare primul pachet de aplicație, cu condiția ca sursa și destinația alese să cadă în selectorii instalați. Când cererea iese prin interfața greșită, pur și simplu nu este eligibilă pentru tunel.

Rutarea către client este necesară și nu suficientă. Politica trebuie să admită sursa pe care ai folosit-o efectiv.

Citește politica instalată, nu fișierul de configurare

Începe cu asocierea activă și selectorii ei, pentru că alocarea dinamică schimbă ce este instalat în nucleu.

ipsec statusall
ip xfrm policy

Ieșirea de stare numește conexiunea, adresa virtuală atribuită și selectorii valabili în acest moment pentru acea parte. Descărcarea politicii arată aceiași selectori ca stare a nucleului, iar selecția pachetelor chiar pe ea se consultă. Compară selectorul din partea porții cu sursa pe care o va folosi aplicația ta, pentru că o nepotrivire explică imediat eșecul. Citește adresa curentă a clientului și nu una dintr-o sesiune anterioară, pentru că un VIP realocat invalidează politica veche.

Clientul trebuie să asculte unde ajunge pachetul

Chiar și o politică perfectă ajunge la un port închis când serviciul se leagă doar de loopback. Ascultătorul trebuie să fie pe adresa atribuită sau pe o adresă locală generală.

ss -ltnp 'sport = :9090'
iptables -S INPUT

Lista socketurilor arată dacă portul este legat de adresa virtuală, iar regulile paravanului arată dacă sunt acceptate conexiuni noi din sursa protejată. O regulă scrisă pentru conexiuni stabilite nu admite o conexiune pe care o inițiază poarta. Păstrează autentificarea proprie a serviciului, pentru că sosirea prin tunel stabilește doar din ce rețea a venit pachetul. Un client în spatele propriului NAT tot nu are nevoie de redirecționare de port de intrare, pentru că aceste cereri călătoresc în interiorul tunelului existent.

Testează direcția nouă separat

O cerere funcțională de la client la server nu exersează niciodată această cale. Generează cererea din poartă și observă ambele capete.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

Căutarea rutei răspunde ce sursă și ce interfață ar folosi poarta, iar aceasta este valoarea pe care politica trebuie să o admită. Captura ar trebui să arate cererea plecând în interiorul ESP și nu ca TCP simplu pe interfața publică. Pe client, capturează traficul decriptat pentru a confirma sosirea și dacă serviciul a răspuns. Dacă cererea dispare fără ESP pe legătură, suspectează adresa sursă înainte de paravanul clientului.

Repetă testul după o reînnoire de chei sau o reconectare, pentru că VIP-ul se poate schimba. O cale care funcționează doar până la următoarea sesiune nu este o cale funcțională.