Twoja pula VPN to nie zakres DHCP sieci LAN: dlaczego to się psuje

Kuszącym skrótem jest przydzielanie klientom VPN adresów z tego samego zakresu, którego używa biurowy serwer DHCP, w przekonaniu, że i tak wszystko jest jedną siecią. Nie jest. Tunel routowany przenosi pakiety unicast między dwoma końcami, podczas gdy pula LAN istnieje po to, by odpowiadać na żądania rozgłoszeniowe w segmencie fizycznym. Ponowne użycie tych samych numerów stawia dwóch przydzielaczy odpowiedzialnych za jedną przestrzeń adresową i pozostawia trasę powrotną niezdefiniowaną.

Dwóch przydzielaczy, jedna przestrzeń adresowa

Serwer DHCP sieci LAN wie, jakie adresy wydzierżawił i jakiemu adresowi MAC, i broni ich za pomocą ARP. Serwer VPN ma własną pulę i nic nie wie o tych dzierżawach. Żaden nie błądzi; po prostu nigdy ich sobie nie przedstawiono.

Adres z puli LAN, który wydaje serwer VPN, może już należeć do drukarki. Teraz dwa urządzenia roszczą sobie jeden adres w tym samym prefiksie, a tablica przekazywania przełącznika decyduje, które odpowie.

To jest awaria, z którą ludzie spotykają się najpierw: klient, który łączy się z powodzeniem, a potem trafia na niewłaściwą maszynę, albo trafia na właściwą z przerwami.

Dlaczego router nie rozdaje adresów VPN

Wykrywanie DHCP jest rozgłoszeniem, a rozgłoszenia zatrzymują się na granicy routowanej. O ile projekt nie mostkuje tunelu albo nie uruchamia przekaźnika DHCP z odpowiednim uprawnieniem, żądanie klienta nigdy nie dociera do serwera LAN.

Dlatego serwer VPN sam przydziela adres: pula w konfiguracji serwera, adres dla każdego peera w konfiguracji WireGuard albo adres wypychany przez warstwę uwierzytelniania we wdrożeniu IKEv2. Te mechanizmy są niezależne od bazy dzierżaw sieci LAN, i właśnie dlatego potrzebują własnego zakresu.

To samo rozumowanie wyjaśnia, dlaczego zmiana zakresu DHCP nie naprawia klienta VPN, który nigdy nie dostaje adresu. Klient nie pyta serwera LAN i żadna edycja zakresu go do tego nie zmusi.

Nakładanie się ujawnia się jako konflikt, a nie jako wolna sieć

Dwie sieci dzielące prefiks bez wspieranego projektu to inny problem niż podwójna własność, i często się je myli. Jeśli pula VPN jest osobnym prefiksem, nakładanie się ma znaczenie tylko wtedy, gdy trasa wysyła ruch w niewłaściwą stronę. Jeśli pula leży wewnątrz prefiksu LAN, konflikt jest natychmiastowy i lokalny.

W praktyce widać odpowiedzi ARP z niewłaściwego urządzenia, połączenia resetowane w połowie i klienta, którego własny adres rości sobie ktoś inny. Nic z tego nie wygląda na problem routingu, dlatego poprawkę stosuje się na niewłaściwej warstwie. Podwójna dzierżawa jest łatwa do potwierdzenia i uciążliwa w codziennym życiu. Przetrwa też restarty, bo obaj przydzielacze nadal upierają się przy tym samym adresie.

Trasa powrotna to osobny problem

Nawet z czystą, osobną pulą hosty sieci LAN muszą wiedzieć, jak odpowiedzieć klientowi. Ich brama domyślna to router, a router potrzebuje trasy dla puli wskazującej na serwer VPN, chyba że projekt tłumaczy zamiast tego ruch klienta.

Przeczytaj ścieżkę w obu kierunkach, zanim cokolwiek zmienisz. Na bramie zapytaj, którego interfejsu użyłby kernel dla adresu klienta; na kliencie zapytaj, której trasy używa dla adresu LAN.

Te polecenia pokazują decyzję przekazywania na bramie i wpisy sąsiadów, które ujawniają duplikat:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Jeśli pierwsze polecenie odpowiada interfejsem tunelu, trasa powrotna istnieje. Jeśli odpowiada interfejsem LAN, router uważa, że klient jest na kablu, i spróbuje wykonać dla niego ARP.

Projekty mostkowane istnieją, ale trzeba je wybrać

Mostkowanie tunelu do sieci LAN to prawdziwy projekt, używany, gdy klienci muszą odbierać rozgłoszenia albo być odkrywani przez protokoły zakładające jeden segment. Wymaga, aby serwer posiadał to zachowanie mostkowania i związane z nim zarządzanie adresami.

Nie działa naśladowanie wyniku przez kopiowanie numerów. Wspólna pula bez mostka daje konflikt bez wykrywania, co jest najgorszym z obu układów.

Wybierz warstwę trzecią z osobną pulą, chyba że aplikacja naprawdę potrzebuje segmentu, i udokumentuj pulę, aby następny administrator nie użył ponownie zakresu DHCP dla porządku.