Ten adres L2TP to IPCP, a nie dzierżawa DHCP w sieci LAN

Wewnętrzny adres pochodzi z negocjacji PPP, a nie z serwera DHCP biura. Zobacz, który etap go przydziela, dlaczego LAN nie może odpowiedzieć i co sprawdzić.

Połączenie wstaje, a adapter pokazuje adres z zakresu biura, więc naturalny wniosek jest taki, że VPN dał ci adres LAN i tym samym umieścił cię w sieci LAN. Żadna z tych dwóch połówek nie jest do końca prawdziwa. L2TP przenosi sesję PPP, a PPP negocjuje wewnętrzny adres IPv4 za pomocą IPCP. Ten adres to parametr sesji uzgodniony między dwiema stronami, a nie dzierżawa wydana przez serwer DHCP biura, i posiadanie go nie czyni cię sąsiadem na kablu biurowym.

Dwa adresy w jednym połączeniu

W połączeniu L2TP są dwie niezależne negocjacje. Zewnętrzna ustanawia chronioną ścieżkę między twoim urządzeniem a punktem końcowym VPN w dowolnej sieci, którą już masz. Wewnętrzna to sesja PPP i tam uzgadniane są adres twojej sesji i adres drugiej strony. Ruch internetowy może w ogóle wychodzić pod trzecim adresem, publicznym adresem punktu końcowego, dlatego strona sprawdzająca VPN i adres adaptera rzadko się zgadzają.

Rozdzielenie tych trzech ról odpowiada na większość pytań, które ludzie przynoszą do tej warstwy. Prywatny numer na interfejsie VPN jest normalny i oczekiwany. Nie mówi nic o tym, czy punkt końcowy zmienił twoje publiczne wyjście, i sam z siebie nie decyduje, jakie cele osiąga twój ruch.

Co dokładnie robi IPCP

IPCP to protokół sterowania IPv4 dla PPP. Każda strona wysyła komunikaty Configure-Request opisujące opcje, których chce, a opcja adresu jest jedną z nich. Klient, który nie ma jeszcze adresu, zwykle pyta z 0.0.0.0, a serwer odpowiada komunikatem Configure-Nak niosącym adres, którego chce dla klienta. Potem klient prosi o ten adres i sesja wstaje z adresem lokalnym i zdalnym.

Ta wymiana jest udokumentowana w specyfikacjach PPP i IPCP i wyjaśnia szczegół, który wygląda jak błąd: adres wybiera serwer według własnej polityki, którą może być pula, ustawienie dla użytkownika albo adres powiązany z uwierzytelnioną tożsamością. Gdy pula się wyczerpie albo polityka koliduje z żądaniem, uwierzytelnianie może się udać, podczas gdy negocjacja adresu zawodzi, i klient zgłasza połączenie, które nigdy się nie stabilizuje.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

Linia w dzienniku pppd wymieniająca adres lokalny i zdalny to udany koniec tej negocjacji. Jej brak obok udanego uwierzytelnienia wskazuje na etap adresu, a nie na dane logowania.

Dlaczego LAN nie może ci odpowiedzieć

Adres z zakresu drugiej strony tworzy oczekiwanie, że hosty w tej sieci LAN mogą cię osiągnąć, a zwykle nie mogą, chyba że serwer kieruje adres twojej sesji z powrotem do tunelu. Bycie w puli to stwierdzenie o przydziale, a nie o topologii. Serwer plików biura nie ma trasy do adresu twojej sesji, chyba że serwer VPN go przekazuje, a może nawet nie jest to dozwolone, nawet jeśli przekazuje.

Dlatego nakładające się zakresy powodują problemy nieproporcjonalne do ich pozornej wielkości. Jeśli pula nakłada się na sieć LAN, której klient już używa, tabela routingu klienta ma teraz dwa roszczenia do tego samego prefiksu, a błędne często wygrywa z powodów, które nie mają nic wspólnego z tunelem.

Sprawdź sesję, potem trasę

Sprawdź najpierw interfejs, potem trasy, potem jeden istotny cel. Każdy krok ma własny tryb awarii, a testowanie wszystkich trzech naraz daje wniosek, którego później nie obronisz.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

Jeśli publiczne sprawdzenie pokazuje adres punktu końcowego, a prywatny cel kończy się przekroczeniem czasu, tunel przenosi twoją trasę domyślną i druga strona nie odpowiada na ten cel. Jeśli prywatny cel odpowiada, ale publiczne sprawdzenie się nie zmienia, profil używa tunelowania dzielonego i tylko część ruchu korzysta z sesji.

Trzymaj trzy etapy osobno

Uwierzytelnianie, negocjacja adresu i przekazywanie zawodzą inaczej, a każdy ma innego właściciela. Dane logowania to problem tożsamości, wyczerpanie IPCP to problem polityki serwera, a brakująca trasa powrotna to problem projektowania sieci. Zgłoszenie wszystkich trzech jako „VPN jest zepsuty” gwarantuje powolną naprawę.

Zapisz przydzielony adres, pulę, z której pochodzi, i to, czy sieć LAN ma do niego dotrzeć. Ta jedna notatka powstrzymuje następną osobę przed założeniem dzierżawy DHCP i szukaniem zakresu, który nigdy nie był zaangażowany.

Powiązane artykuły