Kvifor ruteradministrasjonen sluttar å svare etter ei VPN-endring

Du endra ei rute eller ein brannmurregel for å testa ein tunnel på ruteren, og no svarar ikkje administrasjonssida frå maskina som fungerte fint for ti minutt sidan. Refleksen er å skylda på VPN-en. Som oftast er tunnelen sunn, og éin av tre andre ting har gått i stykker: inga rute tilbake til ruterens eigen adresse, ein inngangspolicy som droppar førespurnaden, eller ei netteneste som ikkje lyttar på adressa du kallar. Alle tre ser like ut i nettlesaren, difor startar folk tunnelen på nytt i ein time og lærer ingenting.

Her er myten det er verdt å drepa fyrst: ein tunnel som verkar er ikkje ein veg tilbake inn. Han er ei ny nettverkstilkopling med sine eigne tillitsspørsmål, og han kan stille fjerna den gamle administrasjonsvegen din medan han opnar ein ny som ingen har gått gjennom.

Tunnelen var aldri administrasjonsvegen

Vidaresending og inngang er ulike jobbar. «Kan ein klient nå NAS-en gjennom tunnelen?» er eit vidaresendingsspørsmål om pakkar som passerer ruteren. «Kan eg opna SSH-porten til ruteren?» er eit inngangsspørsmål om pakkar som er adresserte til ruteren sjølv. Ein tillatingsregel skriven for vidaresendt trafikk gjer ingenting for det andre, og det er den vanlegaste grunnen til at ein tunnel som ber trafikk perfekt likevel avviser administrasjonsøkta di.

Den motsette feilen er å stola på eit grensesnittnamn. Ein tunnel er kryptert til peeren, ikkje til kvar teneste bak han, og ordet VPN i ei grensesnittetikett seier ingenting om kva kjelder som bør få logga inn.

Nivå éin: finst det ei rute til ruterens eigen adresse?

Start på klienten og spør kjernen kvar pakken vil gå. På Linux skriv ip route get 10.6.0.1 ut den valde ruta, utgåande grensesnitt og kjeldeadresse. Viss han rapporterer standardruta mot leverandøren din, kjem pakken aldri inn i tunnelen, og ingen regel på ruteren kan redda han.

Tunnelsida har sin eigen versjon av spørsmålet. WireGuard handsamar AllowedIPs som ein kryptonøkkel-ruteringstabell: i kvar ende erklærer han kva kjeldeadresser ein peer kan bruka og kva mål som vert sende til den peeren. Viss klientoppføringa ikkje inneheld tunneladressa til ruteren, har klienten inga rute dit. Viss serveroppføringa for den klienten ikkje dekkjer tunneladressa til klienten, droppar serveren pakken før nokon brannmurregel vert sett på.

Stadfest den nøyaktige adressa du ventar å nå før du feilsøkjer policyen. Ei utdatert DNS-oppføring eller ei bufra nabo-oppføring frå før endringa sender deg til ei adresse ruteren aldri har eigd.

Nivå to: inngangspolicyen, ikkje vidaresendingspolicyen

Brannmurar vurderer reglar på grensesnittet der pakken kjem inn. På pfSense og OPNsense avgjer grensesnittfana og rekkjefølgja på reglane om trafikk til brannmuren sine eigne tenester er tillaten; ein regel som slepp LAN-klientar ut på internett er ikkje ein regel som lèt ein tunnel-peer opna web-GUI-en. På OpenWrt med firewall4 har kvar sone ein inngangspolicy, option input 'ACCEPT' eller 'REJECT', og eit tunnelgrensesnitt i ei sone med inngang REJECT vil avvisa administrasjonstilkoplingar medan det framleis vidaresender trafikk om vidaresending er tillaten.

Ikkje deaktiver anti-lockout-regelen for å få den nye vegen til å verka. Den regelen hindrar at ein dårleg regel låser ute LAN-administrasjonsadressa; han vernar LAN-subnettet, ikkje tunnel-subnettet du nettopp laga. Legg til éin smal regel for kjelda til administratoren og lat sikkerheitsnettet vera. pfSense dokumentasjonen om admin-tilgang forklarar kvar desse kontrollane ligg.

# 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: lyttar noko på den adressa?

