Redenumirea unui server Pritunl schimbă o etichetă în consolă. Nu schimbă adresa la care se conectează profilurile clienților și nu creează o înregistrare DNS. Valoarea care contează este adresa publică a gazdei, iar aceasta acceptă un nume la fel de ușor ca o adresă.

Numele la care se conectează clienții locuiește într-un singur câmp al gazdei

Pritunl expune punctul final prin setarea Adresă publică a gazdei, care acceptă o adresă IP publică sau un nume DNS. Puneți vpn.example.net acolo, iar profilurile generate și sincronizarea autentificată vor livra acel nume clienților. Înregistrarea trebuie să existe deja și să se rezolve către ascultătorul care acceptă transportul VPN; câmpul anunță o destinație, nu o publică. Numele afișat al unui obiect server este metadată administrativă și nu ajunge niciodată la încercarea de conectare a clientului.

Așadar primul pas nu este redenumirea a nimic. Deschideți setările gazdei, schimbați adresa publică și salvați prin interfața acceptată.

Trei câmpuri care par identice și nu sunt

Adresa locală servește replicării și rutării între gazdele Pritunl. Adresa de legătură descrie cum serverele conectate ajung unul la altul. Niciuna nu este adresa la care se conectează un client, iar copierea numelui public în ele strică topologia pe care o descriu. Adresa IPv6 publică este un câmp separat cu propria înregistrare și cale; o înregistrare A pentru IPv4 nu stabilește accesibilitatea IPv6.

Un nume DNS nu poartă nici mapare de porturi, nici ascultător. Dacă serviciul ascultă pe 1194 UDP, numele se rezolvă în continuare către o gazdă care trebuie să accepte 1194 UDP. Un proxy invers HTTP pe portul 443 care servește consola web nu este punctul final al transportului VPN, chiar și atunci când ambele împart același nume.

Rutarea bazată pe domenii din interiorul tunelului este încă un alt strat. Denumirea punctului final exterior nu spune nimic despre destinațiile private pe care un client le poate atinge.

Trimiteți noul nume clienților care există

Schimbarea câmpului nu rescrie profilurile care au plecat deja de pe server. Sincronizarea autentificată a configurației din Pritunl poate livra modificările de adresă și port ale gazdei către clienții compatibili, iar clientul CLI documentat sincronizează înainte de a se conecta sau reconecta. Un profil importat în NetworkManager sau într-un client OpenVPN autonom nu are un astfel de canal și necesită o înlocuire aprobată. Sesiunile existente nu dovedesc nimic, pentru că au fost stabilite cu valoarea veche.

Când consola web stă în spatele unui echilibrator de sarcină, Pritunl documentează o setare separată Adresă de sincronizare pentru calea de sincronizare. Nu reutilizați numele de gazdă al consolei pentru ascultătorul VPN doar pentru că ambele sunt Pritunl.

Livrați schimbarea în această ordine: salvați setarea gazdei, exportați sau sincronizați profilul actual, înlocuiți copia clientului și apoi reconectați-vă. Notați ce clienți sunt gestionați de sincronizare și care au fișiere importate, pentru că al doilea grup nu va urma automat. O listă a proprietății clienților este mai utilă aici decât încă o înregistrare DNS.

Acceptați schimbarea cu o conexiune reală

Rezolvarea este cel mai slab test posibil. dig +short vpn.example.net care returnează o adresă dovedește doar că există o înregistrare.

Testul de acceptare este o conexiune autentificată nouă de la un client cu profilul nou, urmată de o cerere către o resursă privată care ar trebui să fie accesibilă prin tunel. Verificați în jurnalul clientului punctul final pe care l-a folosit efectiv, nu pe cel intenționat. Păstrați o cale de administrare care nu depinde de schimbarea corectă a numelui, astfel încât o eroare să nu vă blocheze în afara consolei.

Mai târziu, când adresa publică se mută, actualizați înregistrarea și planificați memoria cache a clienților și comportamentul de reconectare. Un nume de gazdă decuplează clienții de o adresă numerică; nu mută un socket activ și nu face un ascultător inaccesibil să răspundă.

Articole similare