Tinke jo dat it omneamen fan de Pritunl-tsjinner syn einpunt feroaret?

It omneamen fan in Pritunl-tsjinner feroaret in label yn 'e konsole. It feroaret net it adres dêr't kliïntprofilen har op ferbine, en it makket gjin DNS-record oan. De wearde dy't fan belang is, is it Iepenbiere Adres fan 'e host, en it akseptearret in namme like maklik as in adres.

De namme dêr't klanten har op ferbine wennet yn ien hostfjild

Pritunl bleatet it einpunt fia de ynstelling Iepenbier Adres fan 'e host, dy't of in iepenbier IP-adres of in DNS-namme akseptearret. Set vpn.example.net dêr, en de generearre profilen en de autentisearre syngronisaasje jouwe dy namme oan klanten. It record moat al bestean en nei de listener resolvje dy't VPN-ferfier akseptearret; it fjild kundiget in bestimming oan, it publisearret dy net. De werjefte fan 'e namme fan in tsjinnerobjekt is bestjoerlike metadata en berikt nea de ferbiningspoging fan 'e klant.

Dat de earste stap is net wat omneame. Iepenje de hostynstellingen, feroarje it Iepenbiere Adres en bewarje fia de stipe interface.

Trije fjilden dy't der itselde útsjen en it net binne

Lokaal Adres tsjinnet replikaasje en routing tusken Pritunl-hosts. Keppeladres beskriuwt hoe't keppele tsjinners elkoar berikke. Gjin fan beide is it adres dêr't in klant him op ferbynt, en it iepenbiere adres deryn kopiearje brekt de topology dy't se beskriuwe. Iepenbier IPv6-adres is in apart fjild mei eigen record en paad; in A-record foar IPv4 makket gjin IPv6-berikberens.

In DNS-namme draacht ek gjin poartemapping en gjin listener. As de tsjinst op 1194 UDP harket, resolvet de namme noch hieltyd nei in host dy't 1194 UDP akseptearje moat. In HTTP-omkearde proxy op poarte 443 dy't de webkonsole tsjinnet, is net it VPN-ferfiereinpunt, sels as beide deselde namme diele.

Domeinbasearre routing binnen de tunnel is wer in oare laach. It neamen fan it bûtenste einpunt seit neat oer hokker priveebestimmingen in klant berikke kin.

Stjoer de nije namme nei de klanten dy't al bestean

It feroarjen fan it fjild skriuwt gjin profilen oer dy't de tsjinner al ferlitten hawwe. De autentisearre konfiguraasjesyngronisaasje fan Pritunl kin adres- en poartewizigingen fan 'e host nei kompatibele klanten leverje, en de dokumintearre CLI-klant syngronisearret foardat er ferbynt of opnij ferbynt. In profyl dat yn NetworkManager of in selsstannige OpenVPN-klant ymportearre is, hat sa'n kanaal net en hat in goedkarde ferfanging nedich. Besteande sesjes bewiisje neat, want se binne tsjin de âlde wearde oprjochte.

As de webkonsole efter in load balancer stiet, dokumintarret Pritunl in aparte ynstelling Syngronisaasje-adres foar it syngronisaasjepaad. Brûk de hostnamme fan 'e konsole net opnij foar de VPN-listener, allinnich om't beide Pritunl binne.

Leverje de wiziging yn dizze folchoarder: bewarje de hostynstelling, eksportearje of syngronisearje it hjoeddeistige profyl, ferfang de kopy fan 'e klant en ferbynje dan opnij. Skriuw op hokker klanten troch syngronisaasje beheard wurde en hokker ymportearre bestannen hawwe, want de twadde groep folget net automatysk. In list fan klantbesit is hjir nuttiger as noch in DNS-record.

Akseptearje de wiziging mei in echte ferbining

Resolúsje is de swakste mooglike test. dig +short vpn.example.net dy't in adres weromjout, bewiist allinnich dat in record bestiet.

De akseptaasjetest is in farske autentisearre ferbining fan in klant mei it nije profyl, folge troch in fersyk nei in priveeboarne dy't troch de tunnel berikber wêze moat. Kontrolearje yn it klantlogboek it einpunt dat it wirklik brûkt hat, net dat wat jo bedoelden. Hâld in behearspaad dat net ôfhinklik is fan it korrekt feroarjen fan 'e namme, sadat in flater jo net bûten de konsole slute kin.

Letter, as it iepenbiere adres ferhuzet, fernij it record en plan foar klantkashing en opnij-ferbinen-gedrach. In hostnamme ûntkeppelt klanten fan in numerysk adres; it ferpleatst gjin libbene socket en lit in ûnberikbere listener net antwurdzje.