Varför routerns admin slutar svara efter en VPN-ändring

Du ändrade en rutt eller en brandväggsregel för att testa en tunnel på routern, och nu svarar inte admin-sidan från datorn som fungerade fint för tio minuter sedan. Reflexen är att skylla på VPN:en. Oftast är tunneln frisk och en av tre andra saker har gått sönder: ingen rutt tillbaka till routerns egen adress, en ingångspolicy som släpper förfrågan, eller en webbtjänst som inte lyssnar på adressen du anropar. Alla tre ser likadana ut i webbläsaren, därför startar folk om tunneln i en timme och lär sig inget.

Här är myten som är värd att döda först: en fungerande tunnel är inte en väg tillbaka in. Den är en ny nätverksanslutning med sina egna tillitsfrågor, och den kan tyst ta bort din gamla administrationsväg medan den öppnar en ny som ingen har granskat.

Tunneln var aldrig administrationsvägen

Vidarebefordran och ingång är olika jobb. ”Kan en klient nå NAS:en genom tunneln?” är en vidarebefordringsfråga om paket som passerar routern. ”Kan jag öppna routerns SSH-port?” är en ingångsfråga om paket som är adresserade till routern själv. En tillåtelseregel skriven för vidarebefordrad trafik gör ingenting för den andra, och det är den vanligaste orsaken till att en tunnel som bär trafik perfekt ändå avvisar din admin-session.

Det motsatta misstaget är att lita på ett gränssnittsnamn. En tunnel är krypterad till peeren, inte till varje tjänst bakom den, och ordet VPN på en gränssnittsetikett säger ingenting om vilka källor som bör få logga in.

Nivå ett: finns det en rutt till routerns egen adress?

Börja på klienten och fråga kärnan vart paketet ska gå. På Linux skriver ip route get 10.6.0.1 ut den valda rutten, utgående gränssnitt och källadress. Om den rapporterar standardrutten mot din leverantör kommer paketet aldrig in i tunneln, och ingen regel på routern kan rädda det.

Tunnelsidan har sin egen version av frågan. WireGuard behandlar AllowedIPs som en kryptonyckel-rutningstabell: i varje ände deklarerar den vilka källadresser en peer får använda och vilka mål som skickas till den peeren. Om klientposten inte innehåller routerns tunneladress har klienten ingen rutt dit. Om serverposten för den klienten inte täcker klientens tunneladress släpper servern paketet innan någon brandväggsregel ses.

Bekräfta den exakta adress du förväntar dig att nå innan du felsöker policyn. En inaktuell DNS-post eller en cachad granpost från före ändringen skickar dig till en adress som routern aldrig har ägt.

Nivå två: ingångspolicyn, inte vidarebefordringspolicyn

Brandväggar utvärderar regler på gränssnittet där paketet anländer. På pfSense och OPNsense avgör fliken för gränssnittet och regelordningen om trafik till brandväggens egna tjänster är tillåten; en regel som släpper ut LAN-klienter på internet är inte en regel som låter en tunnel-peer öppna webbgränssnittet. På OpenWrt med firewall4 bär varje zon en ingångspolicy, option input 'ACCEPT' eller 'REJECT', och ett tunnelgränssnitt i en zon med ingång REJECT avvisar administrationsanslutningar medan det fortfarande vidarebefordrar trafik om vidarebefordran är tillåten.

Inaktivera inte anti-lockout-regeln för att få den nya vägen att fungera. Den regeln hindrar en dålig regel från att låsa ute LAN-administrationsadressen; den skyddar LAN-subnätet, inte tunnel-subnätet du just skapade. Lägg till en smal regel för administratörens källa och lämna skyddsnätet i fred. pfSense dokumentationen om admin-åtkomst förklarar var dessa kontroller finns.

# 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

Nivå tre: lyssnar något på den adressen?

