OpenVPN iroute sau ruta kernel: care lipsește?

Un pachet către 10.77.20.0/24 ia două decizii separate pe un server OpenVPN: sistemul de operare trebuie să îl predea interfeței VPN, iar OpenVPN trebuie să știe care client conectat deține acel prefix. O rută kernel lipsă îl aruncă înainte de tunel, iar o rută peer lipsă îl aruncă după. Cele două eșecuri arată identic din LAN-ul îndepărtat, iar diagnosticarea celui pe care îl aveți cere o comandă pe fiecare parte.

În traseul de date clasic din spațiul utilizator, ruta kernel aduce pachetul în procesul tunelului, iar iroute îi spune acelui proces ce peer trebuie să îl primească. Niciuna nu o înlocuiește pe cealaltă, iar o configurație care o conține doar pe una va părea rezonabilă până la primul ping.

Două decizii, nu o singură rută

Imaginați-vă o legătură între situri în care 10.77.20.0/24 se află în spatele unui singur client. Ruta kernel a serverului, de exemplu ip route add 10.77.20.0/24 dev tun0, trimite pachetele potrivite către dispozitivul tunelului. Apoi OpenVPN consultă propria tabelă internă, construită din intrările iroute din directorul de configurare al clientului, pentru a decide ce conexiune peer le primește. Fără ruta kernel pachetul nu ajunge niciodată la proces, iar fără ruta peer ajunge la proces și nu merge nicăieri.

Această separare se uită ușor, pentru că o singură linie de rută într-un profil de client poate părea că face ambele treburi. Nu le face: împingerea unei rute le spune clienților ce să trimită prin tunel, în timp ce iroute îi spune serverului cine deține un interval de adrese în spatele unui client. Ele trăiesc în fișiere diferite, sunt citite de părți diferite și eșuează în direcții opuse.

Unde aparține iroute și ce spune

Intrarea merge într-un fișier per client numit după common_name-ul clientului, în client-config-dir, ca iroute 10.77.20.0/24. Potrivirea numelui fișierului nu este cosmetică: OpenVPN caută identitatea autentificată și citește fișierul exact cu acel nume, așa că un fișier numit site-a are efect doar pentru un client al cărui nume comun este site-a. Adăugați ccd-exclusive dacă clienții fără un astfel de fișier trebuie refuzați complet, ceea ce este setarea corectă atunci când fiecare client este o poartă de sit. Păstrați un fișier per poartă și numiți-l după subiectul certificatului pe care îl emiteți efectiv.

Testați intrarea de pe server înainte de a da vina pe LAN-ul îndepărtat. Fișierul de stare listează clienții conectați cu numele lor comune, iar un server care rulează cu --verb 4 înregistrează instalarea iroute în momentul în care peer-ul se conectează. Dacă nu apare nimic la conectare, fișierul este în directorul greșit sau numește identitatea greșită.

Capcana: fișierul există, identitatea este greșită

Un iroute care arată corect, dar este atașat peer-ului greșit, pierde mai mult timp decât un fișier lipsă, pentru că totul pe disc pare în regulă. Redenumirea certificatelor, numele comune duplicate și username-as-common-name care schimbă identitatea efectivă le produc pe toate. Verificați ce identitate a autentificat serverul, nu pe cea pe care o așteptați: ieșirea de stare este autoritară, în timp ce numele fișierului este doar o cheie de căutare.

O rută poate supraviețui proprietarului ei. Rutele statice și intrările iroute descriu un prefix, nu o garanție de disponibilitate, așa că traficul poate continua să fie direcționat către un peer care este acum deconectat.

Finalizați traseul dincolo de peer

Proprietatea peer-ului este mijlocul traseului, nu sfârșitul. Clientul trebuie să transmită pachetele din tunel în propriul LAN, ceea ce înseamnă redirecționare IP activată pe acel host și o regulă de firewall care permite tranzitul. Gazdele din LAN-ul îndepărtat au nevoie de o cale de întoarcere pentru adresa tunelului: fie o rută care indică înapoi spre poartă, fie un design NAT deliberat pe partea clientului. Confirmați setarea de redirecționare pe client cu sysctl net.ipv4.ip_forward în loc să presupuneți o valoare implicită a distribuției.

Dacă alți clienți VPN trebuie să ajungă la acea subrețea, aranjamentul crește din nou: serverul are nevoie de client-to-client, iar acei clienți trebuie să ruteze prefixul prin tunel. Nimic din toate acestea nu reiese din propria tabelă de rutare a serverului.

Verificați o destinație dintr-o sursă reală în loc de serverul însuși. Un ping de la un host LAN nelegat la un host din spatele clientului exersează calea de întoarcere, regula de redirecționare și proprietatea peer-ului într-o singură mișcare, în timp ce un handshake reușit dovedește doar identitatea. Apoi deconectați peer-ul proprietar și notați ce face ruta, pentru că acel răspuns este modul dumneavoastră de eșec.