DHCP através de uma VPN: pontuar o broadcast ou encaminhá-lo?

Um portátil novo do outro lado do túnel não obtém endereço, embora o mesmo portátil funcione na sede. A primeira suspeita habitual é que o túnel bloqueia o DHCP. Mais frequentemente o broadcast nunca teve caminho: um cliente não configurado envia para 255.255.255.255, e um router IP comum não encaminha esse pacote. O túnel faz exatamente o que faz um túnel encaminhado.

Dois desenhos podem mudar isso, e não são equivalentes. Um transporta o broadcast; o outro encaminha o pedido.

O broadcast nunca atravessa o router

Um cliente DHCPv4 sem endereço envia de 0.0.0.0 para o endereço de broadcast limitado nas portas UDP 67 e 68. Esse pacote fica no seu link por desenho. Um router que o encaminhasse estaria a inundar cada segmento que serve.

Assim, um túnel encaminhado de site para site liga o relay a um servidor. Não amplia o domínio de broadcast do cliente, e nenhuma regra de firewall o fará.

O que um túnel pontuado alarga na prática

Uma VPN deliberadamente pontuada pode transportar broadcast Ethernet dentro da sua topologia suportada, e então o DHCP pode passar como tráfego local. É uma opção real, mas é uma decisão de desenho de camada 2. Está a ampliar o domínio de falha e a fronteira de acesso juntamente com o broadcast.

A ponte também altera o que uma tempestade de broadcast, uma varredura ARP ou um servidor DHCP fraudulento podem alcançar. Se não ligaria o escritório remoto ao mesmo comutador, não ponte o túnel só para distribuir endereços. Teste esse raio de impacto antes de o ativar.

É uma decisão maior do que fornecer um endereço, e deve ser tomada deliberadamente.

Encaminhe o pedido em vez disso

A resposta habitual é um relay na rede local do cliente. Recebe o broadcast, transforma-o num pedido unicast e coloca o seu próprio endereço no campo de endereço da gateway. O servidor responde para esse endereço do relay.

Para um escritório remoto ilustrativo, o relay fica na LAN do escritório e o servidor é alcançado pela VPN do site. Configure o âmbito para esse escritório, as identidades do relay e do servidor, e o caminho de retorno completo. Permitir UDP 67 pelo túnel não diz ao servidor que conjunto usar.

Um relay que encaminha mas nunca recebe resposta é normalmente um problema de caminho de retorno. Verifique a rota de volta ao endereço do relay antes de alterar o âmbito.

Separe o DHCP do ARP e do endereçamento do túnel

O DHCP viaja sobre UDP/IP. No Ethernet, um host também pode usar ARP para verificar se um endereço candidato já está em uso. Essa verificação de conflito é uma operação local ao link separada, não o transporte das mensagens DHCP. Dizer que o DHCP é essencialmente ARP está errado; dizer que os dois nunca se relacionam é demasiado amplo.

Um cliente VPN também pode obter o seu endereço de túnel a partir do protocolo VPN ou do próprio conjunto do servidor, em vez de um broadcast DHCP. Uma opção cujo nome contenha DHCP pode descrever definições do cliente enviadas, não um pacote DHCP encaminhado. Verifique o conjunto do servidor antes de assumir que o DHCP está envolvido.

Registe a rede destinatária, o proprietário da atribuição, o âmbito, se existe um relay e o comportamento esperado durante uma falha. Depois teste uma concessão nova e uma renovação através desse modelo. Se dois sites podem servir o mesmo conjunto não gerido, tem um conflito à espera do primeiro portátil itinerante.