Hur man planerar en router-VPN-återställning före en fjärrbyte

Du är på väg att redigera tunneln som bär din egen session, så arbetet som räddar dig sker före bytet, inte under scramblen efter det. Skyddsnätet finns inte på VPN-sidan: det är återställningsskärmen, en konsol eller en andra väg som inte går genom enheten du redigerar. Jag planerar alla tre på samma routergränssnitt som jag ska redigera, och jag använder sökvägen en gång medan allt fortfarande fungerar. Det här är genomgången jag följer, i ordning.

Gå igenom återställningsflödet innan du behöver det

Öppna sidan som skulle ångra din ändring. På pfSense är det Diagnostik > Säkerhetskopiering och återställning; på OpenWrt är det System > Backup / Flash Firmware; på OPNsense är det System > Konfiguration > Säkerhetskopior, som också behåller tidigare versioner som du kan återgå till utan fil. Du återställer inget ännu. Du kontrollerar om den sidan öppnas från den sökväg du kommer att ha under ändringen, om den vill ha en omstart efteråt och om den avvisar ett arkiv skrivet av en annan firmwareversion. Netgate dokumenterar sitt eget export- och återställningsflöde vid docs.netgate.com.

En återställning byter ut hela konfigurationen, så det är inte en ångra för en regel. Arkivet innehåller användare, certifikat, VPN-nycklar, brandväggsregler och inställningarna för administratörsgränssnittet som avgör vem som får logga in. Det är därför jag exporterar omedelbart före ändringen och namnger filen med datum och den enstaka inställningen jag tänker röra. Att återställa en månad gammal fil återställer också en månad gammal tunnel och en månad gammal nyckel.

Om plattformen bara laddar arkiv från samma version, notera det nu: en firmwareuppgradering plus en VPN-redigering i ett fönster lämnar dig kvar i en fil som routern inte accepterar.

Bevisa en väg in som hoppar över tunneln

En andra SSH-session från samma bärbara dator till samma offentliga adress är inte en andra väg; båda dör tillsammans. Den oberoende sökvägen är en av dessa: en seriell eller KVM-konsol, en hypervisor eller molnkonsol, ett administrations-VLAN som kan nås från en värd som inte finns bakom tunneln, ett andra WAN- eller LTE-modem med en egen administrativ regel eller en person på plats.

Testa den valda vägen medan routern är frisk. Logga in över det, öppna VPN-sidan och sluta innan du sparar. Om en låsningsregel bara låter den nå instrumentpanelen har du fortfarande tid att fixa det, och korrigeringen måste ligga ovanför avvisningsregeln i regelordningen.

De flesta routrar binder administratörstjänsten till ett gränssnitt eller en adressfamilj, så en out-of-band-rutt måste komma dit den tjänsten lyssnar. Att bredda bindningen för fönstret fungerar, men det är i sig en förändring av den väg du är beroende av.

Exportera filen och skriv utlösaren

Flytta exporten från routern och från maskinen som kan förlora sin tunnel. En säkerhetskopia som är lagrad på routerns filsystem försvinner i exakt det misslyckande du planerar för, och en som sitter på den bärbara datorn som håller på att tappa anslutningen är knappt bättre.

Behandla den filen som en referens. Den innehåller privata nycklar, fördelade hemligheter, certifikatmaterial och hash för lösenord, så kryptera den eller lagra den med samma försiktighet som routerns inloggning.

Skriv sedan en mening: om jag inte kan öppna en ny hanteringssession från PATH inom N minuter efter ändringen, återställer jag FIL och startar om. Meningen tvingar ner omfattningen till en variabel. Rutt-, DNS- och brandväggsredigeringar som begås tillsammans är snabba att spara och långsamma att dela när du får ett försök till.

Använd en commit-timer där plattformen har en

Flera plattformar kommer att ångra ändringen åt dig om du inte kan bekräfta den. RouterOS Säkert läge, som anges med Ctrl+X i en terminal, återställer ändringarna som gjordes under den sessionen när sessionen avbryts. Junos rullar tillbaka ett obekräftat åtagande som bekräftats. Cisco IOS-par laddar om med återladdningsavbryt. Företagsbrandväggar arrangerar vanligtvis väntande ändringar med en timer för automatisk återställning. OpenWrt och de flesta konsumentfirmware har inget motsvarande, så där måste timern vara extern: en schemalagd återställning, ett cron-jobb som byter tillbaka en fil och startar om tjänsten, eller en omstart till den tidigare konfigurationen.

Anta inte att en funktion med liknande namn täcker samma omfattning. En produkts automatiska återställning kan endast täcka brandväggsregler; en annan kan täcka hela konfigurationen, inklusive hanteringsregeln du just ändrade för att hålla dig tillgänglig. Läs vad timern återställer innan du litar på den.

En timer kan inte ersätta en exporterad fil. Det misslyckas i det fall som betyder mest här: sessionen överlever, ledningsplanet gör det inte, och ingenting utlöser någonsin återgången.

Testa en helt ny anslutning, inte den öppna

En etablerad session fortsätter ofta att arbeta igenom förändringar som blockerar varje nytt handslag, eftersom dess tillstånd redan existerar och policy utvärderas när en anslutning skapas. Efter ändringen, skapa nya anslutningar från fjärrsidan: en ny SSH-session, ett nytt VPN-handslag från en klient, en normal sidladdning till routerns LAN-adress.

# run these from the remote machine, in a new shell
ssh -o ConnectTimeout=8 admin@"$ROUTER_WAN"
nc -vz "$ROUTER_WAN" 443
dig +short example.internal "@$ROUTER_LAN"

Testa sedan nedströms tunneln snarare än själva tunneln: namnupplösning, en TCP-anslutning till en intern tjänst och applikationen du faktiskt använder. En tunnel som etablerar men inte delar ut någon användbar DNS ser frisk ut i klientstatus och trasig i webbläsaren, och den skillnaden avgör om du återställer filen eller fixar en regel.

Upprepa efter en påtvingad frånkoppling och återanslutning, och en gång till efter en omstart om plattformen återställer tillståndet vid start. Vissa konfigurationer klarar varje livetest och misslyckas vid första uppstarten med de nya reglerna på plats.

Stäng dörrarna du öppnade för fönstret

Ta bort den tillfälliga administratörsregeln för valfri källa, engångskontot, den utökade bindningen, den tillåtna DNS-regeln och felsökningsloggningen. Den borttagningen är i sig en ändring på vägen du är beroende av, så kör om testet av den nya anslutningen efter det, från fjärrsidan.

Behåll den exporterade filen tills ändringen har överlevt en omstart och en riktig klientåterkoppling, rotera sedan allt du delade medan fönstret var öppet. En konfiguration som fungerar tills nästa start är ett lugnt sätt att tappa en router en vecka senare, när ingen kommer ihåg vilken regel som var tillfällig.

Skriv ner ändringen där nästa person tittar: vad som flyttades, vilken fil ångrar den, vilken sökväg som når konsolen och vilken regel som var tillfällig.

Innan du öppnar VPN-sidan måste fyra saker finnas: ett återställningsflöde du har testat, en andra sökväg du har bevisat, en exporterad fil som du faktiskt kan nå och en skriftlig trigger. Om någon saknas, fixa det först. Bytet kan vänta en timme; en lockout kan inte.