Myslíte si, že přejmenování serveru Pritunl změní jeho koncový bod?

Přejmenování serveru Pritunl mění štítek v konzoli. Nemění adresu, na kterou se připojují klientské profily, a nevytváří záznam DNS. Hodnota, na které záleží, je veřejná adresa hostitele a ta přijímá název stejně snadno jako adresu.

Název, na který se klienti připojují, žije v jednom poli hostitele

Pritunl zpřístupňuje koncový bod pomocí nastavení Veřejná adresa hostitele, které přijímá buď veřejnou IP adresu, nebo název DNS. Vložte tam vpn.example.net a vygenerované profily i ověřená synchronizace předají tento název klientům. Záznam už musí existovat a směřovat na naslouchač, který přijímá přenos VPN; pole inzeruje cíl, ale nezveřejňuje ho. Zobrazovaný název objektu serveru je administrativní metadata a nikdy se nedostane k pokusu klienta o připojení.

Prvním krokem tedy není přejmenování čehokoli. Otevřete nastavení hostitele, změňte veřejnou adresu a uložte přes podporované rozhraní.

Tři pole, která vypadají podobně a nejsou

Lokální adresa slouží replikaci a směrování mezi hostiteli Pritunl. Adresa odkazu popisuje, jak se propojené servery navzájem dostanou. Ani jedno není adresa, na kterou se klient připojuje, a kopírování veřejného názvu do nich rozbíjí topologii, kterou popisují. Veřejná adresa IPv6 je samostatné pole s vlastním záznamem a cestou; záznam A pro IPv4 nedosáhne dostupnosti přes IPv6.

Název DNS také nenese žádné mapování portů ani naslouchač. Pokud služba naslouchá na 1194 UDP, název se stále překládá na hostitele, který musí přijímat 1194 UDP. HTTP reverzní proxy na portu 443, která obsluhuje webovou konzoli, není koncovým bodem přenosu VPN, i když obě sdílejí stejný název.

Směrování podle domén uvnitř tunelu je zase jiná vrstva. Pojmenování vnějšího koncového bodu nic neříká o tom, které soukromé cíle může klient dosáhnout.

Přeneste nový název ke klientům, kteří existují

Změna pole nepřepisuje profily, které už server opustily. Ověřená synchronizace konfigurace Pritunl může doručit změny adresy hostitele a portu kompatibilním klientům a dokumentovaný klient CLI se synchronizuje před připojením nebo opětovným připojením. Profil importovaný do NetworkManageru nebo do samostatného klienta OpenVPN takový kanál nemá a potřebuje schválenou náhradu. Existující relace nic nedokazují, protože byly navázány se starou hodnotou.

Když webová konzole stojí za vyvažovačem zátěže, Pritunl dokumentuje samostatné nastavení Adresa synchronizace pro cestu synchronizace. Nepoužívejte jméno hostitele konzole pro naslouchač VPN jen proto, že obojí je Pritunl.

Doručte změnu v tomto pořadí: uložte nastavení hostitele, exportujte nebo synchronizujte aktuální profil, nahraďte kopii klienta a potom se znovu připojte. Zaznamenejte, které klienty spravuje synchronizace a které drží importované soubory, protože druhá skupina nebude následovat automaticky. Seznam vlastnictví klientů je zde užitečnější než další záznam DNS.

Přijměte změnu skutečným připojením

Překlad je nejslabší možný test. dig +short vpn.example.net, který vrátí adresu, dokazuje jen to, že záznam existuje.

Přijímacím testem je nové ověřené připojení z klienta s novým profilem, po němž následuje požadavek na soukromý prostředek, který má být dostupný tunelem. Zkontrolujte v klientském logu koncový bod, který skutečně použil, ne ten, který jste zamýšleli. Udržujte cestu správy, která nezávisí na správné změně názvu, aby vás chyba nemohla uzamknout mimo konzoli.

Později, když se veřejná adresa přesune, aktualizujte záznam a naplánujte kešování u klientů a chování při opětovném připojení. Název hostitele odpoutává klienty od číselné adresy; nepřesouvá živý socket ani nepřiměje nedostupný naslouchač odpovídat.