Czy uważasz, że zmiana nazwy serwera Pritunl zmienia jego punkt końcowy?

Zmiana nazwy serwera Pritunl zmienia etykietę w konsoli. Nie zmienia adresu, z którym łączą się profile klientów, i nie tworzy rekordu DNS. Znaczenie ma publiczny adres hosta, a przyjmuje on nazwę równie chętnie jak adres.

Nazwa, z którą łączą się klienci, mieszka w jednym polu hosta

Pritunl udostępnia punkt końcowy przez ustawienie Publiczny adres hosta, które przyjmuje publiczny adres IP lub nazwę DNS. Umieść tam vpn.example.net, a wygenerowane profile i uwierzytelniona synchronizacja przekażą tę nazwę klientom. Rekord musi już istnieć i rozwiązywać się na odbiornik, który akceptuje transport VPN; pole ogłasza cel, ale go nie publikuje. Wyświetlana nazwa obiektu serwera to metadane administracyjne i nigdy nie dociera do próby połączenia klienta.

Pierwszym krokiem nie jest więc zmienianie czegokolwiek nazwy. Otwórz ustawienia hosta, zmień publiczny adres i zapisz przez obsługiwany interfejs.

Trzy pola, które wyglądają podobnie i takie nie są

Adres lokalny służy replikacji i routingowi między hostami Pritunl. Adres łącza opisuje, jak połączone serwery docierają do siebie. Żadne z nich nie jest adresem, z którym łączy się klient, a kopiowanie do nich publicznej nazwy psuje topologię, którą opisują. Publiczny adres IPv6 to osobne pole z własnym rekordem i ścieżką; rekord A dla IPv4 nie ustanawia osiągalności IPv6.

Nazwa DNS nie niesie też mapowania portów ani odbiornika. Jeśli usługa nasłuchuje na 1194 UDP, nazwa nadal rozwiązuje się na host, który musi akceptować 1194 UDP. Odwrotne proxy HTTP na porcie 443 obsługujące konsolę web nie jest punktem końcowym transportu VPN, nawet gdy oba dzielą tę samą nazwę.

Routing oparty na domenach wewnątrz tunelu to jeszcze inna warstwa. Nazwanie zewnętrznego punktu końcowego nic nie mówi o tym, do jakich prywatnych celów klient może dotrzeć.

Wyślij nową nazwę do istniejących klientów

Zmiana pola nie przepisuje profili, które już opuściły serwer. Uwierzytelniona synchronizacja konfiguracji Pritunl może dostarczyć zmiany adresu i portu hosta zgodnym klientom, a udokumentowany klient CLI synchronizuje się przed połączeniem lub ponownym połączeniem. Profil zaimportowany do NetworkManagera lub samodzielnego klienta OpenVPN nie ma takiego kanału i wymaga zatwierdzonego zamiennika. Istniejące sesje niczego nie dowodzą, bo zostały nawiązane ze starą wartością.

Gdy konsola web stoi za równoważeniem obciążenia, Pritunl dokumentuje osobne ustawienie Adres synchronizacji dla ścieżki synchronizacji. Nie używaj ponownie nazwy hosta konsoli dla odbiornika VPN tylko dlatego, że oba są Pritunl.

Dostarcz zmianę w tej kolejności: zapisz ustawienie hosta, wyeksportuj lub zsynchronizuj bieżący profil, zastąp kopię klienta, a następnie połącz się ponownie. Zapisz, którymi klientami zarządza synchronizacja, a które mają zaimportowane pliki, bo druga grupa nie podąży automatycznie. Lista własności klientów jest tu przydatniejsza niż kolejny rekord DNS.

Zaakceptuj zmianę prawdziwym połączeniem

Rozwiązywanie nazw to najsłabszy możliwy test. dig +short vpn.example.net zwracający adres dowodzi tylko, że rekord istnieje.

Test akceptacyjny to nowe uwierzytelnione połączenie z klienta z nowym profilem, po którym następuje żądanie do prywatnego zasobu, który powinien być osiągalny przez tunel. Sprawdź w dzienniku klienta punkt końcowy, którego faktycznie użył, a nie ten, który był zamierzony. Utrzymuj ścieżkę zarządzania niezależną od poprawnej zmiany nazwy, aby błąd nie mógł zablokować cię poza konsolą.

Później, gdy publiczny adres się przesunie, zaktualizuj rekord i zaplanuj buforowanie po stronie klientów oraz zachowanie przy ponownym łączeniu. Nazwa hosta odłącza klientów od adresu liczbowego; nie przenosi aktywnego gniazda i nie sprawia, że nieosiągalny odbiornik odpowie.