De ce administrarea routerului nu mai răspunde după o schimbare de VPN

Ai schimbat o rută sau o regulă de firewall ca să testezi un tunel pe router, iar acum pagina de administrare nu mai răspunde de pe laptopul care funcționa bine acum zece minute. Reflexul este să dai vina pe VPN. De cele mai multe ori tunelul este sănătos și s-a stricat unul din trei alte lucruri: nu există rută înapoi la adresa routerului însuși, o politică de intrare aruncă cererea, sau un serviciu web nu ascultă pe adresa pe care o apelezi. Toate trei arată la fel în browser, de aceea oamenii repornesc tunelul o oră și nu învață nimic.

Iată mitul care merită ucis primul: un tunel care funcționează nu este o cale de întoarcere înăuntru. Este o conexiune de rețea nouă, cu propriile întrebări de încredere, și poate elimina în tăcere vechea cale de administrare în timp ce deschide una nouă pe care nimeni nu a verificat-o.

Tunelul nu a fost niciodată calea de administrare

Redirecționarea și intrarea sunt lucruri diferite. „Poate un client să ajungă la NAS prin tunel?” este o întrebare de redirecționare despre pachete care trec prin router. „Pot deschide portul SSH al routerului?” este o întrebare de intrare despre pachete adresate routerului însuși. O regulă de permitere scrisă pentru trafic redirecționat nu face nimic pentru a doua, și acesta este cel mai frecvent motiv pentru care un tunel care transportă traficul perfect refuză totuși sesiunea ta de administrare.

Greșeala inversă este să ai încredere într-un nume de interfață. Un tunel este criptat către partener, nu către fiecare serviciu din spatele lui, iar cuvântul VPN de pe o etichetă de interfață nu spune nimic despre ce surse ar trebui să se poată autentifica.

Primul nivel: există o rută către adresa routerului însuși?

Începe pe client și întreabă nucleul încotro va merge pachetul. Pe Linux, ip route get 10.6.0.1 tipărește ruta aleasă, interfața de ieșire și adresa sursă. Dacă raportează ruta implicită către furnizorul tău, pachetul nu intră niciodată în tunel, iar nicio regulă de pe router nu îl poate salva.

Partea tunelului are propria versiune a întrebării. WireGuard tratează AllowedIPs ca pe un tabel de rutare cu cheie criptografică: la fiecare capăt declară ce adrese sursă poate folosi un partener și ce destinații sunt trimise către acel partener. Dacă intrarea clientului nu include adresa de tunel a routerului, clientul nu are rută către ea. Dacă intrarea serverului pentru acel client nu acoperă adresa de tunel a clientului, serverul aruncă pachetul înainte de a se uita la vreo regulă de firewall.

Confirmă adresa exactă pe care speri să o atingi înainte de a depana politica. O înregistrare DNS veche sau o intrare de vecin din cache de dinainte de schimbare te trimite la o adresă pe care routerul nu a avut-o niciodată.

Al doilea nivel: politica de intrare, nu politica de redirecționare

Firewallurile evaluează regulile pe interfața pe care sosește pachetul. În pfSense și OPNsense, fila interfeței și ordinea regulilor decid dacă traficul către serviciile firewallului însuși este permis; o regulă care lasă clienții LAN să iasă pe internet nu este o regulă care permite unui partener de tunel să deschidă interfața web. În OpenWrt cu firewall4, fiecare zonă poartă o politică de intrare, option input 'ACCEPT' sau 'REJECT', iar o interfață de tunel într-o zonă cu intrare REJECT va refuza conexiunile de administrare, continuând însă să redirecționeze traficul dacă redirecționarea este permisă.

Nu dezactiva regula anti-blocare pentru ca noua cale să funcționeze. Acea regulă împiedică o regulă proastă să blocheze adresa de administrare LAN; protejează subrețeaua LAN, nu subrețeaua tunelului pe care tocmai ai creat-o. Adaugă o singură regulă îngustă pentru sursa administratorului și lasă plasa de siguranță în pace. Documentația pfSense despre accesul de administrare explică unde se află acele controale.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Al treilea nivel: ascultă ceva pe acea adresă?

