Router LAN și client VPN: două dispozitive, două tabele de rutare

Două dispozitive redirecționează pachetul și fiecare își ține propriul tabel. Routerul LAN știe că prefixul îndepărtat aparține clientului VPN, iar clientul VPN știe cum să ajungă la acel prefix prin tunelul său. Configurați doar primul tabel și pachetul ajunge la o mașină fără rută potrivită, așa că iese din nou pe ruta implicită. Aceasta este toată defecțiunea, iar din partea LAN arată ca o buclă de rutare, pentru că aproape este una.

Desenați cele două salturi înainte de a atinge o rută

Luați o schemă ilustrativă: gazde LAN pe 192.168.50.0/24, routerul obișnuit pe 192.168.50.1, un client dedicat pe 192.168.50.15 și un LAN îndepărtat pe 10.60.0.0/24 accesibil doar prin tunelul pe care îl ține acel client. Niciunul dintre cele două intervale private nu se suprapune cu celălalt, iar tunelul are propriul plan de adrese.

Ambele intervale private contează pentru că decid ce dispozitiv poate răspunde. Partea îndepărtată va vedea pachetul venind de la adresa de tunel a clientului, iar răspunsul trebuie să găsească un drum înapoi la 192.168.50.0/24. Dacă este configurat doar sensul de ieșire, cererea poate funcționa în timp ce răspunsul dispare.

Pasul 1: îndreptați routerul spre client, nu spre tunel

Pe routerul LAN, adăugați o rută de destinație al cărei următor salt este adresa LAN a clientului:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Acea înregistrare spune „livrează-l mașinii care poate face tunel”. Nu spune nimic despre cum este construit tunelul și nu înlocuiește ruta proprie a clientului. Pe un router administrat, echivalentul trăiește în pagina de rute statice a dispozitivului; pe un router Linux aparține configurației interfeței care deține LAN-ul, nu unui shell pe care îl veți închide.

Verificați răspunsul celei de-a doua comenzi. Dacă raportează clientul ca gateway și interfața LAN ca device, primul salt este corect, iar restul muncii este pe cealaltă mașină.

Pasul 2: dați clientului o rută proprie pe partea tunelului

Clientul primește acum un pachet pentru 10.60.0.0/24 și își consultă propriul tabel. Dacă configurația tunelului a instalat o rută pentru acel prefix, pachetul continuă criptat. Dacă nu, pachetul corespunde rutei implicite obișnuite și se întoarce la 192.168.50.1, care îl trimite din nou clientului.

Uitați-vă înainte de a adăuga ceva:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

O rută de prefix lipsă în toate tabelele este descoperirea pe care o căutați. Adăugați-o prin configurația proprie a tunelului, astfel încât următoarea reconectare să o reinstaleze; o ip route add manuală dispare odată cu sesiunea și face defecțiunea să revină în cel mai incomod moment. Următorul salt este interfața de tunel sau adresa pe care VPN-ul o atribuie ca partener, în funcție de client, iar adresa partenerului ar trebui să vină din profilul curent, nu dintr-o notă veche.

Bucla, când apare, nu este infinită în practică: TTL scade la fiecare trecere și pachetul moare cu un mesaj de timp depășit. De aceea un traceroute repetat poate sugera un ciclu, în timp ce un client care pur și simplu nu redirecționează aruncă același pachet în tăcere.

Pasul 3: permiteți redirecționarea și alegeți calea de întoarcere

Primirea și redirecționarea sunt permisiuni diferite. net.ipv4.ip_forward=1 pe client permite tranzitul la nivel de kernel, iar o regulă de firewall trebuie totuși să îl permită între interfața LAN și tunel. O regulă care permite accesul la pagina de administrare a clientului nu va permite tranzitul către LAN-ul îndepărtat, iar distincția este ușor de ratat când aceeași gazdă răspunde la ping local.

Partea îndepărtată are problema oglindă. Trebuie să știe că 192.168.50.0/24 este accesibil prin acest client autentificat. Cu OpenVPN asta înseamnă de obicei o rută pe client împinsă de configurația serverului, sau un fișier specific clientului pe server care declară LAN-ul din spatele clientului. Fără ea, LAN-ul îndepărtat fie aruncă răspunsul, fie îl trimite la propria poartă implicită, adică la internet.

Traducerea sursei este alternativa când prefixul LAN nu poate fi anunțat. O regulă masquerade cu scop pe client rescrie sursa în adresa tunelului, iar răspunsurile se întorc atunci în mod natural. Ascunde și care gazdă LAN a făcut cererea, iar singură nu permite părții îndepărtate să inițieze conexiuni spre interior. Alegeți acest compromis deliberat, în loc să adăugați un masquerade general și să descoperiți efectul secundar mai târziu.

Pasul 4: faceți ambele decizii persistente, apoi testați calea reală

Fiecare rută are un proprietar, iar proprietarul este configurația care se regenerează la pornire sau la reconectare. Pe router poate fi o intrare de rută statică; pe client poate fi profilul VPN, NetworkManager sau systemd-networkd. Verificați reconectând tunelul și repornind clientul, apoi citiți tabelul din nou în loc să vă bazați pe modificare.

Păstrați intactă ruta implicită care transportă conexiunea exterioară a tunelului. Înlocuirea ei pentru a „simplifica” configurația rupe calea criptată înainte ca vreun trafic interior să o poată folosi, iar simptomul este un tunel care nu se mai restabilește după schimbare.

Testați de pe un host LAN obișnuit, nu de pe client, pentru că o cerere originată pe client nu exercită niciodată primul salt al routerului. Obțineți un serviciu care există doar în LAN-ul îndepărtat și confirmați corpul răspunsului, apoi priviți contoarele sau jurnalele clientului pentru a vedea tranzitul. Un traceroute interior care arată salturi private dovedește redirecționarea, nu criptarea: calea exterioară este o observație separată, iar doar contoarele interfeței tunelului arată ce a ieșit prin el.