Hvorfor routerens admin holder op med at svare efter en VPN-ændring

Du har ændret en rute eller en firewallregel for at teste en tunnel på routeren, og nu svarer admin-siden ikke fra den bærbare computer, der fungerede fint for ti minutter siden. Refleksen er at give VPN'en skylden. Det meste af tiden er tunnelen sund, og en af tre andre ting er gået i stykker: ingen rute tilbage til routerens egen adresse, en inputpolitik der dropper anmodningen, eller en webtjeneste, der ikke lytter på den adresse, du kalder. Alle tre ser ens ud i browseren, og derfor genstarter folk tunnelen i en time og lærer intet.

Her er myten, der er værd at dræbe først: en tunnel, der virker, er ikke en vej tilbage ind. Den er en ny netværkstilkobling med sine egne tillidsspørgsmål, og den kan stille fjerne din gamle administrationsvej, mens den åbner en ny, som ingen har gennemgået.

Tunnelen var aldrig administrationsvejen

Videresendelse og input er forskellige opgaver. "Kan en klient nå NAS'en gennem tunnelen?" er et videresendelsesspørgsmål om pakker, der passerer gennem routeren. "Kan jeg åbne routerens SSH-port?" er et inputspørgsmål om pakker, der er adresseret til routeren selv. En tilladelsesregel skrevet til videresendt trafik gør intet for det andet, og det er den mest almindelige grund til, at en tunnel, der transporterer trafik perfekt, stadig afviser din admin-session.

Den modsatte fejl er at stole på et interfacenavn. En tunnel er krypteret til peer'en, ikke til hver tjeneste bag den, og ordet VPN i et interfacemærke siger intet om, hvilke kilder der bør have lov til at logge ind.

Lag et: er der en rute til routerens egen adresse?

Start på klienten og spørg kernen, hvor pakken vil gå hen. På Linux udskriver ip route get 10.6.0.1 den valgte rute, det udgående interface og kildeadressen. Hvis den rapporterer standardruten mod din udbyder, kommer pakken aldrig ind i tunnelen, og ingen regel på routeren kan redde den.

Tunnelsiden har sin egen version af spørgsmålet. WireGuard behandler AllowedIPs som en kryptonøgle-routingtabel: i hver ende erklærer den, hvilke kildeadresser en peer må bruge, og hvilke destinationer der sendes til den peer. Hvis klientposten ikke indeholder routerens tunneladresse, har klienten ingen rute til den. Hvis serverposten for den klient ikke dækker klientens tunneladresse, dropper serveren pakken, før nogen firewallregel konsulteres.

Bekræft den præcise adresse, du forventer at nå, før du fejlfinder politik. En forældet DNS-post eller en cachet nabo-post fra før ændringen sender dig til en adresse, routeren aldrig har ejet.

Lag to: inputpolitikken, ikke videresendelsespolitikken

Firewalls vurderer regler på det interface, hvor pakken ankommer. På pfSense og OPNsense afgør interfacefanen og regelrækkefølgen, om trafik til firewallens egne tjenester er tilladt; en regel, der lukker LAN-klienter ud på internettet, er ikke en regel, der lader en tunnel-peer åbne web-GUI'en. På OpenWrt med firewall4 har hver zone en inputpolitik, option input 'ACCEPT' eller 'REJECT', og et tunnelinterface i en zone med input REJECT vil afvise administrationsforbindelser, mens det stadig videresender trafik, hvis videresendelse er tilladt.

Deaktiver ikke anti-lockout-reglen for at få den nye vej til at virke. Den regel forhindrer, at LAN-administrationsadressen låses ude af en dårlig regel; den beskytter LAN-subnettet, ikke det tunnel-subnet, du netop har oprettet. Tilføj én smal regel for administratorens kilde, og lad sikkerhedsnettet være. pfSense dokumentation om admin-adgang forklarer, hvor disse kontroller findes.

# 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

Lag tre: lytter noget på den adresse?

