Uusi reititin, sama VPN-palvelin: siirrä sen julkinen sisäänkäynti
VPN-palvelin jää LAN-verkkoon, joten reitittimen vaihto on kaksi luovutusta: polku siihen ja asiakkaiden tallentama julkinen sisäänkäynti. Siirrä molemmat ja testaa sitten ulkopuolelta.
Kytket uuden reitittimen, internet palaa, ja puhelimen VPN-asiakas osoittaa edelleen osoitteeseen, joka ei enää vastaa. VPN-palvelimella ei muuttunut mikään, koska palvelin ei koskaan siirtynyt. Reititin oli julkinen sisäänkäynti, ja sen vaihtaminen vaihtoi osoitteen, edelleenohjaussäännön ja mahdollisesti dynaamisen DNS:n päivittäjän samalla kertaa.
Käsittele vaihto kahtena luovutuksena, älä yhtenä, ja pidä työn aikana paikallinen reitti hallintaliittymään.
Kirjoita luovutus muistiin ennen irrottamista
Kirjaa LAN-etuliite, palvelimen osoite ja sen määritystapa, kuuntelija ja kuljetus, jota VPN todella käyttää, saapuva sääntö, joka julkaisee sen, ja nimi, jonka asiakkaat ovat tallentaneet. Merkitse sitten, mikä kone päivittää dynaamisen DNS:n tietuetta tänään: se voi olla reititin, palvelin itse tai erillinen agentti toisella isännällä. Tee tämä, kun vanhat hallintasivut vielä latautuvat. Kuvakaappaus saapuvasta säännöstä on parempi kuin muistettu porttinumero.
Lisää yksityiset etuliitteet, joihin asiakkaiden pitäisi päästä, ja miten LAN-verkon laitteet lähettävät vastaukset niihin takaisin. Molemmat unohtuvat helposti, koska vaihtoavustaja puhuu internetyhteydestä eikä paluupoluista. Vie myös vanha kokoonpano, jos valmistaja tukee sen palauttamista, hyväksyen sen, että yhden mallin varmuuskopio tuodaan toiseen harvoin puhtaasti.
Säilytä sitä kirjausta suojatussa paikassa. Reitittimen varmuuskopio voi sisältää WAN-linkin tunnistetiedot. Käsittele vientitiedostoa kuin salasanaa, älä kuin asetusmuistiinpanoa.
Siirrä ensin osoite, sitten edelleenohjaus
Jos uusi reititin säilyttää saman LAN-etuliitteen, anna palvelimelle sen aiempi varaus tai vastaava staattinen määritys. Jos etuliite muuttuu, päivitä ensin palvelimen osoite ja jokainen kuuntelijasidonta, joka nimeää sen, koska vanhaan osoitteeseen osoittava edelleenohjaus lähettää liikenteen hiljaa ei mihinkään.
Luo sen jälkeen täsmälleen yksi saapuva sääntö kuljetukselle, jota VPN käyttää. Valmistajien oppaat, jotka kuvaavat edelleenohjausta paikalliselle palvelimelle, näyttävät mekanismin, eivät yleispätevää reseptiä, joten sovita sääntö todelliseen protokollaasi ja porttiisi, älä blogin luetteloon. Uuden reitittimen edelleenohjaus ei voi poistaa sen yläpuolella olevaa operaattoritason NATia, eikä mikään paikallinen sääntö tee yksityisestä osoitteesta internetistä saavutettavaa, jos palveluntarjoaja jo jakaa yhden kanssasi.
Varmista, että palvelimen oma palomuuri sallii edelleen tämän liikenteen. Tarkista, istuuko reitittimen ja internetin välissä toinen yhdyskäytävä, koska monet tarjoajat antavat yhdistetyn modeemin ja reitittimen. Lue uuden laitteen WAN-osoite ja vertaa sitä osoitteeseen, jonka asiakkaat selvittävät. Jos ne eroavat, edelleenohjauksesi laskeutuu jollekin, joka ei ole reunalla.
Päätä, kuka päivittää julkisen nimen
Päätepisteen päivitykset tarvitsevat yhden omistajan ja vain yhden. Jos vanha reititin julkaisi nimen, määritä korvaavaan laitteeseen tuettu päivittäjä ja varmista, että tietue todella muuttui. Jos palvelin julkaisi sen jo, jätä se järjestely rauhaan sen sijaan, että lisäisit kilpailevan päivittäjän, joka heiluu kahden osoitteen välillä.
Kun käyttöönotto julkaisee molemmat osoiteperheet, lue sekä A- että AAAA-tietue. Kummankin on osoitettava palveluun, joka todella kuuntelee ja on sallittu oman palomuuripolkunsa kautta, eikä toimiva IPv4-kartoitus kerro mitään IPv6-puolesta. Pidä myös asiakasprofiilin identiteettitarkistukset: muuttunut julkinen osoite ei ole syy hyväksyä sertifikaattia tai vertaisavainta, joka ei täsmää.
Todista vaihto ulkopuolelta
Testaa valtuutetulla ulkoisella yhteydellä ja tuoreella istunnolla, älä LAN-verkon sisältä. Sisäinen testi julkista osoitetta vastaan riippuu paluukäyttäytymisestä ja kulkee eri polkua kuin todellinen asiakas.
Noudata järjestystä, jota asiakas noudattaa: selvitä nimi, neuvottele tunneli, todenna ja suorita sitten yksi toiminto yksityistä resurssia vastaan. Juuri sen viimeisen vaiheen ihmiset ohittavat, ja vain se todistaa paluupolun. Jos kirjautuminen onnistuu mutta yksityinen toiminto epäonnistuu, vertaa uutta LAN-etuliitettä, asiakkaan valitsemia reittejä ja resurssin vastauspolkua luovutusmuistiinpanoihisi.
Vasta kun kaikki neljä vaihetta menevät läpi, vanha reititin on turvallista poistaa käytöstä. Irrota se ja toista ulkoinen testi vielä kerran. Vanhentunut tietue, joka selvittää edelleen vanhaan osoitteeseen, epäonnistuu jo aivan ensimmäisessä vaiheessa, ja se on helpompi diagnosoida, kun vanha laite on vielä hyllyllä.
Pidä uusi kartoitus palautusmuistiinpanojesi kanssa
Arkistoi lopullinen palvelinmääritys, saapuva sääntö ja päivityksen omistajan nimi sen menettelyn viereen, jolla reitittimelle päästään paikallisesti. Seuraavan vaihdon pitäisi alkaa siltä sivulta, ei traceroutesta.
Jos tunneli epäonnistuu edelleen ulkopuolelta kaiken edellä kuvatun jälkeen, tarkista, vastaako reitittimen ilmoittama julkinen osoite sitä, jonka asiakkaat selvittävät. Se yksi vertailu erottaa DNS-ongelman edelleenohjausongelmasta, ja se vie vähemmän aikaa kuin uuden portinedelleenohjausoppaan lukeminen.