Waarom de routerbeheerder niet meer reageert na een VPN-wijziging

Je hebt een route of firewallregel gewijzigd om een tunnel op de router te testen, en nu reageert de beheerpagina niet meer vanaf de laptop die tien minuten eerder nog prima werkte. De reflex is de VPN de schuld geven. Meestal is de tunnel gezond en is een van drie andere dingen stuk: geen route terug naar het eigen adres van de router, een invoerbeleid dat het verzoek dropt, of een webservice die niet luistert op het adres dat je aanroept. Alle drie zien er in de browser hetzelfde uit, daarom herstarten mensen een uur lang de tunnel en leren niets.

Hier is de mythe die je het eerst moet doden: een werkende tunnel is geen weg terug naar binnen. Het is een nieuwe netwerkaansluiting met eigen vertrouwensvragen, en hij kan je oude beheerpad stilletjes weghalen terwijl hij een nieuw pad opent dat niemand heeft bekeken.

De tunnel was nooit het beheerpad

Doorsturen en invoer zijn verschillende taken. "Kan een client de NAS via de tunnel bereiken?" is een doorstuurbraag over pakketten die door de router gaan. "Kan ik de SSH-poort van de router openen?" is een invoervraag over pakketten die aan de router zelf zijn gericht. Een toestaanregel die voor doorgestuurd verkeer is geschreven, doet niets voor de tweede vraag, en dat is de meest voorkomende reden dat een tunnel die verkeer perfect vervoert je beheersessie toch weigert.

De omgekeerde fout is een interfacenaam vertrouwen. Een tunnel is versleuteld naar de peer, niet naar elke dienst erachter, en het woord VPN op een interfacelabel zegt niets over welke bronnen mogen inloggen.

Laag één: is er een route naar het eigen adres van de router?

Begin op de client en vraag de kernel waar het pakket heen gaat. Op Linux drukt ip route get 10.6.0.1 de gekozen route, de uitgaande interface en het bronadres af. Als het de standaardroute naar je provider meldt, komt het pakket nooit in de tunnel, en geen enkele regel op de router kan dat redden.

De tunnelkant heeft zijn eigen versie van de vraag. WireGuard behandelt AllowedIPs als een cryptosleutel-routingtabel: aan elk uiteinde verklaart die welke bronadressen een peer mag gebruiken en welke bestemmingen naar die peer worden gestuurd. Als de clientvermelding het tunneladres van de router niet bevat, heeft de client geen route ernaartoe. Als de serververmelding voor die client het tunneladres van de client niet dekt, gooit de server het pakket weg voordat er ook maar één firewallregel wordt bekeken.

Bevestig het exacte adres dat je wilt bereiken voordat je het beleid debugt. Een verouderd DNS-record of een gecachte buurvermelding van voor de wijziging stuurt je naar een adres dat de router nooit heeft gehad.

Laag twee: het invoerbeleid, niet het doorstuurbeleid

Firewalls beoordelen regels op de interface waar het pakket aankomt. Op pfSense en OPNsense bepalen het interfacetabblad en de regelvolgorde of verkeer naar de eigen diensten van de firewall is toegestaan; een regel die LAN-clients naar internet laat, is geen regel die een tunnelpeer de web-GUI laat openen. Op OpenWrt met firewall4 draagt elke zone een invoerbeleid, option input 'ACCEPT' of 'REJECT', en een tunnelinterface in een zone met invoer REJECT weigert beheerverbindingen terwijl hij verkeer nog doorstuurt als doorsturen is toegestaan.

Schakel de anti-lockoutregel niet uit om het nieuwe pad te laten werken. Die regel voorkomt dat een slechte regel het LAN-beheeradres buitensluit; hij beschermt het LAN-subnet, niet het tunnelsubnet dat je net hebt gemaakt. Voeg één smalle regel toe voor de bron van de beheerder en laat het vangnet met rust. De pfSense-documentatie over beheerderstoegang legt uit waar die instellingen staan.

# 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

Laag drie: luistert er iets op dat adres?

