Nå routerens admin-side via VPN, ikke via WAN

Routerens admin-side åbner på to sekunder fra sofaen og udløber fra et hotelværelse, mens VPN-klienten hele tiden rapporterer, at den er forbundet. Det, du har, er en vej ud, ikke en vej tilbage: tunnelen bærer din trafik til internettet og stopper der. For at nå en enhed inde i dit eget LAN kræves en session, der afsluttes på noget med en rute ind i det. Det er en designbeslutning, ikke en indstilling, og den afgør, om resten af arbejdet overhovedet er muligt.

Forskellen er let at tabe, fordi ét produkt kan klare begge opgaver. En kommerciel udgangsklient og en server til fjernadgang kan tale samme protokol på samme port, og forskellen er, hvilken side der ejer adresseområdet bag endepunktet.

Hvilken side af tunnelen ejer LAN’et

Til administration skal endepunktet ligge inde i det netværk, du vil nå, eller have en autoriseret vej ind i det. En router, der kører sin egen VPN-server, opfylder kravet; det gør en lille altid-tændt vært med fast adresse og en rute til LAN’et også. En udgangstjeneste drevet af en tredjepart gør ikke, fordi dens endepunkt ikke har nogen grænseflade på dit LAN og ingen regel, der ville lade en dukke op. Det er den kontrol, der skal være færdig, før du rører noget andet.

Firmware mærker sjældent den forskel, så læs, hvad funktionen gør, i stedet for hvilken protokol den nævner. WireGuard, OpenVPN og IKEv2 optræder alle på begge sider af markedet: ét build sender husstandens trafik udad, et andet accepterer din fjerne enhed. Et build kun til klient kan ikke gøres til en server via konfiguration, uanset hvordan menuen er formuleret.

Få returruten til at findes

En WireGuard-server på routeren har en grænsefladeadresse som 10.8.0.1/24 og en peer-post til bærbaren. Klienten bestemmer, hvilke destinationer den sender ind i tunnelen, og en liste, der kun indeholder tunnelens undernet, lader LAN’et være usynligt, uanset hvordan serveren er konfigureret. Begge ender skal være enige, og normalt redigeres kun den ene.

wg show wg0 allowed-ips
ip route get 192.168.1.1

Den første kommando rapporterer, hvad hver peer må sende fra serverens synspunkt; den anden rapporterer, hvor en LAN-adresse faktisk ville gå hen på klienten. En LAN-destination, der opløses til tunnelgrænsefladen, er routing, der virker, og en, der forlader gennem den fysiske gateway, ankommer aldrig, uanset hvad firewallen siger. Tilføj LAN-præfikset til klientens tilladte liste, og de samme to kommandoer bliver et verifikationstrin i stedet for en diagnose.

Det samme hop for IPsec-gateways beskrives af strongSwan-dokumentationen om videresendelse, hvor videresendelse og en source-NAT-regel er det, der forbinder en tunnelklient med en intern vært. Adresseringen er forskellig; kravet er det ikke.

Hvem må åbne admin-siden

Adgangskontrol hører på routeren, ikke i hensigten om at være forsigtig. Tillad kun den godkendte tunnelidentitet eller kildeområdet, der har brug for siden, og læs routerens egen input-kæde samt enhver videresendt LAN-politik. En regel, der lader det kablede LAN nå admin-siden, siger intet om en klient, der ankommer på tunnelgrænsefladen. Skriv undtagelsen for en bestemt identitet, og hold derefter en anden identitet, der bør afvises.

Lytteren er den anden halvdel, og den er usynlig i firewall-output. ss -ltnp viser den adresse, webserveren er bundet til, og en tjeneste, der kun er bundet til LAN-adressen, svarer ikke på tunneladressen, uanset hvor tilladende reglerne er. At binde den igen eller tilføje en adresse er en konfigurationsændring på routeren, ikke en firewallændring.

Hold godkendelse og transportvalidering slået til i samme gennemløb. Tilgængelig er ikke betroet, og hver enhed inde i en tunnel bliver ikke dermed administrator. Tunnellegitimationsoplysningerne og routerkontoen er separate privilegier med separate livscyklusser, så en tabt bærbars nøgle kan tilbagekaldes uden at nulstille hver administrators adgangskode.

Test udefra, ikke fra sofaen

Test fra et netværk, du ikke kontrollerer. Forbind gennem den godkendte tunnel, åbn en frisk admin-session, og ændr noget harmløst, som du kan se afspejlet på siden. Fra sofaen beviser du, at LAN’et virker, hvilket aldrig var i tvivl.

Test derefter afvisningerne med samme omhu. Forsøg at åbne siden uden tunnelen, og bekræft, at det fejler, og bekræft, at administrationstjenesten slet ikke lytter på WAN-adressen. En side, der blot ikke er linket, er ikke adgangskontrol, og en WAN-lytter, der viser en loginformular, er stadig en WAN-lytter. Hvis en adgangskode er det eneste mellem internettet og routerens konsol, er designet en adgangskode.

Husstandens tjenester fortjener et kig, mens du er der. Stramning af administrationsregler ødelægger ofte gæstenetværket eller den resolver, familiens enheder bruger, og det dukker op dage senere som en urelateret klage.

Behold en vej tilbage, mens du ændrer ting

Før du ændrer ruter eller tunnelindstillinger eksternt, forbered en uafhængig vej tilbage. En eksisterende session kan overleve den ændring, der allerede blokerer nye forbindelser, og det er præcis sådan, folk lukker sig selv ude, mens de ser på en session, der stadig virker. Mulighederne er konkrete: en planlagt genstart til en kendt konfiguration, konsol- eller fysisk adgang, en anden tunnel, der ikke afhænger af den indstilling, der redigeres, eller out-of-band-administration, hvor hardwaren tilbyder det. Vælg én, og bevis den før vedligeholdelsesvinduet i stedet for under det.

Hold registreringen kort og aktuel: hvilken vært der afslutter tunnelen, hvilke identiteter der kan nå siden, hvilken adresse tjenesten binder til, og hvordan en tabt enhed tilbagekaldes. Listen fungerer også som gendannelsesplan, fordi den siger, hvor hver afhængighed bor. En manglende returrute er et routingproblem, der skal repareres, og det er aldrig en grund til at udgive administration på WAN.