Który adres źródłowy NGINX zapisze dla klienta VPN?

W instalacji NGINX i OpenVPN na tym samym hoście pojawiają się trzy adresy klienta, po jednym dla każdej ścieżki, którą może obrać żądanie. Przeglądarka trafiająca na adres tunelu, przeglądarka trafiająca na adres publiczny i program wychodzący przez internetową drogę bramy wyglądają na gniazdzie nasłuchującym różnie. Zdecyduj, którą ścieżkę obserwujesz, zanim zinterpretujesz wiersz logu. Decyzja zależy od celu, którego użył klient, od wyjątku, jaki ma dla zewnętrznego punktu końcowego VPN, i od tego, czy coś tłumaczy pakiet po drodze.

Decyduj po celu, nie po tym, kim jest użytkownik

Zacznij od adresu, na który wysłano żądanie, bo to ten adres wybiera ścieżkę. Żądanie do adresu tunelu hosta przychodzi na interfejsie tunelu z wewnętrznym adresem klienta jako źródłem. Żądanie do adresu publicznego hosta zwykle przychodzi na interfejsie skierowanym do internetu z publicznym adresem klienta, nawet gdy ten sam laptop ma w tej chwili zestawiony tunel. Przynależność do puli VPN jest więc cechą ścieżki pakietu, a nie cechą, która podąża za użytkownikiem.

Właśnie ten trzeci wiersz warto sprawdzić najpierw, gdy w logu pojawia się użytkownik VPN z adresem, który nie ma nic wspólnego z tunelem. Wyjaśnia to też, dlaczego dwóch użytkowników na tym samym profilu może dawać różne wpisy: ich własne sieci dostępowe się różnią i nic w tunelu tego nie nadpisuje.

Dlaczego zewnętrzny punkt końcowy tworzy drugą ścieżkę publiczną

Klient musi dotrzeć do publicznego adresu bramy, aby zestawić tunel, więc trasa do tego adresu musi istnieć poza tunelem. Gdy klient przekierowuje cały ruch do środka, rozsądna implementacja utrzymuje jawną trasę hosta do publicznego adresu serwera, aby uniknąć tunelu zależnego od samego siebie. Ten wyjątek nie rozróżnia usług, więc każde żądanie do tego samego publicznego adresu go stosuje, w tym żądanie przeglądarki do witryny hostowanej na bramie.

To mechanizm stojący za większością mylących zgłoszeń w tej dziedzinie, i zależy on od implementacji klienta, a nie serwera. Dwaj klienci z identycznymi profilami mogą więc zachowywać się różnie. Usunięcie wyjątku, aby »naprawić« log, ściąga tunel ze sobą, więc zachowaj go i projektuj wokół niego.

Czytaj gniazdo, tabelę i format logu razem

Trzy obserwacje rozstrzygają, którą ścieżkę widzisz: gdzie nasłuchuje gniazdo, który interfejs odpowiada celowi i co format logu rzeczywiście zapisuje. Jeśli nasłuch jest powiązany tylko z adresem tunelu, żądanie publiczne w ogóle do niego nie dotrze, co od razu wyklucza dwa wiersze. Jeśli wyszukanie dla klienta zwraca urządzenie tunelu, żądanie dotarło z wewnętrznym źródłem i log powinien to pokazać.

ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44

Następnie czytaj format, a nie wiersz. Pole zasilane przekazanym nagłówkiem rejestruje twierdzenie, a nie peera gniazda, a twierdzenie ma znaczenie tylko wtedy, gdy bezpośredni peer jest zaufanym proxy. Zapisanie obu wartości w logu rozstrzyga późniejsze spory, bo bezpośredni peer i zastąpiony adres to różne fakty i tylko jeden z nich przyszedł z sieci.

log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.conf

Wybierz punkt wejścia, którego chcesz, i uzgodnij DNS

Jeśli witryna ma być dostępna tylko przez tunel, nadaj jej nazwę, która klientom VPN rozwiązuje się na adres tunelu, i egzekwuj politykę na gnieździe nasłuchującym. Odpowiedź dzielonego DNS zwracająca 10.24.0.1 dla nazwy wewnętrznej to decyzja routingu w kostiumie szczegółu rozwiązywania nazw. Jeśli witryna musi być także publiczna, utrzymuj dwie nazwy lub dwa porty i pozwól logowi powiedzieć, która obsłużyła żądanie.

Reguły zezwalania podlegają tej samej logice. Zezwolenie puli tunelu nie upoważnia do żądania publicznego i nie wypełni wewnętrznego adresu na połączeniu, które przyszło przez internet. Mieszanie obu punktów wejścia pod jedną nazwą czyni zapisane źródło skutkiem ubocznym routingu klienta, a nie wyborem projektowym.

Zweryfikuj ścieżkę, potem politykę

Potwierdź ścieżkę przechwyceniem na bramie i żądaniem, które kontrolujesz. Przechwycenie na urządzeniu tunelu i na interfejsie publicznym pokazują, które niosło bajty, a kolejność pakietów mówi, czy między nimi nastąpiło tłumaczenie.

tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5

Następnie zweryfikuj dostęp w obu kierunkach: zamierzony nazwany punkt wejścia działa dla zamierzonego klienta, a niezatwierdzona ścieżka publiczna jest odrzucana, a nie tylko wolna. Ogólna witryna echa IP dowodzi czegoś o wyjściu bramy do internetu i niczego o tej witrynie na tym samym hoście. Gdy strona i WebSocket się nie zgadzają, porównaj ich adresy URL, rodziny adresów i odpowiedzi DNS, zanim dotkniesz konfiguracji serwera.