Który adres trafia do DNS dla serwera połączonego przez VPN?
Hostowany serwer ma trzy adresy i nie są one wymienne. Wybierz wartość, której potrzebuje każda usługa, a potem potwierdź ją z zewnątrz maszyny.
Hostowany serwer z zainstalowanym VPN-em ma ostatecznie trzy adresy, a tylko jeden z nich należy do każdego miejsca, które właśnie konfigurujesz. Kopiowanie numeru z panelu dostawcy do DNS, do listenera albo na listę dozwolonych adresów to sposób, w jaki działający tunel zamienia się w usługę, do której nikt nie może dotrzeć. Ten przewodnik porządkuje pracę tak, aby każdy adres został wybrany dla podanego celu. Wymienia też polecenia, które potwierdzają, co faktycznie opublikowałeś.
Zmapuj trzy adresy, zanim cokolwiek opublikujesz
Nazwij je według funkcji. Adres underlay to ten, którego maszyna używa do dotarcia do punktu końcowego VPN przez internet, i często jest prywatny za NAT-em dostawcy. Adres tunelu żyje wewnątrz VPN-a i przydziela go serwer albo klient w zależności od produktu. Wyjście publiczne to adres, który zdalna witryna zapisuje po translacji, i nie musi istnieć na żadnym interfejsie, o który możesz zapytać.
Panel pokazujący jeden publiczny adres dla maszyny mówi ci bardzo niewiele o dwóch pozostałych rolach. Osiągalność underlay to wymóg, nie zakup: laptop za domowym routerem może dotrzeć do hostowanego punktu końcowego VPN bez posiadania publicznego adresu IPv4. Czego nie możesz zrobić, to wymyślić ścieżki wejściowej, wpisując nazwę, która rozwiązuje się na adres, którego nikt nie przekazuje dalej.
Wybierz adres według usługi, nie według etykiety
Zapisz, co serwer musi robić, zanim wybierzesz numer. Wychodzące wywołania API potrzebują stabilnego wyjścia, gdy druga strona prowadzi listę dozwolonych adresów. Dostęp prywatny potrzebuje adresu tunelu, do którego klienci mogą routować, oraz listenera związanego z nim. Publiczny hosting potrzebuje mapowania wejściowego, które dostawca naprawdę oferuje, a sam adres wyjścia tego nie zapewnia.
Jedna maszyna może służyć wszystkim trzem celom i nadal używać trzech różnych adresów. Pęka założenie, że jedna wartość pokrywa je wszystkie:
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
Wiersz wejściowy to ten, o który ludzie się spierają. Rekord wskazujący adres wyjścia nie tworzy listenera, otwarcia zapory ani mapowania portu, i czekanie tego nie zmienia. Gdy dostawca sprzedaje dedykowany adres razem z regułą wejściową, ten pakiet jest zdolnością, którą kupiłeś; sam adres nie jest uprawnieniem.
Polecenia, które pokazują, który adres jest który
Czytaj maszynę, nie panel. Nazwy interfejsów różnią się między systemami, więc dopasuj adresy do urządzeń, zamiast ufać etykiecie.
Pierwszy wiersz wymienia każdy adres IPv4 i jego urządzenie, a drugi pyta jądro, którego urządzenia użyłoby do znanego celu zewnętrznego:
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'Jeśli wyszukiwanie trasy odpowiada urządzeniem tunelu dla ruchu publicznego, twój pełny tunel działa. Sprawdzenie listenera jest równie ważne, bo proces związany tylko z 127.0.0.1 nigdy nie odpowie na adresie tunelu, niezależnie od tego, jaką nazwę opublikujesz.
Opublikuj go, a potem sprawdź z zewnątrz
Opublikuj wartość, której potrzebuje usługa, i nic więcej: rekord A lub AAAA do hostingu, wpis na liście dozwolonych adresów dla wywołań wychodzących, profil klienta dla dostępu prywatnego. Potem testuj z pozycji, która ma znaczenie, a tą nigdy nie jest maszyna, którą właśnie edytowałeś.
Dwa sprawdzenia pokrywają większość, a oba są wystarczająco tanie, by trzymać je w skrypcie:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthOdpowiedź DNS dowodząca, że twój rekord istnieje, nie jest dowodem, że żądanie dociera, a jedno udane żądanie dowodzi tylko, że jedna ścieżka działa z jednej sieci. Powtórz sprawdzenie przez połączenie mobilne, gdy w grę wchodzi lista dozwolonych adresów, bo wyjście, które obserwujesz, może zależeć od rodziny adresów i obranej trasy. Zanotuj, którą rodzinę zweryfikowałeś; działająca ścieżka IPv4 nie mówi absolutnie nic o IPv6.
Jeśli usługa jest wejściowa, adres wyjścia nie wystarcza
Dostęp wejściowy wymaga czterech rzeczy w jednej linii: nazwy lub adresu, do którego klient może dotrzeć, trasy, która dostarcza pakiet do maszyny, listenera, który go przyjmuje, oraz polityki, która go nie odrzuca. VPN zmienia drugi element, a czasem pierwszy, i nie robi nic dla trzeciego i czwartego. Gdy tunel jest ścieżką dostawy, klienci łączą się z adresem tunelu, nie z wyjściem.
Zapisz, od którego adresu zależy każda usługa, a potem wracaj do tej notatki, ilekroć dostawca zmieni swój model trasowania. Serwer, który odpowiada prywatnie i zawodzi publicznie, zwykle nie jest zepsuty; odpowiada pod niewłaściwą tożsamością, a naprawa jest decyzją o mapowaniu, a nie zmianą zapory.