Dink jy die hernoeming van die Pritunl-bediener verander sy eindpunt?

Die hernoeming van 'n Pritunl-bediener verander 'n etiket in die konsole. Dit verander nie die adres wat kliëntprofiele skakel nie, en dit skep nie 'n DNS-rekord nie. Die waarde wat saak maak, is die bediener se Openbare Adres, en dit aanvaar 'n naam net so geredelik soos 'n adres.

Die naam wat kliënte skakel, woon in een bedienerveld

Pritunl stel die eindpunt bloot deur die bediener se Openbare Adres-instelling, wat óf 'n openbare IP-adres óf 'n DNS-naam aanvaar. Plaas vpn.example.net daar, en die gegenereerde profiele en geauthentiseerde sinchronisasie gee daardie naam aan kliënte. Die rekord moet reeds bestaan en na die luisteraar wys wat VPN-vervoer aanvaar; die veld adverteer 'n bestemming, dit publiseer nie een nie. 'n Bedienerobjek se vertoonnaam is administratiewe metadata en bereik nooit die kliënt se verbindingspoging nie.

Die eerste stap is dus nie om enigiets te hernoem nie. Maak die bedienerinstellings oop, verander die Openbare Adres en stoor deur die ondersteunde koppelvlak.

Drie velde wat soortgelyk lyk en dit nie is nie

Plaaslike Adres dien replikasie en roetering tussen Pritunl-bedieners. Skakeladres beskryf hoe geskakelde bedieners mekaar bereik. Nie een van hulle is die adres wat 'n kliënt skakel nie, en om die openbare naam daarin te kopieer, breek die topologie wat hulle beskryf. Openbare IPv6-adres is 'n aparte veld met sy eie rekord en pad; 'n A-rekord vir IPv4 vestig nie IPv6-bereikbaarheid nie.

'n DNS-naam dra ook geen porttoewysing en geen luisteraar nie. As die diens op 1194 UDP luister, wys die naam steeds na 'n bediener wat 1194 UDP moet aanvaar. 'n HTTP-omgekeerde instaanbediener op poort 443 wat die webkonsole bedien, is nie die VPN-vervoereindpunt nie, selfs wanneer albei dieselfde naam deel.

Domeingebaseerde roetering binne die tonnel is weer 'n ander laag. Die benoeming van die buitenste eindpunt sê niks oor watter private bestemmings 'n kliënt mag bereik nie.

Stuur die nuwe naam na die kliënte wat reeds bestaan

Om die veld te verander herskryf nie profiele wat die bediener reeds verlaat het nie. Pritunl se geauthentiseerde konfigurasiesinchronisasie kan adres- en portveranderings aan versoenbare kliënte lewer, en die gedokumenteerde CLI-kliënt doen sinchronisasie voordat dit verbind of herverbind. 'n Profiel wat in NetworkManager of 'n selfstandige OpenVPN-kliënt ingevoer is, het nie so 'n kanaal nie en benodig 'n goedgekeurde vervanging. Bestaande sessies bewys niks, want hulle is teen die ou waarde gevestig.

Waar die webkonsole agter 'n lasbalanseerder sit, dokumenteer Pritunl 'n aparte Sinchronisasie-adres-instelling vir die sinchronisasiepad. Moenie die konsole se gasheernaam vir die VPN-luisteraar hergebruik net omdat albei Pritunl is nie.

Lewer die verandering in hierdie volgorde: stoor die bedienerinstelling, voer die huidige profiel uit of sinchroniseer dit, vervang die kliënt se kopie en verbind dan weer. Teken aan watter kliënte deur sinchronisasie bestuur word en watter ingevoerde lêers hou, want die tweede groep sal nie outomaties volg nie. 'n Lys van kliënteienskap is hier nuttiger as nog 'n DNS-rekord.

Aanvaar die verandering met 'n werklike verbinding

Resolusie is die swakste moontlike toets. dig +short vpn.example.net wat 'n adres teruggee, bewys net dat 'n rekord bestaan.

Die aanvaardingstoets is 'n vars geauthentiseerde verbinding van 'n kliënt met die nuwe profiel, gevolg deur 'n versoek na 'n private hulpbron wat deur die tonnel bereikbaar behoort te wees. Kyk in die kliëntlog na die eindpunt wat dit werklik gebruik het, nie die een wat jy bedoel het nie. Hou 'n bestuurspad wat nie daarvan afhang dat die naam korrek verander word nie, sodat 'n fout jou nie uit die konsole kan sluit nie.

Wanneer die openbare adres later beweeg, werk die rekord by en beplan vir kliëntkashering en herverbindingsgedrag. 'n Gasheernaam ontkoppel kliënte van 'n numeriese adres; dit skuif nie 'n lewendige socket nie en maak nie 'n onbereikbare luisteraar antwoord nie.