Een dienst kan draaien en toch onbereikbaar zijn omdat hij aan één adres is gebonden. OpenWrts uhttpd houdt expliciete luistervermeldingen in /etc/config/uhttpd, bijvoorbeeld list listen_http '0.0.0.0:80'; een build die alleen aan het LAN-adres bindt, accepteert niets op het tunneladres, en producten met een instelling voor de luisterinterface gedragen zich hetzelfde. De luistercommando's hierboven beantwoorden dat direct.

Scheid daarna weigering van stilte. nc -vz 10.6.0.1 443 dat een geweigerde verbinding teruggeeft, betekent dat het pakket de router heeft bereikt en iets het heeft geweigerd, ofwel een gesloten poort ofwel een expliciete weigeringsregel. Blijven hangen tot de time-out betekent dat het pakket is weggegooid of nooit is gerouteerd. Dat onderscheid vertelt je welke laag je hierna moet bekijken, en het kost vijf seconden.

Een VPN-interface is een grens, geen herstelpad

Versleuteling beschermt de draad; het zegt niets over wie de beheerpagina mag openen. Zodra de tunnel werkt, weersta de neiging om bereikbaarheid op te lossen door alles op de tunnelinterface toe te staan. Geef beheerders een regel die aan hun eigen tunneladres is gekoppeld of een aparte alleen-beheerders-tunnel, en houd gewone gebruikers, de NAS, de camera's en de gezinslaptops weg van de beheerpoort. Een peer die bestandsdeling nodig heeft, hoort niet één regel van de routerlogin verwijderd te zijn.

De rol van de router verandert het antwoord. Een router die de tunnel beëindigt, mag beheerders er legitiem van accepteren, terwijl een router die de tunnel alleen als internetuitgang gebruikt dat meestal niet zou moeten. In beide gevallen is de subnettoestemming niet de login, dus houd accountauthenticatie en transportbeveiliging aan.

De compenserende zet die mensen na een lockout doen is erger: WAN-beheer aanzetten of een poort naar de web-GUI doorsturen. Dat maakt van een korte storing een permanente blootstelling, en de loginpagina is dan bereikbaar voor elke scanner op internet. Test ook de geweigerde kant, niet alleen de toegestane, zodat een peer die geen beheerderstoegang zou moeten hebben een time-out of weigering krijgt in plaats van een loginvraag.

Test ook met een nieuwe verbinding. Een stateful firewall houdt bestaande stromen in zijn statustabel, dus de SSH-sessie die je al open hebt, kan een wijziging overleven die elke nieuwe verbinding blokkeert. Zo blijft een lockout onzichtbaar tot de volgende herstart of de volgende slaap van de laptop.

Bereid de weg terug voor je het beleid aanraakt

Schrijf vier dingen op voor de eerste wijziging: hoe je het apparaat bereikt als de tunnel sterft, bijvoorbeeld een seriële console, een providerconsole of een machine op het LAN; waar de huidige configuratie naartoe wordt geëxporteerd; welke ene regel of route je gaat wijzigen; en hoe je precies dat item terugdraait. Op OpenWrt legt sysupgrade -b /tmp/backup.tar.gz de configuratie vast, en wijzigingen blijven in behandeling tot uci commit, wat je een goedkope undo geeft als je het op tijd merkt. pfSense houdt een configuratiegeschiedenis bij, en AutoConfigBackup helpt alleen als het al was ingeschakeld. Als de router een fail-closed regelset draait, controleer dan dat het onderhoudspad dat je plant niet in het verkeer zit dat die regel blokkeert, en onthoud dat een herstart blijvende regels opnieuw toepast in plaats van ze te wissen.

Wijzig één grens per poging en test daarna vanaf een nieuwe verbinding in plaats van de shell die je openhoudt. Als de test mislukt, draai die ene wijziging terug voordat je de volgende laag aanraakt. De tunnel kan de hele tijd omhoog blijven, maar zijn groene statuspictogram is geen bewijs dat je er nog in komt.

Snelle controle voor je weggaat:

• Kun je de router bereiken vanaf een bron die niet afhangt van de regel die je net hebt bewerkt?
• Laat het invoerbeleid op de tunnelinterface alleen de bron van de beheerder toe?
• Is de beheerdienst gebonden aan een adres dat op de tunnel bestaat?
• Heb je één geweigerde peer en één nieuwe sessie getest?
• Is het WAN-beheeroppervlak nog steeds gesloten?