DHCP över en VPN: broa broadcasten eller vidarebefordra den?
Klienter på andra sidan en tunnel får ingen adress. Bestäm om broadcasten ska bäras eller vidarebefordras, och håll DHCP åtskilt från ARP.
En ny laptop på andra sidan tunneln får ingen adress, medan samma laptop fungerar på huvudkontoret. Den vanliga första gissningen är att tunneln blockerar DHCP. Oftare har broadcasten aldrig haft en väg: en okonfigurerad klient skickar till 255.255.255.255, och en vanlig IP-router vidarebefordrar inte det paketet. Tunneln gör precis det en routad tunnel gör.
Två utformningar kan ändra det, och de är inte likvärdiga. Den ena bär broadcasten; den andra vidarebefordrar begäran.
Broadcasten korsar aldrig routern
En DHCPv4-klient utan adress skickar från 0.0.0.0 till den begränsade broadcastadressen på UDP-portarna 67 och 68. Det paketet stannar på sin länk enligt design. En router som vidarebefordrade det skulle översvämma varje segment den betjänar.
Så en routad plats-till-plats-tunnel kopplar relayen till en server. Den utökar inte klientens broadcastdomän, och ingen brandväggsregel får den att göra det.
Vad en bryggd tunnel faktiskt utökar
En medvetet bryggd VPN kan bära Ethernet-broadcast inom sin topologi som stöds, och då kan DHCP passera som lokal trafik. Det är ett reellt alternativ, men det är ett designval på lager 2. Du utökar feldomenet och åtkomstgränsen tillsammans med broadcasten.
Bryggning ändrar också vad en broadcaststorm, en ARP-skanning eller en falsk DHCP-server kan nå. Om du inte skulle koppla kontoret på distans till samma switch bör du inte brygga tunneln bara för att dela ut adresser. Testa den radien innan du aktiverar den.
Det är ett större beslut än att tillhandahålla en adress, och det bör fattas medvetet.
Vidarebefordra begäran i stället
Det vanliga svaret är en relay på klientens lokala nätverk. Den tar emot broadcasten, gör om den till en unicast-begäran och sätter sin egen adress i gateway-adressfältet. Servern svarar till den relayadressen.
För ett illustrativt kontor på distans sitter relayen på kontorets LAN och servern nås via platsens VPN. Konfigurera omfånget för det kontoret, relayens och serverns identiteter samt hela returvägen. Att tillåta UDP 67 genom tunneln talar inte om för servern vilken pool som ska användas.
En relay som vidarebefordrar men aldrig tar emot ett svar är oftast ett returvägsproblem. Kontrollera vägen tillbaka till relayadressen innan du ändrar omfånget.
Skilj DHCP från ARP och från tunneladressering
DHCP går över UDP/IP. På Ethernet kan en värd också använda ARP för att kontrollera om en kandidatadress redan används. Den konfliktkontrollen är en separat länklokal operation, inte transporten för DHCP-meddelanden. Att säga att DHCP i huvudsak är ARP är fel; att säga att de två aldrig har med varandra att göra är för brett.
En VPN-klient kan också få sin tunneladress från VPN-protokollet eller från serverns egen pool i stället för från en DHCP-broadcast. Ett alternativ med DHCP i namnet kan beskriva pushade klientinställningar, inte ett vidarebefordrat DHCP-paket. Kontrollera serverns pool innan du antar att DHCP är inblandat överhuvudtaget.
Anteckna mottagarnätverket, ägaren till tilldelningen, omfånget, om det finns en relay och det förväntade beteendet vid ett avbrott. Testa sedan en ny lease och en förnyelse genom den modellen. Om två platser kan betjäna samma ohanterade pool har du en konflikt som väntar på den första vandrande laptopen.