Ny ruter, same VPN-tenar: flytt den offentlege inngangen

Du set inn den nye ruteren, internett kjem tilbake, og VPN-klienten på telefonen peikar framleis på ei adresse som ikkje svarar lenger. Ingenting på VPN-tenaren er endra, for tenaren flytta seg aldri. Ruteren var den offentlege inngangen, og å byte han ut bytte ut adressa, vidaresendingsregelen og kanskje oppdateringsprogrammet for dynamisk DNS samstundes.

Handsam bytet som to overleveringar, ikkje éi, og hald ein lokal veg inn i administrasjonsgrensesnittet medan du arbeider.

Skriv ned overleveringa før du koplar frå

Noter LAN-prefikset, tenaradressa og korleis ho blir tildelt, lyttaren og transporten VPN faktisk brukar, den inngåande regelen som publiserer han, og namnet klientane har lagra. Noter deretter kva maskin som oppdaterer den dynamiske DNS-posten i dag: det kan vere ruteren, tenaren sjølv eller ein separat agent på ein annan vert. Gjer dette medan dei gamle administrasjonssidene framleis lastar. Eit skjermbilete av den inngåande regelen er betre enn eit hugsa portnummer.

Legg til dei private prefiksa klientane skal nå, og korleis einingar på LAN-et sender svar tilbake til dei. Begge blir lett gløymde, fordi byteveivisaren snakkar om internettilgang og ikkje om returvegar. Eksporter også den gamle konfigurasjonen om produsenten støttar gjenoppretting av han, medan du godtek at ein tryggingskopi frå éin modell sjeldan blir importert reint i ein annan.

Oppbevar den notata på ein verna stad. Ein ruterkopi kan innehalde påloggingsinformasjon for WAN-linja. Handsame eksportfila som eit passord og ikkje som ei notat om innstillingar.

Flytt adressa først, deretter vidaresendinga

Om den nye ruteren held på same LAN-prefiks, gje tenaren reservasjonen han hadde, eller ei tilsvarande statisk tildeling. Om prefikset blir endra, oppdater først tenaradressa og kvar lyttarbinding som nemner ho, for ei vidaresending mot den gamle adressa sender trafikken stille ingen stad.

Opprett deretter nøyaktig éin inngåande regel for transporten VPN brukar. Produsentrettleiingar som skildrar vidaresending til ein lokal tenar, viser mekanismen og ikkje ei universell oppskrift, så tilpass regelen til din faktiske protokoll og port i staden for ei liste frå ein blogg. Ei vidaresending på den nye ruteren kan ikkje fjerne operatør-NAT som ligg over han, og inga lokal regel gjer ei privat adresse tilgjengeleg frå internett om leverandøren alt deler éi med deg.

Stadfest at brannmuren til tenaren sjølv framleis tillèt den trafikken. Sjekk om det sit ein ekstra gateway mellom ruteren og internett, for mange leverandørar gjev ein kombinert modem og ruter. Les WAN-adressa på den nye eininga og samanlikn ho med adressa klientane slår opp. Om dei er ulike, landar vidaresendinga di på noko som ikkje er kanten.

Avgjer kven som oppdaterer det offentlege namnet

Oppdateringar av endepunktet treng éin eigar og berre éin. Om den gamle ruteren publiserte namnet, konfigurer eit støtta oppdateringsprogram på erstatninga og stadfest at posten faktisk endra seg. Om tenaren alt publiserte det, lat den ordninga vere i fred i staden for å leggje til eit konkurrerande oppdateringsprogram som vinglar mellom to adresser.

Når utrullinga publiserer begge adressefamiliane, les både A-posten og AAAA-posten. Kvar av dei må peike på ei teneste som faktisk lyttar og er tillaten gjennom sin eigen brannmurveg, og ein fungerande IPv4-mapping seier ingenting om IPv6-sida. Hald også identitetskontrollane i klientprofilen: ei endra offentleg adresse er ikkje grunn til å godta eit sertifikat eller ein peernøkkel som ikkje passar.

Prov bytet utanfrå

Test med ei autorisert ekstern tilkopling og ei fersk økt, ikkje frå innsida av LAN-et. Ein intern test mot den offentlege adressa er avhengig av hairpin-åtferd og går ein annan veg enn ein ekte klient.

Fylg sekvensen ein klient fylgjer: slå opp namnet, forhandle tunnelen, autentiser, og utfør deretter éin operasjon mot ein privat ressurs. Det siste trinnet er det folk hoppar over, og det er det einaste som provar returvegen. Om pålogginga lukkast men den private operasjonen mislukkast, samanlikn det nye LAN-prefikset, rutene klienten valde og svarvegen til ressursen med overleveringsnotata dine.

Først når alle fire trinna går gjennom, er den gamle ruteren trygg å ta ut av drift. Koplar han frå, og gjer deretter den eksterne testen éin gong til. Ein utdatert post som framleis slår opp til den gamle adressa, feilar alt i det første trinnet, og det er lettare å diagnostisere medan den gamle eininga framleis står i hylla.

Oppbevar den nye mappinga saman med gjenopprettingsnotata dine

Arkiver den endelege tenartildelinga, den inngåande regelen og namnet på oppdateringseigaren ved sida av prosedyren for å nå ruteren lokalt. Det neste bytet bør starte frå den sida og ikkje frå ein traceroute.

Om tunnelen framleis feilar utanfrå etter alt ovanfor, sjekk om den offentlege adressa ruteren rapporterer samsvarar med den klientane slår opp. Den eine samanlikninga skil eit DNS-problem frå eit vidaresendingsproblem, og ho tek kortare tid enn å lese nok ei rettleiing om portvidaresending.