Nå routerns adminsida via VPN, inte via WAN

Routerns adminsida öppnas på två sekunder från soffan och tar timeout från ett hotellrum, medan VPN-klienten hela tiden rapporterar att den är ansluten. Det du har är en väg ut, inte en väg tillbaka: tunneln bär din trafik till internet och stannar där. För att nå en enhet inne i ditt eget LAN krävs en session som slutar på något med en rutt dit. Det är ett designbeslut, inte en inställning, och det avgör om resten av arbetet alls är möjligt.

Skillnaden är lätt att tappa bort eftersom en produkt kan göra båda jobben. En kommersiell utgångsklient och en server för fjärråtkomst kan tala samma protokoll på samma port, och skillnaden är vilken sida som äger adressutrymmet bakom slutpunkten.

Vilken sida av tunneln äger LAN-et

För administration måste slutpunkten ligga i nätverket du vill nå, eller ha en auktoriserad väg dit. En router som kör sin egen VPN-server kvalar in; det gör också en liten alltid påslagen värd med fast adress och en rutt till LAN-et. En utgångstjänst som drivs av tredje part gör det inte, eftersom dess slutpunkt inte har något gränssnitt på ditt LAN och ingen regel som skulle låta ett dyka upp. Det här är kontrollen som måste slutföras innan du rör något annat.

Firmware märker sällan den skillnaden, så läs vad funktionen gör i stället för vilket protokoll den nämner. WireGuard, OpenVPN och IKEv2 förekommer alla på båda sidor av marknaden: en build skickar hushållstrafik ut, en annan tar emot din fjärrenhet. En build endast för klient kan inte göras om till server via konfiguration, hur menyn än är formulerad.

Få returrutten att finnas

En WireGuard-server på routern har en gränssnittsadress som 10.8.0.1/24 och en peer-post för den bärbara datorn. Klienten avgör vilka destinationer den skickar in i tunneln, och en lista som bara innehåller tunnelsubnätet lämnar LAN-et osynligt, hur servern än är konfigurerad. Båda ändarna måste vara överens, och vanligtvis redigeras bara en av dem.

wg show wg0 allowed-ips
ip route get 192.168.1.1

Det första kommandot rapporterar vad varje peer får skicka ur serverns synvinkel; det andra rapporterar vart en LAN-adress faktiskt skulle ta vägen på klienten. Ett LAN-mål som löses upp till tunnelgränssnittet är routning som fungerar, och det som går ut genom den fysiska gatewayen kommer aldrig fram, vad brandväggen än säger. Lägg till LAN-prefixet i klientens tillåtna lista och samma två kommandon blir ett verifieringssteg i stället för en diagnos.

Samma hopp för IPsec-gatewayer beskrivs av strongSwan-dokumentationen om vidarebefordran, där vidarebefordran och en source-NAT-regel kopplar en tunnelklient till en intern värd. Adresseringen skiljer sig; kravet inte.

Vem som får öppna adminsidan

Åtkomstkontroll hör på routern, inte i avsikten att vara försiktig. Tillåt bara den autentiserade tunnelidentiteten eller det källområde som behöver sidan, och läs routerns egen input-kedja samt all vidarebefordrad LAN-policy. En regel som låter det kabelanslutna LAN-et nå adminsidan säger ingenting om en klient som kommer in på tunnelgränssnittet. Skriv undantaget för en specifik identitet och behåll sedan en andra identitet som ska nekas.

Lyssnaren är den andra halvan och den är osynlig i brandväggens utdata. ss -ltnp visar adressen som webbservern är bunden till, och en tjänst som bara är bunden till LAN-adressen svarar inte på tunneladressen, hur tillåtande reglerna än är. Att binda om den eller lägga till en adress är en konfigurationsändring på routern, inte en brandväggsändring.

Håll autentisering och transportvalidering påslagna i samma genomgång. Nåbar är inte betrodd, och varje enhet inne i en tunnel blir inte därmed administratör. Tunnelns autentiseringsuppgifter och routerns konto är separata privilegier med separata livscykler, så nyckeln till en förlorad bärbar dator kan återkallas utan att återställa varje administratörs lösenord.

Testa utifrån, inte från soffan

Testa från ett nätverk du inte kontrollerar. Anslut genom den godkända tunneln, öppna en ny adminsession och ändra något harmlöst som du ser återspeglat på sidan. Från soffan bevisar du att LAN-et fungerar, vilket aldrig var ifrågasatt.

Testa sedan avvisningarna med samma omsorg. Försök med sidan utan tunneln och bekräfta att det misslyckas, och bekräfta att administrationstjänsten inte lyssnar alls på WAN-adressen. En sida som bara inte är länkad är inte åtkomstkontroll, och en WAN-lyssnare som visar ett inloggningsformulär är fortfarande en WAN-lyssnare. Om ett lösenord är det enda mellan internet och routerns konsol, är designen ett lösenord.

Hushållstjänster förtjänar en titt medan du är där. Åtstramning av administrationsregler bryter ofta gästnätverket eller resolvern som familjens enheter använder, och det dyker upp dagar senare som ett orelaterat klagomål.

Behålla en väg tillbaka medan du ändrar saker

Innan du ändrar rutter eller tunnelinställningar på distans, förbered en oberoende väg tillbaka. En befintlig session kan överleva ändringen som redan blockerar nya anslutningar, och det är precis så folk låser sig ute medan de tittar på en session som fortfarande fungerar. Alternativen är konkreta: en schemalagd omstart till en känd konfiguration, konsol- eller fysisk åtkomst, en andra tunnel som inte beror på inställningen som redigeras, eller out-of-band-administration där hårdvaran erbjuder det. Välj en och bevisa den före underhållsfönstret, inte under det.

Håll dokumentationen kort och aktuell: vilken värd som avslutar tunneln, vilka identiteter som kan nå sidan, vilken adress tjänsten binder till och hur en förlorad enhet återkallas. Listan fungerar också som återställningsplan, eftersom den säger var varje beroende bor. En saknad returrutt är ett routningsproblem att reparera, och det är aldrig en anledning att publicera administration på WAN.