Brama hostuje własną stronę administracyjną: adres wewnętrzny czy publiczny

Usługa na samej bramie VPN potrzebuje wewnętrznego wejścia, do którego dotrze tunel. Opublikuj ją prywatnie, a następnie potwierdź, że publiczny nasłuch nie jest nadal otwarty.

Strona administracyjna odpowiada z telefonu w sieci komórkowej i kończy się przekroczeniem czasu z laptopa przyłączonego do VPN. Nic w tunelu nie jest zepsute, bo żądanie nigdy do niego nie wchodzi. Nazwa hosta rozwiązuje się na publiczny adres bramy, a ten adres jest osiągalny tylko z zewnątrz tunelu, który ona kończy. Naprawa polega na daniu usłudze prywatnego wejścia, a nie na przesuwaniu zewnętrznego punktu końcowego.

Strona ładuje się z zewnątrz, a nie przez tunel

Porównywane są dwa różne żądania. Z sieci komórkowej przeglądarka dociera bezpośrednio do publicznego adresu. Z wnętrza tunelu ta sama nazwa rozwiązuje się na ten sam publiczny adres, a pakiet musi teraz wyjść przez tunel, aby dotrzeć do adresu po własnej dalekiej stronie tunelu. Ta sama nazwa, ten sam adres, dwie bardzo różne pozycje.

Trasa docelowa wybiera adres, a nie port. Nic w tablicy routingu nie wie, że port 443 służy administracji, a port 1194 to transport, więc oba są traktowane jako ten sam cel.

Dlatego strona czasem działa, a czasem nie, zależnie od tego, jakiej nazwy i jakiej sieci użył klient. To problem ścieżki, a nie problem uwierzytelniania. Oba klienty uwierzytelniają się znakomicie.

Utrzymaj zewnętrzny punkt końcowy osiągalny

Profile pełnego tunelu potrzebują trasy wyjątku dla punktu końcowego VPN, a opcja redirect-gateway OpenVPN dokumentuje dokładnie to: zdalny punkt końcowy zachowuje trasę przez wcześniej istniejącą bramę, aby tunel nie routował do samego siebie. Usuń ten wyjątek, a szyfrowany transport podąży za tunelem, co kończy sesję w pętli. Właśnie ten wyjątek sprawia, że adres punktu końcowego pozostaje osiągalny z wnętrza tunelu.

Skutkiem jest to, że publiczny adres pozostaje osiągalny z klienta, dlatego żądanie przeglądarki do tego adresu może pójść tą samą trasą wyjątku i wyjść bez wchodzenia do tunelu. Wyjątek robi swoje, a szkodę wyrządza nazwa.

Przed zmianą czegokolwiek czytaj decyzję trasy, a nie listę interfejsów. Polecenia poniżej drukują decyzję, a nie inwentarz. Uruchom je z klienta, który zawiódł.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Jeśli wyszukiwanie pokazuje trasę punktu końcowego przez fizyczną bramę, zachowanie jest poprawne, a strona administracyjna jest po prostu wysyłana złą ścieżką. To miejsce, w którym rozwiązywanie nazw staje się poprawką.

Daj usłudze prywatną nazwę

Usługa potrzebuje nazwy, która wewnątrz tunelu rozwiązuje się na adres bramy, zachowując przy tym semantykę certyfikatu i nazwy hosta, której oczekuje aplikacja. Prywatny rekord strefy dla nazwy administracyjnej to zwykła odpowiedź, i pozostawia nazwę transportu nietkniętą.

Nie przekierowuj nazwy transportu na adres wewnętrzny, bo następne zestawienie tunelu próbowałoby wtedy dotrzeć do adresu, który istnieje tylko wewnątrz tunelu. Ten błąd daje VPN działający dokładnie raz.

Sprawdź także obie rodziny adresów, bo pozostawiony rekord AAAA może wysłać przeglądarkę tam, gdzie prywatny plan nigdy nie sięgał.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Dopasuj politykę do miejsca, w którym działa proces

Do natywnego procesu nasłuchującego na bramie dociera się ścieżką lokalnego wejścia, więc łańcuch wejściowy i powiązanie gniazda decydują, czy żądanie zostanie przyjęte. Reguły przekazywania i przekazywanie IP nie skłonią lokalnego nasłuchu do odpowiedzi. Zezwól na źródła tunelu w polityce wejściowej i potwierdź, że proces jest powiązany z adresem, do którego tunel może dotrzeć.

Kontener opublikowany na porcie hosta idzie inną ścieżką, bo pakiet jest tłumaczony docelowo i przekazywany. To żądanie napotyka politykę przekazywania hosta i własne reguły Dockera, dlatego działający natywny nasłuch może współistnieć z kontenerem, który odrzuca ten sam port.

Kolejność startu ma znaczenie w obu przypadkach, bo powiązanie z adresem, który pojawia się dopiero po podniesieniu tunelu, zawodzi po cichu przy rozruchu.

Sprawdź dostęp prywatny i odrzuconą ścieżkę publiczną

Wykonaj nowe nazwane żądanie z upoważnionego klienta, zachowując nienaruszone własne kontrole tożsamości aplikacji. Następnie spróbuj tej samej usługi z zewnątrz tunelu i potwierdź, że nie odpowiada. Prywatna nazwa to udogodnienie, a nie ograniczenie, a nasłuch wciąż powiązany z publicznym adresem wciąż jest wystawiony. Właśnie tę ostatnią kontrolę pomija większość przeglądów.

Czytaj powiązania i stan filtra, a nie nazwę hosta, którą dostali użytkownicy. Ekspozycja jest właściwością gniazda, a nie nazwy. Ta różnica przeżywa każdą zmianę DNS.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

Gdy wewnętrzne żądanie zwraca stronę, a zewnętrzne przekracza czas, usługa ma jedną zamierzoną prywatną ścieżkę i transport pozostaje osiągalny. Gdy zewnętrzne żądanie nadal odpowiada, nasłuch lub opublikowany wpis kontenera trzeba zawęzić, zanim ktokolwiek opisze usługę jako tylko wewnętrzną.

Powiązane artykuły