En tjeneste kan køre og stadig være uopnåelig, fordi den bandt til én adresse. OpenWrts uhttpd holder eksplicitte lytterposter i /etc/config/uhttpd, for eksempel list listen_http '0.0.0.0:80'; et build, der kun binder til LAN-adressen, accepterer intet på tunneladressen, og produkter, der udstiller en lytte-interface-indstilling, opfører sig på samme måde. Lyttekommandoerne ovenfor besvarer det direkte.

Adskil derefter afvisning fra tavshed. nc -vz 10.6.0.1 443, der returnerer en afvist forbindelse, betyder, at pakken nåede routeren, og at noget afviste den, enten en lukket port eller en eksplicit afvisningsregel. En hængning indtil timeout betyder, at pakken blev droppet eller aldrig rutet. Den forskel fortæller dig, hvilket lag du skal undersøge næste gang, og den koster fem sekunder.

Et VPN-interface er en grænse, ikke en gendannelsesvej

Kryptering beskytter ledningen; den siger intet om, hvem der må åbne admin-siden. Når tunnelen virker, modstå trangen til at løse tilgængelighed ved at tillade alt på tunnelinterfacet. Giv administratorer en regel bundet til deres egen tunneladresse eller en separat admin-only tunnel, og hold almindelige brugere, NAS'en, kameraerne og familiens bærbare computere væk fra administrationsporten. En peer, der har brug for fildeling, bør ikke være én regel fra routerens login.

Routerens rolle ændrer svaret. En router, der afslutter tunnelen, kan legitimt acceptere administratorer fra den, mens en router, der kun bruger tunnelen som internetudgang, normalt ikke bør. I begge tilfælde er subnet-tilladelsen ikke login, så hold kontogodkendelse og transportsikkerhed slået til.

Det kompenserende træk, folk gør efter en lockout, er værre: at slå WAN-administration til eller videresende en port til web-GUI'en. Det gør et kort udfald til en permanent eksponering, og login-siden er derefter tilgængelig for enhver scanner på internettet. Test også den afviste side, ikke kun den tilladte, så en peer, der ikke bør have admin-adgang, får timeout eller afvisning i stedet for en loginprompt.

Test også med en frisk forbindelse. En stateful firewall holder eksisterende flows i sin state-tabel, så den SSH-session, du allerede har åben, kan overleve en ændring, der blokerer hver ny forbindelse. Det er sådan en lockout forbliver usynlig indtil næste genstart eller næste lur af den bærbare.

Forbered vejen tilbage, før du rører politikken

Skriv fire ting ned før den første ændring: hvordan du når enheden, hvis tunnelen dør, for eksempel en seriel konsol, en udbyderkonsol eller en maskine på LAN'et; hvor den nuværende konfiguration eksporteres hen; hvilken enkelt regel eller rute du er ved at ændre; og hvordan du præcist ruller netop det element tilbage. På OpenWrt fanger sysupgrade -b /tmp/backup.tar.gz konfigurationen, og ændringer forbliver afventende indtil uci commit, hvilket giver dig en billig fortrydelse, hvis du opdager det i tide. pfSense fører en konfigurationshistorik, og AutoConfigBackup hjælper kun, hvis det allerede var slået til. Hvis routeren kører et fail-closed regelsæt, skal du bekræfte, at den vedligeholdelsesvej, du planlagde, ikke ligger inde i den trafik, reglen blokerer, og huske, at en genstart genanvender vedvarende regler i stedet for at rydde dem.

Ændr én grænse pr. forsøg, og test derefter fra en ny forbindelse i stedet for den shell, du holder åben. Hvis testen fejler, rul den ene ændring tilbage, før du rører det næste lag. Tunnelen kan blive oppe hele tiden, men dens grønne statusikon er ikke bevis for, at du stadig kan komme ind.

Hurtigt tjek, før du går:

• Kan du nå routeren fra en kilde, der ikke afhænger af den regel, du lige har redigeret?
• Tillader inputpolitikken på tunnelinterfacet kun administratorens kilde?
• Er administrationstjenesten bundet til en adresse, der findes på tunnelen?
• Har du testet en afvist peer og en frisk session?
• Er WAN-administrationsfladen stadig lukket?