DHCP przez VPN: mostkować broadcast czy go przekazywać?

Nowy laptop po drugiej stronie tunelu nie dostaje adresu, choć ten sam laptop działa w centrali. Zwykłe pierwsze podejrzenie to blokowanie DHCP przez tunel. Częściej broadcast nigdy nie miał drogi: nieskonfigurowany klient wysyła na 255.255.255.255, a zwykły router IP nie przekazuje tego pakietu. Tunel robi dokładnie to, co robi tunel trasowany.

Dwa projekty mogą to zmienić i nie są równoważne. Jeden przenosi broadcast; drugi przekazuje żądanie.

Broadcast nigdy nie przekracza routera

Klient DHCPv4 bez adresu wysyła z 0.0.0.0 na ograniczony adres broadcast na portach UDP 67 i 68. Ten pakiet zgodnie z projektem zostaje na swoim łączu. Router, który by go przekazał, zalałby każdy obsługiwany przez siebie segment.

Zatem trasowany tunel między lokalizacjami łączy przekaźnik z serwerem. Nie rozszerza domeny broadcastu klienta i żadna reguła zapory tego nie sprawi.

Co mostkowany tunel naprawdę rozszerza

Celowo mostkowany VPN może przenosić broadcast Ethernetu w ramach swojej obsługiwanej topologii, a wtedy DHCP może przejść jako ruch lokalny. To realna opcja, ale to decyzja projektowa warstwy 2. Rozszerzasz domenę awarii i granicę dostępu razem z broadcastem.

Mostkowanie zmienia też to, do czego mogą dotrzeć burza broadcastowa, skan ARP czy fałszywy serwer DHCP. Jeśli nie podłączyłbyś biura zdalnego do tego samego przełącznika, nie mostkuj tunelu tylko po to, by rozdawać adresy. Przetestuj ten promień rażenia, zanim to włączysz.

To większa decyzja niż dostarczenie adresu i powinna być podjęta świadomie.

Zamiast tego przekazuj żądanie

Zwykła odpowiedź to przekaźnik w sieci lokalnej klienta. Odbiera broadcast, zamienia go na żądanie unicast i wpisuje własny adres w pole adresu bramy. Serwer odpowiada na ten adres przekaźnika.

Dla przykładowego biura zdalnego przekaźnik stoi w sieci LAN biura, a serwer jest osiągany przez VPN lokalizacji. Skonfiguruj zakres dla tego biura, tożsamości przekaźnika i serwera oraz pełną drogę powrotną. Zezwolenie na UDP 67 przez tunel nie mówi serwerowi, której puli użyć.

Przekaźnik, który przekazuje, ale nigdy nie odbiera odpowiedzi, to zwykle problem drogi powrotnej. Sprawdź trasę z powrotem do adresu przekaźnika, zanim zmienisz zakres.

Oddziel DHCP od ARP i od adresowania tunelu

DHCP działa przez UDP/IP. W Ethernetcie host może też użyć ARP, by sprawdzić, czy adres kandydujący nie jest już zajęty. To sprawdzenie konfliktu jest osobną operacją lokalną dla łącza, a nie transportem komunikatów DHCP. Twierdzenie, że DHCP to w istocie ARP, jest błędne; twierdzenie, że te dwa nigdy nie mają związku, jest zbyt szerokie.

Klient VPN może też otrzymać adres tunelu z protokołu VPN albo z własnej puli serwera, a nie z broadcastu DHCP. Opcja, której nazwa zawiera DHCP, może opisywać wypychane ustawienia klienta, a nie przekazany pakiet DHCP. Sprawdź pulę serwera, zanim założysz, że DHCP w ogóle uczestniczy.

Zapisz sieć odbiorcy, właściciela przydziału, zakres, istnienie przekaźnika i oczekiwane zachowanie podczas awarii. Następnie przetestuj nową dzierżawę i odnowienie według tego modelu. Jeśli dwie lokalizacje mogą obsługiwać tę samą niezarządzaną pulę, masz konflikt czekający na pierwszy wędrujący laptop.