Hvorfor ruterens admin slutter å svare etter en VPN-endring

Du endret en rute eller en brannmurregel for å teste en tunnel på ruteren, og nå svarer ikke admin-siden fra maskinen som fungerte fint for ti minutter siden. Refleksen er å skylde på VPN-en. Som oftest er tunnelen sunn, og én av tre andre ting har gått i stykker: ingen rute tilbake til ruterens egen adresse, en inngangspolicy som dropper forespørselen, eller en webtjeneste som ikke lytter på adressen du kaller. Alle tre ser like ut i nettleseren, derfor restarter folk tunnelen i en time og lærer ingenting.

Her er myten det er verdt å drepe først: en tunnel som virker er ikke en vei tilbake inn. Den er en ny nettverkstilkobling med sine egne tillitsspørsmål, og den kan stille fjerne den gamle administrasjonsveien din mens den åpner en ny som ingen har gjennomgått.

Tunnelen var aldri administrasjonsveien

Videreformidling og inngang er forskjellige jobber. «Kan en klient nå NAS-en gjennom tunnelen?» er et videreformidlingsspørsmål om pakker som passerer ruteren. «Kan jeg åpne ruterens SSH-port?» er et inngangsspørsmål om pakker som er adressert til ruteren selv. En tillatelsesregel skrevet for videreformidlet trafikk gjør ingenting for det andre, og det er den vanligste grunnen til at en tunnel som bærer trafikk perfekt likevel avviser admin-økten din.

Den motsatte feilen er å stole på et grensesnittnavn. En tunnel er kryptert til peeren, ikke til hver tjeneste bak den, og ordet VPN i en grensesnittetikett sier ingenting om hvilke kilder som bør få logge inn.

Nivå én: finnes det en rute til ruterens egen adresse?

Start på klienten og spør kjernen hvor pakken vil gå. På Linux skriver ip route get 10.6.0.1 ut den valgte ruten, utgående grensesnitt og kildeadresse. Hvis den rapporterer standardruten mot leverandøren din, kommer pakken aldri inn i tunnelen, og ingen regel på ruteren kan redde den.

Tunnelsiden har sin egen versjon av spørsmålet. WireGuard behandler AllowedIPs som en kryptonøkkel-ruteringstabell: i hver ende erklærer den hvilke kildeadresser en peer kan bruke og hvilke mål som sendes til den peeren. Hvis klientoppføringen ikke inneholder ruterens tunneladresse, har klienten ingen rute dit. Hvis serveroppføringen for den klienten ikke dekker klientens tunneladresse, dropper serveren pakken før noen brannmurregel blir sett på.

Bekreft den nøyaktige adressen du forventer å nå før du feilsøker policyen. En utdatert DNS-oppføring eller en bufret nabo-oppføring fra før endringen sender deg til en adresse ruteren aldri har eid.

Nivå to: inngangspolicyen, ikke videreformidlingspolicyen

Brannmurer vurderer regler på grensesnittet der pakken ankommer. På pfSense og OPNsense avgjør grensesnittfanen og rekkefølgen på reglene om trafikk til brannmurens egne tjenester er tillatt; en regel som slipper LAN-klienter ut på internett er ikke en regel som lar en tunnel-peer åpne web-GUI-en. På OpenWrt med firewall4 har hver sone en inngangspolicy, option input 'ACCEPT' eller 'REJECT', og et tunnelgrensesnitt i en sone med inngang REJECT vil avvise administrasjonstilkoblinger mens det fortsatt videresender trafikk hvis videreformidling er tillatt.

Ikke deaktiver anti-lockout-regelen for å få den nye veien til å virke. Den regelen hindrer at en dårlig regel låser ute LAN-administrasjonsadressen; den beskytter LAN-subnettet, ikke tunnel-subnettet du nettopp laget. Legg til én smal regel for administratorens kilde og la sikkerhetsnettet være. pfSense dokumentasjonen om admin-tilgang forklarer hvor disse kontrollene ligger.

# 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: lytter noe på den adressen?

