Tror du, at omdøbning af Pritunl-serveren ændrer dens endpoint?

Omdøbning af en Pritunl-server ændrer en etiket i konsollen. Det ændrer ikke den adresse, som klientprofiler kontakter, og det opretter ikke en DNS-post. Den værdi, der betyder noget, er værtens offentlige adresse, og den accepterer et navn lige så villigt som en adresse.

Navnet, som klienterne kontakter, bor i ét værtfelt

Pritunl eksponerer endpointet via værtens indstilling Offentlig adresse, som tager enten en offentlig IP-adresse eller et DNS-navn. Sæt vpn.example.net der, og de genererede profiler og den autentificerede synkronisering giver klienterne det navn. Posten skal allerede findes og pege på den lytter, der accepterer VPN-transport; feltet annoncerer en destination, det offentliggør den ikke. Et serverobjekts visningsnavn er administrative metadata og når aldrig klientens forbindelsesforsøg.

Så det første skridt er ikke at omdøbe noget. Åbn værtens indstillinger, ændr den offentlige adresse, og gem via den understøttede grænseflade.

Tre felter, der ligner hinanden og ikke er det

Lokal adresse tjener replikering og routing mellem Pritunl-værter. Linkadresse beskriver, hvordan sammenkædede servere når hinanden. Ingen af dem er den adresse, en klient kontakter, og at kopiere det offentlige navn ind i dem ødelægger den topologi, de beskriver. Offentlig IPv6-adresse er et separat felt med sin egen post og sti; en A-post for IPv4 skaber ikke IPv6-rækkevidde.

Et DNS-navn bærer heller ingen portmapning og ingen lytter. Hvis tjenesten lytter på 1194 UDP, peger navnet stadig på en vært, der skal acceptere 1194 UDP. En HTTP-reversproxy på port 443, der betjener webkonsollen, er ikke VPN-transportens endpoint, selv når begge deler samme navn.

Domænebaseret routing inde i tunnelen er endnu et andet lag. Navngivning af det ydre endpoint siger intet om, hvilke private destinationer en klient kan nå.

Skub det nye navn ud til de klienter, der findes

Ændring af feltet omskriver ikke profiler, der allerede har forladt serveren. Pritunls autentificerede konfigurationssynkronisering kan levere ændringer af værtens adresse og port til kompatible klienter, og den dokumenterede CLI-klient synkroniserer, før den forbinder eller genopretter forbindelsen. En profil, der er importeret i NetworkManager eller i en selvstændig OpenVPN-klient, har ingen sådan kanal og kræver en godkendt erstatning. Eksisterende sessioner beviser intet, fordi de blev oprettet mod den gamle værdi.

Når webkonsollen står bag en load balancer, dokumenterer Pritunl en separat indstilling Synkroniseringsadresse til synkroniseringsstien. Genbrug ikke konsollens værtsnavn til VPN-lytteren, bare fordi begge er Pritunl.

Lever ændringen i denne rækkefølge: gem værtens indstilling, eksportér eller synkronisér den aktuelle profil, erstat klientens kopi, og genopret derefter forbindelsen. Notér, hvilke klienter der styres af synkronisering, og hvilke der har importerede filer, fordi den anden gruppe ikke følger automatisk. En liste over klienters ejerskab er mere nyttig her end endnu en DNS-post.

Accepter ændringen med en rigtig forbindelse

Opslag er den svageste mulige test. dig +short vpn.example.net, der returnerer en adresse, beviser kun, at en post findes.

Accepttesten er en frisk autentificeret forbindelse fra en klient med den nye profil, efterfulgt af en anmodning til en privat ressource, der bør kunne nås gennem tunnelen. Tjek i klientloggen det endpoint, den faktisk brugte, ikke det, du havde tænkt. Behold en administrationsvej, der ikke afhænger af, at navnet ændres korrekt, så en fejl ikke kan låse dig ude af konsollen.

Når den offentlige adresse senere flytter sig, skal du opdatere posten og planlægge klientcaching og genoprettelsesadfærd. Et værtsnavn afkobler klienter fra en numerisk adresse; det flytter ikke en aktiv socket eller får en utilgængelig lytter til at svare.