Accesul la LAN prin OpenVPN e stricat? Verifică zonele, rutele și calea de întoarcere

Routerul răspunde pentru că este local. Pentru a ajunge la o mașină din spatele lui sunt necesare o regulă de redirecționare, un prefix pe client și o cale de întoarcere pentru răspuns.

Tunelul raportează o conexiune reușită, pagina routerului însuși se încarcă, iar maparea unității către o mașină din spatele lui tot expiră. Nimic din această combinație nu este contradictoriu: routerul răspunde ca el însuși, iar atingerea a ceva din spatele lui este o altă decizie luată în alt loc. Parcurge verificările de mai jos în ordine și oprește-te la prima defecțiune, pentru că fiecare se sprijină pe cea anterioară. Când toate patru trec, defecțiunea este deasupra tunelului, nu în el.

Ce filtru vede un pachet destinat LAN-ului

Un pachet adresat routerului este consumat local; un pachet adresat unui host din spatele lui trebuie redirecționat, iar firewall-urile judecă aceste două cazuri separat. Prin urmare, permisiunea de a ajunge la router nu spune nimic despre permisiunea de a-l traversa. Firmware-ul care își ascunde seturile de reguli le implementează totuși pe amândouă, de obicei ca un selector care oferă LAN-ul, internetul sau ambele. Dacă selectorul omite LAN-ul, nicio verificare ulterioară nu va conta.

OpenWrt face această împărțire inspectabilă, iar distincția merită o lectură. Zona care încheie tunelul are nevoie de o regulă de redirecționare către zona LAN, în timp ce o regulă de intrare guvernează doar serviciile de pe routerul însuși. O pagină de administrare funcțională lângă un LAN mort este rezultatul obișnuit al acelei reguli de redirecționare lipsă.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Uită-te la ținta de redirecționare a zonei care poartă tunelul: accept este ceea ce are nevoie scara, iar reject explică fiecare expirare de mai jos. Două setări vecine produc același simptom, așa că exclude-le cât timp ești aici. Izolarea wireless ascunde hosturile cablate de clienții wireless, iar un router care tratează hosturile LAN inactive ca offline poate arunca răspunsurile chiar și după ce redirecționarea funcționează.

De ce un tunel divizat are nevoie de prefixul împins

Un client care trimite tot traficul prin tunel are deja prefixul LAN prin ruta sa implicită, așa că nu e nimic de adăugat. Tunelul divizat este cazul care cere prefixul declarat explicit, pentru că nimic altceva din configurație nu îl menționează. Adaugă directiva în configurația serverului și reîncarcă serviciul.

push "route 192.168.50.0 255.255.255.0"

Profilurile care conțin route-nopull ignoră rutele împinse, așa că același prefix aparține fișierului clientului. În orice caz, confirmă că intrarea a ajuns în loc să presupui, pentru că o suprascriere silențioasă arată identic cu o problemă de firewall.

ip route show | grep 192.168.50

Un partener sit-la-sit cere mai mult decât o împingere. Serverul trebuie să afle ce prefixe stau în spatele acelui partener, ceea ce face o linie iroute în fișierul său client-config-dir, iar tabelul propriu are nevoie de o rută corespunzătoare în tunel.

Răspunsul are nevoie de o adresă la care poate ajunge

Redirecționarea cererii este doar jumătate dintr-un schimb, pentru că hostul LAN trebuie să răspundă la o adresă din grupul tunelului. Routerele mici rezolvă de obicei asta traducând sursa pe zona tunelului, astfel încât răspunsul este adresat routerului și nu are nevoie de configurare în altă parte. Scoate acea traducere și hostul are nevoie de propria rută către grup, pe care o primește gratis când routerul este gateway-ul său implicit. Un host cu adresă setată manual și alt gateway răspunde prin acel gateway, iar clientul vede o sesiune care se deschide și apoi se blochează.

tcpdump -ni tun0 host 192.168.50.20

Rulează asta pe router în timp ce clientul își repetă cererea, și citește destinația răspunsului, nu cererea. Un răspuns adresat grupului înseamnă că calea de întoarcere funcționează și că defecțiunea este mai adânc. Niciun răspuns înseamnă că hostul nu a acceptat niciodată pachetul, ceea ce te trimite înapoi la setul de reguli.

O scară care se termină în locul potrivit

Patru verificări localizează stratul, iar fiecare este o singură comandă, nu o judecată. Rulează-le în ordine și oprește-te la prima defecțiune. Ordinea contează mai mult decât comenzile, pentru că un pas ulterior care trece ascunde motivul pentru care unul anterior a eșuat.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Numele aparțin sfârșitului scării, niciodată începutului. O partajare care răspunde ca 192.168.50.20 dar nu ca nas.local indică rezolvarea numelor sau un sufix de căutare, iar modificările din firewall nu pot schimba niciunul.

Notează primul pas eșuat, apoi dă porturilor de serviciu propria rundă, pentru că un ascultător și o permisiune de host sunt cerințe separate. Partajarea fișierelor, desktopul de la distanță și fluxurile camerelor au nevoie de ambele, iar un firewall de host care se încrede în subrețeaua LAN dar nu în grupul tunelului aruncă clientul în timp ce ping-ul încă reușește. Când toate verificările trec și aplicația tot eșuează, defecțiunea este deasupra tunelului: un serviciu legat de o singură interfață sau un proxy configurat pe client.

Articole similare