Ei teneste kan køyra og likevel vera uoppnåeleg fordi ho batt til éi adresse. uhttpd i OpenWrt har eksplisitte lyttaroppføringar i /etc/config/uhttpd, til dømes list listen_http '0.0.0.0:80'; eit bygg som berre bind til LAN-adressa godtek ingenting på tunneladressa, og produkt som viser ei lyttargrensesnitt-innstilling oppfører seg likt. Lyttarkommandoane ovanfor svarar på dette direkte.

Skil så avvising frå stillheit. nc -vz 10.6.0.1 443 som returnerer ei avvist tilkopling betyr at pakken nådde ruteren og noko avviste han, anten ein lukka port eller ein eksplisitt avvisingsregel. Å henga til tidsavbrot betyr at pakken vart droppa eller aldri ruta. Den skilnaden fortel deg kva nivå du skal undersøkja neste gong, og han kostar fem sekund.

Eit VPN-grensesnitt er ei grense, ikkje ein gjenopprettingsveg

Kryptering vernar leidningen; ho seier ingenting om kven som får opna administrasjonssida. Når tunnelen verkar, motstå freistinga til å løysa tilgjenge ved å tillata alt på tunnelgrensesnittet. Gje administratorar ein regel bunden til deira eigen tunneladresse eller ein eigen admin-berre tunnel, og hald vanlege brukarar, NAS-en, kameraa og familiens laptops unna administrasjonsporten. Ein peer som treng fildeling bør ikkje vera éin regel unna innlogginga på ruteren.

Rolla til ruteren endrar svaret. Ein ruter som avsluttar tunnelen kan legitimt ta imot administratorar frå han, medan ein ruter som berre brukar tunnelen som internettutgang vanlegvis ikkje bør. I begge tilfelle er subnett-tillatinga ikkje innlogginga, så hald kontogodkjenning og transporttryggleik på.

Kompensasjonstrekket folk gjer etter ein lockout er verre: å slå på WAN-administrasjon eller vidaresenda ein port til web-GUI-en. Det gjer eit kort avbrot til ei varig blottlegging, og innloggingssida er då tilgjengeleg for kvar skannar på internett. Test også den avviste sida, ikkje berre den tillatne, slik at ein peer som ikkje skal ha admin-tilgang får tidsavbrot eller avvising i staden for ein innloggingsførespurnad.

Test også med ei fersk tilkopling. Ein stateful brannmur held eksisterande straumar i state-tabellen sin, så SSH-økta du alt har open kan overleva ei endring som blokkerer kvar ny tilkopling. Det er slik ein lockout blir usynleg til neste omstart eller neste svevn på maskina.

Førebu vegen tilbake før du rører policyen

Skriv ned fire ting før den første endringa: korleis du når eininga om tunnelen døyr, til dømes seriekonsoll, leverandørkonsoll eller ei maskin på LAN-et; kvar den noverande konfigurasjonen vert eksportert; kva éin regel eller rute du er i ferd med å endra; og korleis du rullar nøyaktig det elementet tilbake. På OpenWrt fangar sysupgrade -b /tmp/backup.tar.gz konfigurasjonen, og endringar blir ventande til uci commit, noko som gjev deg ein billeg angre. pfSense fører konfigurasjonshistorie, og AutoConfigBackup hjelper berre om det alt var slått på. Viss ruteren køyrer eit fail-closed regelsett, stadfest at vedlikehaldsvegen du planla ikkje ligg inne i trafikken den regelen blokkerer, og hugs at ein omstart brukar varige reglar på nytt i staden for å sletta dei.

Endra éi grense per forsøk, og test deretter frå ei ny tilkopling i staden for skalet du held ope. Viss testen feilar, rull den eine endringa tilbake før du rører neste nivå. Tunnelen kan bli oppe heile tida, men det grøne statusikonet er ikkje prov på at du framleis kjem inn.

Rask sjekk før du går:

• Når du ruteren frå ei kjelde som ikkje avheng av regelen du nettopp redigerte?
• Tillèt inngangspolicyen på tunnelgrensesnittet berre kjelda til administratoren?
• Er administrasjonstenesta bunden til ei adresse som finst på tunnelen?
• Har du testa éin avvist peer og éi fersk økt?
• Er WAN-administrasjonsflata framleis lukka?