Un serviciu poate rula și totuși să fie inaccesibil pentru că s-a legat de o singură adresă. uhttpd din OpenWrt păstrează intrări explicite de ascultare în /etc/config/uhttpd, de exemplu list listen_http '0.0.0.0:80'; o compilare care se leagă doar de adresa LAN nu acceptă nimic pe adresa tunelului, iar produsele care expun o setare de interfață de ascultare se comportă la fel. Comenzile de ascultare de mai sus răspund direct la asta.

Apoi separă refuzul de tăcere. nc -vz 10.6.0.1 443 care returnează o conexiune refuzată înseamnă că pachetul a ajuns la router și ceva l-a respins, fie un port închis, fie o regulă explicită de respingere. Agățarea până la expirarea timpului înseamnă că pachetul a fost aruncat sau nu a fost niciodată rutat. Această distincție îți spune ce nivel să inspectezi în continuare și costă cinci secunde.

O interfață VPN este o graniță, nu o cale de recuperare

Criptarea protejează cablul; nu spune nimic despre cine poate deschide pagina de administrare. Odată ce tunelul funcționează, rezistă impulsului de a rezolva accesibilitatea permițând totul pe interfața tunelului. Dă administratorilor o regulă legată de propria adresă de tunel sau un tunel separat doar pentru administratori, și ține utilizatorii obișnuiți, NAS-ul, camerele și laptopurile familiei departe de portul de administrare. Un partener care are nevoie de partajare de fișiere nu ar trebui să fie la o regulă distanță de autentificarea în router.

Rolul routerului schimbă răspunsul. Un router care termină tunelul poate accepta legitim administratori din el, în timp ce un router care folosește tunelul doar ca ieșire spre internet de obicei nu ar trebui. În ambele cazuri permisiunea de subrețea nu este autentificarea, așa că lasă activate autentificarea contului și securitatea transportului.

Mișcarea compensatorie pe care o fac oamenii după o blocare este mai rea: activarea administrării prin WAN sau redirecționarea unui port către interfața web. Asta transformă o întrerupere scurtă într-o expunere permanentă, iar pagina de autentificare devine atunci accesibilă oricărui scaner din internet. Testează și partea refuzată, nu doar pe cea permisă, ca un partener care nu ar trebui să aibă acces de administrator să primească expirare sau refuz în loc de o cerere de autentificare.

Testează și cu o conexiune nouă. Un firewall cu stare păstrează fluxurile existente în tabelul său de stări, așa că sesiunea SSH deja deschisă poate supraviețui unei schimbări care blochează orice conexiune nouă. Așa rămâne o blocare invizibilă până la următoarea repornire sau următoarea adormire a laptopului.

Pregătește calea de întoarcere înainte de a atinge politica

Notează patru lucruri înainte de prima schimbare: cum vei ajunge la dispozitiv dacă tunelul moare, de exemplu o consolă serială, o consolă a furnizorului sau o mașină în LAN; unde este exportată configurația actuală; ce singură regulă sau rută vei modifica; și cum vei reveni exact la acel element. În OpenWrt, sysupgrade -b /tmp/backup.tar.gz capturează configurația, iar modificările rămân în așteptare până la uci commit, ceea ce îți dă o anulare ieftină dacă observi la timp. pfSense ține un istoric al configurației, iar AutoConfigBackup ajută doar dacă era deja activat. Dacă routerul rulează un set de reguli fail-closed, confirmă că calea de mentenanță planificată nu se află în traficul blocat de acea regulă și ține minte că o repornire reaplică regulile persistente în loc să le șteargă.

Schimbă o graniță pe încercare, apoi testează dintr-o conexiune nouă în loc de shell-ul pe care îl ții deschis. Dacă testul eșuează, revino asupra acelei singure schimbări înainte de a atinge nivelul următor. Tunelul poate rămâne sus tot timpul, dar pictograma verde de stare nu este dovada că mai poți intra.

Verificare rapidă înainte de a pleca:

• Poți ajunge la router dintr-o sursă care nu depinde de regula pe care tocmai ai editat-o?
• Politica de intrare pe interfața tunelului permite doar sursa administratorului?
• Serviciul de administrare este legat de o adresă care există pe tunel?
• Ai testat un partener refuzat și o sesiune nouă?
• Suprafața de administrare prin WAN este încă închisă?