Adres VPN a dzierżawa DHCP w sieci LAN: kto przydziela IP tunelu?

Podłącz klienta i patrz na kartę sieciową, a nie na ikonę Wi-Fi. Adres taki jak 10.80.0.14 może siedzieć na tunelu, choć żaden serwer DHCP w sieci biurowej nigdy nie zapisał tej dzierżawy. To, który proces wybrał numer, decyduje, gdzie zaczyna się diagnoza.

Na kliencie wszystko wygląda tak samo: jeden adres IPv4, jedna maska, czasem brama domyślna. Różnica ujawnia się dopiero wtedy, gdy zapytasz, kto odpowiada za ten adres i kto prowadzi jego rejestr.

Odczytaj adres tunelu od strony klienta

Windows pokazuje różnicę, jeśli przeczytasz cały blok, a nie pierwszy wiersz. ipconfig /all wypisuje opis karty, adres fizyczny i wiersz DHCP. Karta połączenia telefonicznego PPP lub IKEv2 zwykle zgłasza DHCP jako wyłączone, ponieważ połączenie wynegocjowało adres podczas wybierania, zamiast dzierżawić go z serwera LAN. Karta tunelu z włączonym DHCP jest nietypowa i zasługuje na osobne zbadanie.

Linux dzieli tę samą informację między dwa narzędzia. ip -4 addr show dev tun0 podaje adres i długość prefiksu. nmcli -f IP4 connection show work ujawnia, czy wartość pochodzi z profilu połączenia, z wymiany DHCP na łączu, czy z konfiguracji wepchniętej. WireGuard to najjaśniejszy przypadek, ponieważ wg-quick stosuje wiersz Address z pliku konfiguracji, gdy interfejs się pojawia, a żaden partner nic nie przydziela w chwili połączenia.

Prefiks też coś mówi. /32 lub maska 255.255.255.255 oznacza, że brama oczekuje routingu do jednego adresu hosta, natomiast szersza maska sugeruje podsieć na łączu gdzieś za tunelem.

Co niesie ładunek konfiguracji IKEv2

IKEv2 ma do tego osobny mechanizm. Ładunek konfiguracji opisany w RFC 7296, sekcja 3.15.1 niesie atrybuty takie jak INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS i ich odpowiedniki IPv6. Klient wysyła atrybut o zerowej długości, gdy nie ma preferencji, a odpowiadający zwraca wartość, która ma zostać użyta. Ta wymiana biegnie wewnątrz IKE_AUTH, już zaszyfrowana, więc żadna transmisja rozgłoszeniowa DHCP nie przekracza tunelu.

Wynikają z tego dwie rzeczy. Po pierwsze, adres wybiera odpowiadający lub dowolny backend autoryzacji, z którym się konsultuje, dlatego pula może mieszkać na bramie, w odpowiedzi RADIUS lub w mapowaniu dostawcy tożsamości. Po drugie, atrybut DNS jest oddzielony od atrybutu adresu. Otrzymanie 10.80.0.14 nie mówi nic o tym, który resolver wrócił ani czy w ogóle jakiś wrócił.

Atrybut maski sieci jest w praktyce opcjonalny. Wiele wdrożeń zwraca tylko adres i pozwala klientowi zainstalować trasę do hosta, dlatego ta sama pula może wyglądać jak /32 na jednym kliencie i /24 na innym.

Gdzie zderzają się zakres DHCP sieci LAN i pula VPN

Kłopoty zaczynają się, gdy oba przydzielacze wskazują ten sam zakres. Serwer DHCP dla 10.20.30.0/24 nic nie wie o puli VPN skonfigurowanej dla 10.20.30.128/25, więc nic nie przeszkadza mu wydzierżawić 10.20.30.140 drukarce, podczas gdy brama daje ten sam adres klientowi zdalnemu. Kolizja pozostaje cicha przez wiele dni, a potem ujawnia się jako sporadyczny duplikat.

Routowany projekt witryna-witryna unika kolizji z samej konstrukcji. Host w oddziale zachowuje adres, który dał mu lokalny serwer DHCP. Interfejsy tunelu na obu bramach mają własne adresy łącza, a tabela routingu decyduje, jak podróżują pakiety. Adresy klientów dostępu zdalnego to trzecia kategoria i nie należy ich mieszać z adresami łącza bramy.

Mostkowanie tunelu do sieci LAN usuwa ten podział. Jeśli projekt naprawdę potrzebuje jednej domeny rozgłoszeniowej, punkt końcowy VPN musi uczestniczyć w tych samych decyzjach przydziału co serwer DHCP, przez przekaźnik lub wspólne źródło autorytatywne, zamiast samodzielnie wydawać adresy.

Sprawdź, który proces posiada adres

Udowodnij własność, zanim zmienisz zakres. Na kliencie zapisz adres i prefiks. W sieci LAN przeszukaj bazę dzierżaw. Na bramie wypisz pule, które jest skonfigurowana rozdawać. Adres znaleziony w pliku dzierżaw należy do serwera DHCP, co oznacza, że tunel jest mostkowany lub przekazywany przez przekaźnik; adres znaleziony tylko w puli bramy należy do punktu końcowego tunelu.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Zapisz cztery rzeczy, gdy odpowiedź będzie jasna: który komponent przydziela adres klienta, jaki zakres jest dla niego zarezerwowany, jak ruch powrotny dociera do tego zakresu i jakie zasoby go akceptują. Te cztery wpisy zamieniają wiersz wirtualnej karty w fakt operacyjny.

Powtórz sprawdzenie atrybutu DNS, póki tam jesteś. Pula, która rozdaje adresy bez resolvera, zostawia klienta na jego lokalnym DNS, co jest inną awarią niż pula rozdająca adres, którego sieć LAN już używa.