Ny ruter, samme VPN-server: flytt den offentlige inngangen

Du setter inn den nye ruteren, internett kommer tilbake, og VPN-klienten på telefonen peker fortsatt på en adresse som ikke lenger svarer. Ingenting på VPN-serveren er endret, for serveren flyttet seg aldri. Ruteren var den offentlige inngangen, og å bytte den byttet adressen, videresendingsregelen og kanskje oppdateringen for dynamisk DNS samtidig.

Behandle byttet som to overleveringer, ikke én, og hold en lokal vei inn i administrasjonsgrensesnittet mens du arbeider.

Skriv ned overleveringen før du kobler fra

Noter LAN-prefikset, serveradressen og hvordan den tildeles, lytteren og transporten VPN faktisk bruker, den inngående regelen som publiserer den, og navnet klientene har lagret. Noter deretter hvilken maskin som oppdaterer den dynamiske DNS-posten i dag: det kan være ruteren, serveren selv eller en separat agent på en annen vert. Gjør dette mens de gamle administrasjonssidene fortsatt lastes. Et skjermbilde av den inngående regelen er bedre enn et husket portnummer.

Legg til de private prefiksene klientene skal nå, og hvordan enheter på LAN-et sender svar tilbake til dem. Begge glemmes lett, fordi bytteveiviseren snakker om internettilgang, ikke om returveier. Eksporter også den gamle konfigurasjonen hvis produsenten støtter gjenoppretting av den, mens du godtar at en sikkerhetskopi fra én modell sjelden importeres rent i en annen.

Oppbevar den notaten på et beskyttet sted. En ruterkopi kan inneholde påloggingsinformasjon for WAN-linjen. Behandle eksportfilen som et passord og ikke som en notat om innstillinger.

Flytt adressen først, deretter videresendingen

Hvis den nye ruteren beholder samme LAN-prefiks, gi serveren reservasjonen den hadde, eller en tilsvarende statisk tildeling. Hvis prefikset endres, oppdater først serveradressen og enhver lytterbinding som nevner den, for en videresending mot den gamle adressen sender trafikken stille ingen steder.

Opprett deretter nøyaktig én inngående regel for transporten VPN bruker. Produsentveiledninger som beskriver videresending til en lokal server, viser mekanismen, ikke en universell oppskrift, så tilpass regelen til din faktiske protokoll og port i stedet for en liste fra en blogg. En videresending på den nye ruteren kan ikke fjerne operator-NAT som ligger over den, og ingen lokal regel gjør en privat adresse tilgjengelig fra internett hvis leverandøren allerede deler en med deg.

Bekreft at serverens egen brannmur fortsatt tillater den trafikken. Sjekk om det sitter en ekstra gateway mellom ruteren og internett, for mange leverandører gir en kombinert modem og ruter. Les WAN-adressen på den nye enheten og sammenlign den med adressen klientene slår opp. Hvis de er forskjellige, lander videresendingen din på noe som ikke er kanten.

Bestem hvem som oppdaterer det offentlige navnet

Oppdateringer av endepunktet trenger én eier og bare én. Hvis den gamle ruteren publiserte navnet, konfigurer en støttet oppdatering på erstatningen og bekreft at posten faktisk endret seg. Hvis serveren allerede publiserte det, la den ordningen være i fred i stedet for å legge til en konkurrerende oppdatering som vingler mellom to adresser.

Når utrullingen publiserer begge adressefamiliene, les både A-posten og AAAA-posten. Hver av dem må peke på en tjeneste som faktisk lytter og er tillatt gjennom sin egen brannmurvei, og en fungerende IPv4-mapping sier ingenting om IPv6-siden. Behold også identitetskontrollene i klientprofilen: en endret offentlig adresse er ikke grunn til å godta et sertifikat eller en peernøkkel som ikke passer.

Bevis byttet utenfra

Test med en autorisert ekstern tilkobling og en fersk økt, ikke fra innsiden av LAN-et. En intern test mot den offentlige adressen avhenger av hairpin-oppførsel og går en annen vei enn en ekte klient.

Følg sekvensen en klient følger: slå opp navnet, forhandle tunnelen, autentiser, og utfør deretter én operasjon mot en privat ressurs. Det siste trinnet er det folk hopper over, og det er det eneste som beviser returveien. Hvis påloggingen lykkes men den private operasjonen mislykkes, sammenlign det nye LAN-prefikset, rutene klienten valgte og ressursens svarvei med overleveringsnotatene dine.

Først når alle fire trinnene passerer, er den gamle ruteren trygg å ta ut av drift. Koble den fra, og gjenta deretter den eksterne testen én gang til. En utdatert post som fortsatt slår opp til den gamle adressen, feiler allerede i det første trinnet, og det er lettere å diagnostisere mens den gamle enheten fortsatt står i hyllen.

Oppbevar den nye mappingen sammen med gjenopprettingsnotatene dine

Arkiver den endelige servertildelingen, den inngående regelen og navnet på oppdateringseieren ved siden av prosedyren for å nå ruteren lokalt. Det neste byttet bør starte fra den siden og ikke fra en traceroute.

Hvis tunnelen fortsatt feiler utenfra etter alt over, sjekk om den offentlige adressen ruteren rapporterer samsvarer med den klientene slår opp. Den ene sammenligningen skiller et DNS-problem fra et videresendingsproblem, og den tar kortere tid enn å lese nok en veiledning om portvideresending.