De ce este subrețeaua din spatele unui client OpenVPN inaccesibilă?

Ping-urile către adresa tunelului serverului reușesc, tabela de rute a clientului arată corect, iar LAN-ul din spatele acelui client rămâne inaccesibil. Tabela de rutare a clientului arată corect, serverul are o rută care indică tunelul, iar pachetele tot dispar. Este simptomul clasic al unui tunel layer-3 care nu știe că unul dintre clienții săi este și o poartă.

O interfață tun nu are următorul salt pentru fiecare client. Kernelul vede o singură interfață cu mulți parteneri, așa că decizia privind clientul care trebuie să primească un pachet pentru un LAN îndepărtat trebuie luată în interiorul procesului OpenVPN. Această decizie se configurează cu iroute, iar fără ea pachetul nu are unde să meargă.

Serverul rutează după client, nu după interfață

Când serverul trebuie să trimită un pachet la adresa tunelului unui client, răspunsul este neechivoc: adresa aparține sesiunii acelui client. Când destinația este o întreagă subrețea din spatele acelui client, adresa nu aparține nimănui pe care serverul îl cunoaște, iar ruta kernelului către tunel spune doar "prin această interfață", fără să spună care partener.

OpenVPN rezolvă acest lucru cu o tabelă de rutare internă care asociază un prefix de destinație unui client anume. Acea tabelă este construită din intrări iroute, de aceea o rută obișnuită pe gazda serverului nu este suficientă. Ruta kernelului duce pachetul la interfața tunelului; asocierea internă decide ce sesiune îl primește. De aceea nici reparația nu apare vreodată în ieșirea de rute a kernelului.

Dacă asocierea lipsește, pachetul ajunge la server, corespunde rutei tunelului și este aruncat pentru că niciun client nu revendică destinația. Nimic nu înregistrează o eroare curată, de aceea defecțiunea arată ca o gaură neagră tăcută, nu ca o buclă de rutare.

Scrierea intrării iroute care numește clientul

iroute locuiește într-un fișier de configurare specific clientului, nu în configurația principală a serverului. Îndreptați serverul către un director cu opțiunea client-config-dir, apoi creați un fișier al cărui nume este numele comun al certificatului clientului și puneți prefixul în el.

Pentru o sucursală al cărei LAN este 10.20.0.0/24 și al cărei nume comun al certificatului este branch-router, fișierul de la acea cale conține o linie precum iroute 10.20.0.0 255.255.255.0. Configurația principală are nevoie doar de opțiunea directorului; prefixul locuiește la client.

Numele comun este partea fragilă. Un certificat emis cu alt subject, sau o implementare care autentifică utilizatorii după numele de utilizator în timp ce fișierul este numit după certificat, produce un fișier care nu este niciodată citit. Verificați numele pe care serverul îl raportează efectiv pentru sesiune și luați în considerare opțiunea care face un client nepotrivit să eșueze în loc să se conecteze în tăcere fără rutele sale. Redenumirea fișierului pentru a corespunde certificatului este o corectare de cinci minute care evită o seară foarte lungă.

Un client poate deține mai multe prefixe. Adăugați o linie iroute pentru fiecare rețea și păstrați lista lângă celelalte setări ale acelui client, astfel încât asocierea să rămână auditabilă.

Construirea căii de întoarcere în ambele sensuri

Aducerea pachetelor la LAN-ul îndepărtat este jumătate din treabă. Clientul trebuie să trimită și traficul acelui LAN în tunel, ceea ce de obicei se face împingând o rută către client: o linie precum push "route 10.8.0.0 255.255.255.0" îi spune fiecărui client cum să atingă rețeaua din partea serverului. Pentru sucursală, ruta echivalentă indică tunelul pentru tot ce trebuie atins în partea serverului.

Sensul de întoarcere are nevoie de un proprietar în partea îndepărtată. Acolo cineva trebuie să cunoască drumul înapoi: o rută statică pe routerul LAN care îndreaptă pool-ul VPN către server, sau traducere de adrese pe server înainte ca traficul să intre în LAN. Ruta statică păstrează adresele originale vizibile în jurnale și în regulile de acces, dar cere cooperarea proprietarului LAN-ului; traducerea este autonomă, dar ascunde cine s-a conectat de fapt.

Redirecționarea trebuie să fie activată pe gazda serverului. Fără ea kernelul acceptă pachetul din tunel și refuză să îl transmită interfeței LAN, ceea ce din perspectiva clientului arată identic cu o iroute lipsă.

Verificarea accesibilității cu sondele potrivite

Testați pe straturi în loc să dați ping la capătul îndepărtat și să ghiciți. De pe server, verificați că asocierea internă pentru prefix există și că ruta kernelului indică tunelul. De pe client, confirmați că ruta împinsă este instalată și că drumul implicit către adresa LAN este tunelul.

Apoi urmăriți pachetele. O captură pe interfața tunelului arată dacă serverul transmite spre client, iar o captură pe interfața LAN arată dacă redirecționează. Dacă prima arată pachete, iar a doua nimic, problema este redirecționarea sau un filtru; dacă niciuna nu arată nimic, căutarea a eșuat mai devreme.

Două servere unite printr-un tunel repetă aceeași regulă pe ambele părți: fiecare are nevoie de o iroute pentru pool-ul celuilalt și fiecare are nevoie de ruta și redirecționarea care fac calea simetrică. Rutarea și politica sunt chestiuni separate aici. Rutarea decide unde poate merge un pachet, în timp ce o regulă FORWARD decide dacă are voie, așa că un client cu două linii iroute atinge ambele prefixe, dacă un filtru nu spune altfel.