Luuletko, että Pritunl-palvelimen uudelleennimeäminen muuttaa sen päätepisteen?

Pritunl-palvelimen uudelleennimeäminen muuttaa konsolissa tunnistetta. Se ei muuta osoitetta, johon asiakasprofiilit yhdistävät, eikä se luo DNS-tietuetta. Merkitsevä arvo on isännän julkinen osoite, ja se hyväksyy nimen yhtä helposti kuin osoitteen.

Nimi, johon asiakkaat yhdistävät, asuu yhdessä isännän kentässä

Pritunl paljastaa päätepisteen isännän asetuksella Julkinen osoite, joka hyväksyy joko julkisen IP-osoitteen tai DNS-nimen. Laita vpn.example.net siihen, niin luodut profiilit ja todennettu synkronointi antavat tämän nimen asiakkaille. Tietueen on jo oltava olemassa ja käännyttävä kuuntelijalle, joka ottaa vastaan VPN-liikenteen; kenttä ilmoittaa kohteen, se ei julkaise sitä. Palvelinobjektin näyttönimi on hallinnollista metatietoa eikä koskaan saavuta asiakkaan yhteysyritystä.

Ensimmäinen askel ei siis ole minkään uudelleennimeäminen. Avaa isännän asetukset, vaihda julkinen osoite ja tallenna tuetun käyttöliittymän kautta.

Kolme kenttää, jotka näyttävät samanlaisilta eivätkä ole

Paikallinen osoite palvelee replikointia ja reititystä Pritunl-isäntien välillä. Linkkiosoite kuvaa, miten linkitetyt palvelimet tavoittavat toisensa. Kumpikaan ei ole osoite, johon asiakas yhdistää, ja julkisen nimen kopioiminen niihin rikkoo topologian, jota ne kuvaavat. Julkinen IPv6-osoite on erillinen kenttä omalla tietueellaan ja polullaan; IPv4:n A-tietue ei luo IPv6-tavoitettavuutta.

DNS-nimi ei myöskään kanna porttikartoitusta eikä kuuntelijaa. Jos palvelu kuuntelee osoitteessa 1194 UDP, nimi kääntyy silti isännäksi, jonka on hyväksyttävä 1194 UDP. HTTP-käänteisvälityspalvelin portissa 443, joka palvelee verkkokonsolia, ei ole VPN-siirron päätepiste, vaikka molemmat jakavat saman nimen.

Tunnelin sisäinen verkkotunnuspohjainen reititys on vielä eri kerros. Ulomman päätepisteen nimeäminen ei kerro mitään siitä, mitkä yksityiset kohteet asiakas voi tavoittaa.

Työnnä uusi nimi olemassa oleville asiakkaille

Kentän muuttaminen ei kirjoita uudelleen profiileja, jotka ovat jo lähteneet palvelimelta. Pritunlin todennettu kokoonpanon synkronointi voi toimittaa isännän osoite- ja porttimuutokset yhteensopiville asiakkaille, ja dokumentoitu CLI-asiakas synkronoi ennen yhdistämistä tai uudelleenyhdistämistä. NetworkManageriin tai erilliseen OpenVPN-asiakkaaseen tuodulla profiililla ei ole tällaista kanavaa ja se tarvitsee hyväksytyn korvaajan. Olemassa olevat istunnot eivät todista mitään, koska ne perustettiin vanhaa arvoa vasten.

Kun verkkokonsoli on kuormantasaimen takana, Pritunl dokumentoi erillisen asetuksen Synkronointiosoite synkronointipolkua varten. Älä käytä konsolin isäntänimeä uudelleen VPN-kuuntelijalle vain siksi, että molemmat ovat Pritunlia.

Toimita muutos tässä järjestyksessä: tallenna isännän asetus, vie tai synkronoi nykyinen profiili, korvaa asiakkaan kopio ja yhdistä sitten uudelleen. Kirjaa, mitä asiakkaita synkronointi hallitsee ja millä on tuotuja tiedostoja, koska toinen ryhmä ei seuraa automaattisesti. Luettelo asiakkaiden omistuksesta on täällä hyödyllisempi kuin vielä yksi DNS-tietue.

Hyväksy muutos oikealla yhteydellä

Nimien selvitys on heikoin mahdollinen testi. dig +short vpn.example.net, joka palauttaa osoitteen, todistaa vain, että tietue on olemassa.

Hyväksymistesti on tuore todennettu yhteys asiakkaalta, jolla on uusi profiili, ja sen jälkeen pyyntö yksityiseen resurssiin, jonka pitäisi olla tunnelin kautta tavoitettavissa. Tarkista asiakkaan lokista päätepiste, jota se todella käytti, ei sitä, jota tarkoitit. Pidä yllä hallintapolkua, joka ei riipu nimen oikeasta muuttamisesta, jotta virhe ei voi lukita sinua ulos konsolista.

Myöhemmin, kun julkinen osoite siirtyy, päivitä tietue ja suunnittele asiakkaiden välimuisti ja uudelleenyhdistämiskäyttäytyminen. Isäntänimi irrottaa asiakkaat numeerisesta osoitteesta; se ei siirrä elävää pistoketta eikä saa tavoittamattoman kuuntelijan vastaamaan.