Cum funcționează IPsec bazat pe rute cu o interfață XFRM

IPsec bazat pe rute încredințează tabelului de rutare o decizie pe care o luau anterior selectorii de politică. În Linux, partea care face acest lucru posibil este interfața XFRM: un dispozitiv virtual al cărui trafic este potrivit cu starea IPsec printr-un identificator de interfață, nu printr-un selector. Crearea uneia cere o singură comandă și nu demonstrează nimic despre existența unui tunel. Dispozitivul este un cârlig între rutare și politica de securitate, iar ambele părți ale acelui cârlig trebuie configurate înainte ca ceva să fie protejat.

Ce este dispozitivul și ce nu este

O interfață XFRM este un mâner de rutare. Pachetele rutate în ea sunt potrivite cu politici XFRM care fac referire la același identificator de interfață, iar dacă există o politică și o stare, ele sunt încapsulate. Fără ele, interfața există, contoarele stau pe loc, iar traficul merge într-un loc inutil.

Aceasta este prima separare diagnostică. O rută în dispozitiv este un fapt de rutare, o stare instalată este un fapt de securitate, iar un contor care crește pe dispozitiv nu este nici una, nici alta. Când oamenii spun că tunelul este sus pentru că interfața arată UP, descriu steagurile de legătură ale unui dispozitiv virtual care nu are un partener propriu. Steagul înseamnă că dispozitivul a fost creat și activat, nimic mai mult.

Încă o limită: identificatorul de interfață nu este un nume. Două dispozitive cu nume asemănătoare și identificatori diferiți nu partajează stare, iar o conexiune configurată cu identificatorul greșit instalează o stare pe care nicio rută nu o va folosi vreodată.

Construiește una în ordinea corectă

Începe cu dispozitivul exterior și cu un număr pe care îl vei pune și în configurația daemonului. Exemplul folosește eth0 ca interfață exterioară și 42 ca identificator, adrese pe care ar trebui să le înlocuiești cu ale tale.

Ridică dispozitivul, apoi confirmă identificatorul înregistrat de kernel înainte de a atinge configurația VPN:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

Acum configurează conexiunea în strongSwan cu același identificator, deoarece daemonul trebuie să instaleze politici și stări care fac referire la acesta. Setează selectorii de trafic local și la distanță la intervalul pe care intenționezi să îl rutezi, apoi rutează acel interval în dispozitiv. Configurația daemonului și tabelul de rutare trebuie să cadă de acord atât asupra identificatorului, cât și asupra destinațiilor, iar niciuna nu o furnizează pe cealaltă.

Ține IKE și ESP în afara rutei tunelului

O rută implicită îndreptată în dispozitivul XFRM captează atât pachetele încapsulate, cât și traficul pe care îl transportă. Rezultatul este o buclă: gateway-ul încearcă să trimită propriul ESP prin tunelul pe care ESP ar trebui să îl construiască.

Soluția este o rută mai specifică pentru adresa exterioară a partenerului prin interfața fizică, care învinge ruta implicită pentru că se potrivește pe mai mulți biți. Rutarea bazată pe marcaje face aceeași treabă atunci când mai multe tuneluri împart un tabel, iar strongSwan documentează ambele abordări pentru implementările bazate pe rute.

Orice ai alege, verifică faptul că pachetul exterior iese neîncapsulat. O verificare rapidă este să dai ping la adresa exterioară a partenerului după ce tunelul este sus; dacă eșuează în timp ce interfața este sus, suspectează capturarea, nu accesibilitatea. Același raționament se aplică portului IKE, deoarece traficul UDP al daemonului însuși nu trebuie rutat în dispozitivul pe care încearcă să îl stabilească.

Verifică contoarele în două locuri înainte de a da vina pe criptare

Contoarele de interfață și contoarele de stare măsoară etape diferite. Pachetele rutate în dispozitiv cresc dispozitivul chiar și atunci când nicio stare nu se potrivește, în timp ce contoarele de stare se mișcă doar pentru traficul care a fost efectiv încapsulat.

Citește ambele, apoi citește viziunea daemonului asupra asocierii copil:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

Contoarele dispozitivului care cresc cu o ieșire de stare goală înseamnă că rutarea funcționează și politica nu se potrivește, de obicei o greșeală de identificator sau de selector. Contoarele de stare care cresc în timp ce partea îndepărtată nu raportează nimic înseamnă că pachetele pleacă, dar nu ajung sau eșuează autentificarea, ceea ce indică calea sau configurația partenerului. O asociere copil listată fără trafic este o problemă de selector la un capăt, nu un cifru stricat.

Decide cine instalează rutele

Doi proprietari pentru un tabel de rutare sunt sursa obișnuită de flapping. Dacă daemonul instalează rutele automat, managerul tău de rețea nu trebuie să instaleze și el o rută implicită prin același dispozitiv, iar o rută manuală adăugată de un script de pornire va fi eliminată la următoarea reconfigurare a daemonului.

Alege un proprietar și notează-l. Când daemonul deține rutele, ține scriptul de pornire în afara tabelului și lasă definiția conexiunii să descrie selectorii de trafic. Când le deține managerul de rețea, dezactivează instalarea automată și acceptă că daemonul nu va repara o rută lipsă la reconectare.

Regulile de redirecționare și de firewall sunt o decizie separată deasupra, deoarece un gateway care lasă să treacă traficul altor gazde are nevoie de amândouă. IPsec bazat pe rute face acel trafic ușor de exprimat cu instrumente obișnuite de rutare; nu face stratul de politică opțional.