Ny router, samma VPN-server: flytta dess offentliga ingång

Du kopplar in den nya routern, internet kommer tillbaka, och VPN-klienten i telefonen pekar fortfarande på en adress som inte längre svarar. Ingenting på VPN-servern har ändrats, eftersom servern aldrig flyttade sig. Routern var den offentliga ingången, och att byta ut den bytte adressen, vidarebefordringsregeln och kanske uppdateraren för dynamisk DNS samtidigt.

Behandla bytet som två överlämningar, inte en, och håll en lokal väg in i administrationsgränssnittet medan du arbetar.

Skriv ner överlämningen innan du kopplar bort

Anteckna LAN-prefixet, serverns adress och hur den tilldelas, lyssnaren och transporten som VPN faktiskt använder, den inkommande regeln som publicerar den och namnet som klienterna har sparat. Anteckna sedan vilken maskin som uppdaterar den dynamiska DNS-posten i dag: det kan vara routern, servern själv eller en separat agent på en annan värd. Gör detta medan de gamla administrationssidorna fortfarande laddas. En skärmbild av den inkommande regeln är bättre än ett ihågkommet portnummer.

Lägg till de privata prefix som klienterna ska nå, och hur enheter på LAN-et skickar svar tillbaka till dem. Båda glöms lätt bort, eftersom bytesguiden talar om internetåtkomst och inte om returvägar. Exportera också den gamla konfigurationen om tillverkaren stöder återställning av den, samtidigt som du accepterar att en säkerhetskopia från en modell sällan importeras rent i en annan.

Förvara den anteckningen på en skyddad plats. En routersäkerhetskopia kan innehålla inloggningsuppgifter för WAN-länken. Behandla exportfilen som ett lösenord och inte som en anteckning om inställningar.

Flytta adressen först, därefter vidarebefordran

Om den nya routern behåller samma LAN-prefix, ge servern den reservation den hade, eller en likvärdig statisk tilldelning. Om prefixet ändras, uppdatera först serverns adress och varje lyssnarbindning som nämner den, eftersom en vidarebefordran mot den gamla adressen tyst skickar trafiken ingenstans.

Skapa sedan exakt en inkommande regel för den transport som VPN använder. Tillverkarguider som beskriver vidarebefordran till en lokal server visar mekanismen, inte ett universellt recept, så anpassa regeln till din faktiska protokoll och port i stället för till en lista från en blogg. En vidarebefordran på den nya routern kan inte ta bort operatörsnivå-NAT som sitter ovanför, och ingen lokal regel gör en privat adress nåbar från internet om leverantören redan delar en med dig.

Bekräfta att serverns egen brandvägg fortfarande tillåter den trafiken. Kontrollera om det sitter en andra gateway mellan routern och internet, eftersom många leverantörer ger en kombinerad modem och router. Läs WAN-adressen på den nya enheten och jämför den med adressen som klienterna slår upp. Om de skiljer sig landar din vidarebefordran på något som inte är kanten.

Bestäm vem som uppdaterar det offentliga namnet

Uppdateringar av slutpunkten kräver en ägare och bara en. Om den gamla routern publicerade namnet, konfigurera en stödd uppdaterare på ersättaren och bekräfta att posten faktiskt ändrades. Om servern redan publicerade det, låt den ordningen vara i fred i stället för att lägga till en konkurrerande uppdaterare som vinglar mellan två adresser.

När driftsättningen publicerar båda adressfamiljerna, läs både A-posten och AAAA-posten. Var och en måste peka på en tjänst som verkligen lyssnar och som är tillåten genom sin egen brandvägsväg, och en fungerande IPv4-mappning säger ingenting om IPv6-sidan. Behåll också identitetskontrollerna i klientprofilen: en ändrad offentlig adress är inte skäl att acceptera ett certifikat eller en peer-nyckel som inte passar.

Bevisa bytet utifrån

Testa med en auktoriserad extern anslutning och en ny session, inte inifrån LAN-et. Ett internt test mot den offentliga adressen beror på hairpin-beteende och går en annan väg än en riktig klient.

Följ den sekvens som en klient följer: slå upp namnet, förhandla tunneln, autentisera och utför sedan en operation mot en privat resurs. Det sista steget är det folk hoppar över, och det är det enda som bevisar returvägen. Om inloggningen lyckas men den privata operationen misslyckas, jämför det nya LAN-prefixet, de rutter klienten valde och resursens svarsväg med dina överlämningsanteckningar.

Först när alla fyra stegen passerar är den gamla routern säker att ta ur drift. Koppla bort den och upprepa sedan det externa testet en gång till. En inaktuell post som fortfarande slår upp till den gamla adressen misslyckas redan i första steget, och det är lättare att diagnosticera medan den gamla enheten fortfarande står på hyllan.

Förvara den nya mappningen tillsammans med dina återställningsanteckningar

Arkivera den slutliga servertilldelningen, den inkommande regeln och namnet på uppdateringsägaren bredvid proceduren för att nå routern lokalt. Nästa byte bör börja från den sidan och inte från en traceroute.

Om tunneln fortfarande misslyckas utifrån efter allt ovan, kontrollera om den offentliga adressen som routern rapporterar stämmer med den som klienterna slår upp. Den enda jämförelsen skiljer ett DNS-problem från ett vidarebefordringsproblem, och den tar kortare tid än att läsa ännu en guide om portvidarebefordran.