Conectat la OpenVPN dar fără ping sau partajare SMB? Verificați trei porți

Tunelul urcă, clientul primește o adresă și nimic din LAN-ul îndepărtat nu răspunde. Pingul eșuează, partajarea nu se deschide și jurnalul VPN arată curat pentru că, din punctul lui de vedere, sesiunea este sănătoasă. Între acea sesiune și un fișier de pe un server stau trei porți independente: politica de redirecționare, porturile de care are nevoie serviciul și numele pe care l-ați tastat în locul unei adrese.

Fiecare poartă eșuează cu un simptom diferit, iar doar prima este pe serverul VPN.

Redirecționarea este o politică pe lanțul FORWARD

Acceptarea listener-ului OpenVPN are loc pe INPUT, de aceea tunelul se poate conecta în timp ce fiecare pachet îndreptat spre LAN este aruncat. Traficul care sosește pe tun0 și iese prin interfața LAN trece prin FORWARD, iar un host cu politică DROP implicită îl aruncă acolo în tăcere. Verificați atât sysctl, cât și lanțul înainte de a atinge orice altceva: sysctl net.ipv4.ip_forward și iptables -L FORWARD -v -n.

Permiteți direcția dorită și răspunsurile care îi aparțin, de exemplu o regulă accept de la interfața tunelului la interfața LAN plus o regulă stateful pentru traficul established și related. Dacă LAN-ul se află în spatele altui router, acel router are nevoie de o rută înapoi spre pool-ul de clienți sau de un source NAT pe serverul VPN. Confirmați acel drum cu un singur ping înainte de a adăuga mai multe reguli, pentru că o regulă care nu poate fi atinsă nu apare niciodată într-un contor.

SMB are nevoie de mai mult de un port

Partajarea fișierelor nu este o singură conversație TCP 445. Descoperirea folosește UDP 137 și 138, sesiunile NetBIOS mai vechi folosesc TCP 139, iar sesiunile SMB moderne folosesc TCP 445. O regulă care deschide doar 445 produce cazul enervant în care o unitate mapată funcționează și navigarea în rețea nu, sau invers.

Transferurile mari prin tunel lovesc și probleme MSS care arată ca o partajare stricată. Un SYN care anunță dimensiunea completă a segmentului LAN este aruncat de MTU-ul mai mic al tunelului, iar conexiunea rămâne blocată după handshake. Limitarea MSS pe calea de redirecționare, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, elimină acel tip de blocaj. Verificați cu o copie de câțiva megabaiți în loc de o listare de director, pentru că răspunsurile mici trec chiar și când transferurile mari nu trec.

Adaptorul tunelului apare ca un profil de rețea nou

Windows clasifică fiecare adaptor într-un profil de rețea, iar un adaptor de tunel nou ajunge de obicei în Public, unde regulile de partajare a fișierelor și imprimantelor sunt blocate. Aceasta este o decizie a firewall-ului gazdă de pe serverul de fișiere, nu o problemă de rutare pe serverul VPN. Schimbați categoria în mod deliberat cu Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private după ce confirmați că politica permite acest lucru, pentru că categoria schimbă și ce reguli de intrare se aplică.

Același profil explică un ping care eșuează în timp ce TCP 445 reușește: cererile echo sunt aruncate în Public în mod implicit.

Numele nu traversează singure un tunel rutat

Rezolvarea numelor NetBIOS și descoperirea locală se bazează pe difuzări pe care un tunel rutat nu le transportă. De aceea tastarea numelui scurt al serverului eșuează în timp ce adresa lui funcționează, iar partajarea pare stricată când doar căutarea este. Adăugați o înregistrare DNS pentru server la resolverul pe care tunelul îl distribuie, sau folosiți adresa în scurtătură.

Dacă implementarea depinde încă de WINS, configurați-l pe client în loc să sperați că va apărea trafic de difuzare. Testați mai întâi după adresă, ca o eroare de nume să nu fie confundată cu o eroare de firewall.

Testați un singur strat odată și citiți prima eroare

Urcați: faceți ping la gateway-ul tunelului, faceți ping la un host din LAN după adresă, apoi deschideți portul serviciului cu Test-NetConnection -ComputerName 10.8.0.5 -Port 445, și abia apoi autentificați-vă la partajare. Primul pas care eșuează este stratul de reparat, iar fiecare pas următor este zgomot până când acela trece. Un ping care răspunde în timp ce portul rămâne închis indică firewall-ul propriu al serverului de fișiere, în timp ce un port care se deschide în ciuda pingurilor tăcute indică filtrarea ICMP. Notați primul pas care eșuează înainte de a schimba ceva, pentru că o a doua schimbare ascunde rezultatul primei.

Dacă serverul VPN nu este routerul LAN-ului, confirmați ruta de întoarcere pe acel router înainte de a adăuga mai multe reguli pe server. Fără ea, cererile ajung la host iar răspunsurile pleacă pe ruta implicită spre internet, ceea ce din partea clientului arată exact ca o aruncare a firewall-ului.

Păstrați contul de partajare separat de autentificarea VPN în notițele dumneavoastră, pentru că un tunel reușit nu spune nimic despre permisiunile fișierelor. Expunerea SMB la internet pentru a ocoli o regulă lipsă nu este o soluție.