En tjeneste kan kjøre og likevel være uoppnåelig fordi den bandt til én adresse. OpenWrts uhttpd har eksplisitte lytteoppføringer i /etc/config/uhttpd, for eksempel list listen_http '0.0.0.0:80'; en bygg som bare binder til LAN-adressen godtar ingenting på tunneladressen, og produkter som viser en lyttegrensesnitt-innstilling oppfører seg likt. Lyttekommandoene ovenfor svarer på dette direkte.

Skill så avvisning fra stillhet. nc -vz 10.6.0.1 443 som returnerer en avvist tilkobling betyr at pakken nådde ruteren og noe avviste den, enten en lukket port eller en eksplisitt avvisningsregel. Å henge til tidsavbrudd betyr at pakken ble droppet eller aldri rutet. Den forskjellen forteller deg hvilket nivå du skal undersøke neste gang, og den koster fem sekunder.

Et VPN-grensesnitt er en grense, ikke en gjenopprettingsvei

Kryptering beskytter ledningen; den sier ingenting om hvem som får åpne admin-siden. Når tunnelen virker, motstå fristelsen til å løse tilgjengelighet ved å tillate alt på tunnelgrensesnittet. Gi administratorer en regel bundet til deres egen tunneladresse eller en egen admin-only tunnel, og hold vanlige brukere, NAS-en, kameraene og familiens laptoper unna administrasjonsporten. En peer som trenger fildeling bør ikke være én regel unna innloggingen på ruteren.

Ruterens rolle endrer svaret. En ruter som avslutter tunnelen kan legitimt godta administratorer fra den, mens en ruter som bare bruker tunnelen som internettutgang vanligvis ikke bør. I begge tilfeller er subnett-tillatelsen ikke innloggingen, så hold kontogodkjenning og transportsikkerhet på.

Kompensasjonstrekket folk gjør etter en lockout er verre: å slå på WAN-administrasjon eller videresende en port til web-GUI-en. Det gjør et kort avbrudd til en permanent eksponering, og innloggingssiden er da tilgjengelig for enhver skanner på internett. Test også den avviste siden, ikke bare den tillatte, slik at en peer som ikke skal ha admin-tilgang får tidsavbrudd eller avvisning i stedet for en innloggingsforespørsel.

Test også med en fersk tilkobling. En stateful brannmur holder eksisterende strømmer i sin state-tabell, så SSH-økten du allerede har åpen kan overleve en endring som blokkerer hver ny tilkobling. Det er slik en lockout forblir usynlig til neste omstart eller neste søvn på maskinen.

Forbered veien tilbake før du rører policyen

Skriv ned fire ting før den første endringen: hvordan du når enheten hvis tunnelen dør, for eksempel seriekonsoll, leverandørkonsoll eller en maskin på LAN-et; hvor den nåværende konfigurasjonen eksporteres; hvilken enkelt regel eller rute du er i ferd med å endre; og hvordan du ruller nøyaktig det elementet tilbake. På OpenWrt fanger sysupgrade -b /tmp/backup.tar.gz konfigurasjonen, og endringer blir ventende til uci commit, noe som gir deg en billig angre. pfSense fører konfigurasjonshistorikk, og AutoConfigBackup hjelper bare hvis det allerede var slått på. Hvis ruteren kjører et fail-closed regelsett, bekreft at vedlikeholdsveien du planla ikke ligger inne i trafikken den regelen blokkerer, og husk at en omstart bruker vedvarende regler på nytt i stedet for å slette dem.

Endre én grense per forsøk, og test deretter fra en ny tilkobling i stedet for skallet du holder åpent. Hvis testen feiler, rull den ene endringen tilbake før du rører neste nivå. Tunnelen kan bli oppe hele tiden, men det grønne statusikonet er ikke bevis for at du fortsatt kommer inn.

Rask sjekk før du går:

• Når du ruteren fra en kilde som ikke avhenger av regelen du nettopp redigerte?
• Tillater inngangspolicyen på tunnelgrensesnittet bare administratorens kilde?
• Er administrasjonstjenesten bundet til en adresse som finnes på tunnelen?
• Har du testet én avvist peer og én fersk økt?
• Er WAN-administrasjonsflaten fortsatt lukket?