Clienții VPN ajung la server dar nu la LAN: care remediere?

Clientul face ping la adresa tunelului serverului OpenVPN și primește răspuns, apoi încearcă o gazdă din LAN-ul serverului și nu primește nimic. Această separare restrânge mult defectul: tunelul este sus, forwardingul probabil funcționează, iar răspunsul iese pe o ușă care nu duce înapoi. Există trei remedieri, iar cea corectă depinde de ce controlați și de ce sunteți dispus să pierdeți. Răspundeți la cele trei întrebări de mai jos în ordine și alegerea nu mai e o chestiune de gust.

Mai întâi, stabiliți care direcție este ruptă

Cererea ajunge pe interfața tunelului cu o adresă sursă din pool-ul VPN. Serverul o trimite mai departe gazdei din LAN, iar acea gazdă răspunde gateway-ului pe care îl indică propriul tabel, de obicei routerul LAN-ului. Dacă routerul nu are rută către pool, răspunsul moare acolo sau rătăcește spre internet.

Testați ambele mașini înainte de a modifica vreuna. Întrebați tabelul de rutare de pe server pe unde ar ajunge la un client; întrebați gazda din LAN cum ar ajunge la aceeași adresă. Prima căutare indică de obicei tunelul, iar a doua routerul LAN-ului, și această diferență este defectul într-o singură linie. Două căutări costă mai puțin decât un audit de firewall și stabilesc direcția problemei.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Dacă gazda din LAN indică deja serverul VPN, problema dvs. este o regulă de firewall sau o limită MTU, nu o cale de întoarcere lipsă. Nu adăugați o rută ca să reparați un filtru.

Întrebarea unu: puteți edita routerul LAN-ului îndepărtat?

Când routerul LAN-ului este al dvs., răspunsul curat este o rută statică spre pool-ul VPN cu adresa LAN a serverului VPN ca următor salt. Ea păstrează intacte adresele sursă ale clienților, ceea ce contează când gazdele din LAN înregistrează, filtrează sau limitează viteza după adresă. Nu are nevoie nici de traducere pe server, așa că tunelul rămâne o cale pură de rutare. Obligația pe care o creează este documentarea, fiindcă pool-ul, ruta și configurația serverului trebuie să fie de acord.

Ea eșuează în tăcere în ziua în care cineva schimbă pool-ul. Notați valoarea o dată și tratați o modificare în oricare dintre cele trei locuri ca o modificare în toate trei.

Un NAS sau un switch de nivel 3 care găzduiește serviciul are nevoie de aceeași rută, dacă nu trimite totul printr-un router care o are. Verificați dispozitivul care termină subrețeaua, nu doar pe cel orientat spre internet. Rețelele mici au adesea trei dispozitive cu o părere despre rutare.

Întrebarea doi: poate LAN-ul să nu mai vadă adresele clienților?

Când routerul aparține altcuiva, traducerea pe serverul VPN nu cere cooperare. Gazda din LAN vede adresa LAN a serverului, îi răspunde, iar serverul traduce înapoi. De aceea aparatele și rolurile de acces la distanță bazate pe NAT se comportă astfel.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Costul este atribuirea: adresele pe client dispar din jurnalele LAN-ului. Orice listă de permisiuni de pe gazda din LAN trebuie atunci să numească serverul în locul pool-ului.

Alegeți traducerea când cooperarea nu este disponibilă, nu când este doar incomodă. Ea ascunde clientul de orice investigație viitoare, inclusiv de cele în care trebuie să știți ce laptop a deschis o conexiune. Poate strica și protocoale care încorporează adrese în payload, fiindcă traducerea trăiește în antet. Niciuna dintre opțiuni nu e mai avansată; ele răspund la întrebări diferite despre proprietate.

Întrebarea trei: este serverul însuși client al altui tunel?

Imaginați-vă cealaltă topologie: serverul VPN apelează și un furnizor comercial, deci are două tuneluri și două seturi de adrese. Traficul pe care îl trimite pentru propriii clienți iese prin furnizor, care nu va ruta răspunsurile înapoi la adresele pool-ului. De aceea răspunsurile dispar deși ambele tuneluri sunt sănătoase.

Remedierea este să mascați și tunelul de ieșire, astfel încât furnizorul să vadă doar adresa tunelului serverului. Direcția inversă are nevoie de propria regulă, fiindcă serverul care inițiază o conexiune către unul dintre clienții săi este un alt flux. Fără acea regulă, clientul răspunde unei adrese pe care nu o poate ruta. Puneți regula îngustă înaintea oricărei mascări largi, ca traducerea specifică să câștige.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Gazdele cu mai multe interfețe adaugă un defect înrudit care arată identic din partea clientului. Răspunsul iese prin interfața cu metrica mai mică pentru că adresa sursă a fost aleasă din alt tabel. Verificați calea de întoarcere cu o căutare, în loc să presupuneți că cea de dus o implică.

Apoi verificați ambele direcții și ambele dimensiuni

După modificare, faceți ping de la client la o gazdă din LAN și apoi de la gazda din LAN la client. A doua direcție este cea pe care lumea o sare, și ea este cea care expune o regulă de traducere incompletă. Notați ambele rezultate cu marcă de timp, ca o regresie ulterioară să fie comparabilă.

Apoi mutați date reale, fiindcă un ping mic care reușește în timp ce un transfer mare se blochează este un simptom MTU. Acel defect apare imediat după ce vă felicitați pentru că ați reparat ruta.

În final, retestați după o repornire. Comenzile de rută și firewall din timpul rulării nu supraviețuiesc, iar o remediere care dispare la următoarea pornire va fi diagnosticată din nou de cineva cu mai puțin context. Faceți modificarea permanentă așa cum face deja sistemul dvs., apoi reporniți o dată intenționat.