En tjänst kan köra och ändå vara oåtkomlig eftersom den band till en enda adress. OpenWrts uhttpd har explicita lyssnarposter i /etc/config/uhttpd, till exempel list listen_http '0.0.0.0:80'; ett bygge som bara binder till LAN-adressen accepterar ingenting på tunneladressen, och produkter som visar en inställning för lyssnargränssnitt beter sig likadant. Lyssnarkommandona ovan svarar på detta direkt.

Skilj sedan avvisning från tystnad. nc -vz 10.6.0.1 443 som returnerar en avvisad anslutning betyder att paketet nådde routern och något avvisade det, antingen en stängd port eller en explicit avvisningsregel. Att hänga till timeout betyder att paketet släpptes eller aldrig routades. Den skillnaden säger vilken nivå du ska undersöka härnäst, och den kostar fem sekunder.

Ett VPN-gränssnitt är en gräns, inte en återhämtningsväg

Kryptering skyddar ledningen; den säger ingenting om vem som får öppna admin-sidan. När tunneln fungerar, motstå frestelsen att lösa nåbarhet genom att tillåta allt på tunnelgränssnittet. Ge administratörer en regel bunden till deras egen tunneladress eller en separat admin-only-tunnel, och håll vanliga användare, NAS:en, kamerorna och familjens laptops borta från administrationsporten. En peer som behöver fildelning bör inte vara en regel från routerns inloggning.

Routerns roll ändrar svaret. En router som avslutar tunneln kan legitimt ta emot administratörer från den, medan en router som bara använder tunneln som internetutgång vanligtvis inte borde. I båda fallen är subnätstillåtelsen inte inloggningen, så håll kontoauth och transportsäkerhet påslagna.

Kompensationsdraget folk gör efter en lockout är värre: att slå på WAN-administration eller vidarebefordra en port till webbgränssnittet. Det gör ett kort avbrott till en permanent exponering, och inloggningssidan är då nåbar för varje skanner på internet. Testa också den avvisade sidan, inte bara den tillåtna, så att en peer som inte ska ha admin-åtkomst får timeout eller avvisning i stället för en inloggningsförfrågan.

Testa också med en färsk anslutning. En stateful brandvägg håller befintliga flöden i sin statustabell, så SSH-sessionen du redan har öppen kan överleva en ändring som blockerar varje ny anslutning. Det är så en lockout förblir osynlig till nästa omstart eller nästa sömn på datorn.

Förbered vägen tillbaka innan du rör policyn

Skriv ner fyra saker före den första ändringen: hur du når enheten om tunneln dör, till exempel en seriekonsol, en leverantörskonsol eller en maskin på LAN:et; var den nuvarande konfigurationen exporteras; vilken enda regel eller rutt du ska ändra; och hur du rullar tillbaka exakt det objektet. På OpenWrt fångar sysupgrade -b /tmp/backup.tar.gz konfigurationen, och ändringar ligger kvar i väntan till uci commit, vilket ger dig en billig ångra om du märker det i tid. pfSense för konfigurationshistorik, och AutoConfigBackup hjälper bara om det redan var påslaget. Om routern kör en fail-closed regeluppsättning, bekräfta att underhållsvägen du planerat inte ligger inne i trafiken som den regeln blockerar, och kom ihåg att en omstart tillämpar beständiga regler igen i stället för att radera dem.

Ändra en gräns per försök och testa sedan från en ny anslutning i stället för skalet du håller öppet. Om testet misslyckas, rulla tillbaka den enda ändringen innan du rör nästa nivå. Tunneln kan vara uppe hela tiden, men dess gröna statusikon är inte bevis för att du fortfarande kommer in.

Snabb kontroll innan du går:

• Når du routern från en källa som inte beror på regeln du just redigerade?
• Tillåter ingångspolicyn på tunnelgränssnittet bara administratörens källa?
• Är administrationstjänsten bunden till en adress som finns på tunneln?
• Har du testat en avvisad peer och en färsk session?
• Är WAN-administrationsytan fortfarande stängd?