Por que unha VM de Azure cun dispositivo VPN perde o camiño de volta
Un dispositivo VPN nunha VM de Azure necesita que a UDR, o indicador de reenvío da tarxeta de rede e a política do convidado coincidan. Siga unha petición de sucursal polas tres.
Unha VM de Azure que executa un dispositivo VPN está dentro de dous sistemas de decisión independentes. Azure decide por onde sae un paquete dunha subrede, usando táboas de rutas e o axuste de reenvío da tarxeta de rede. O sistema operativo do propio dispositivo decide se reenvía o paquete descifrado. Un túnel que sobe perfectamente pode fallar igualmente no segundo sistema, e aí é onde se deteñen a maioría destes despregamentos.
Tres propietarios dun mesmo camiño
Colla unha rede de sucursal 192.168.50.0/24 e unha subrede de carga de traballo 10.0.10.0/24, co dispositivo en 10.0.0.4 na súa propia subrede. Unha soa petición toca tres configuracións separadas.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
Cada fila pertence a un equipo distinto na maioría das organizacións, e por iso esta falla adoita chegar como tres tíckets en lugar dun.
A ruta que apunta ao dispositivo
Asocie unha táboa de rutas á subrede de carga de traballo e dea ao prefixo da sucursal un seguinte salto de tipo Virtual appliance con 10.0.0.4 como enderezo. Use o enderezo privado accesible do dispositivo, nunca o seu punto de entrada público de VPN. O seguinte salto ten que ser un enderezo que a subrede de carga de traballo xa poida acadar. Deixe o resto do encamiñamento da carga de traballo como está, salvo que decidise deliberadamente substituír a ruta predeterminada.
Manteña o dispositivo na súa propia subrede e asegúrese de que a ruta que envía o tráfico da sucursal ao dispositivo non capture tamén o camiño de saída do propio dispositivo. Ese bucle parece un túnel san con cero respostas, e é algo moi desagradable de depurar ás 2 da madrugada.
O indicador da tarxeta de rede que todos esquecen
Azure ten un axuste de reenvío de IP por tarxeta de rede, e está desactivado por defecto. Existe porque unha tarxeta que reenvía recibe paquetes dirixidos a outra cousa, e descartalos en silencio é o valor seguro por defecto para todos os demais.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true actívao para unha interface. As directrices de Microsoft sobre o reenvío na tarxeta de rede requiren o axuste en cada tarxeta conectada que reenvíe tráfico, así que un dispositivo dunha soa tarxeta aínda o necesita nesa tarxeta.
O indicador non é unha ruta nin unha regra de devasa. Activalo concede permiso e nada máis.
Que fai o convidado co paquete descifrado
Cando o túnel remata, a pila do propio dispositivo toma a seguinte decisión. Nun convidado Linux, o reenvío de IPv4 é un axuste de execución, e sysctl -w net.ipv4.ip_forward=1 dura ata o seguinte arrinque. Gárdeo nun ficheiro baixo /etc/sysctl.d/ no seu lugar. Un dispositivo de provedor ten o seu propio equivalente, e as instrucións de Linux pegadas nunha plataforma de provedor normalmente non fan absolutamente nada.
A política de devasa do convidado volve ser aparte, e tamén o grupo de seguridade de rede da carga de traballo. Permitir UDP 500 e 4500 cara ao enderezo público da VM protexe o túnel; non di nada sobre se unha petición de sucursal descifrada pode chegar a un porto da carga de traballo.
Siga unha petición e a súa resposta
Escolla un fluxo permitido e séguoo de punta a punta. A sucursal necesita unha ruta para 10.0.10.0/24 a través da conexión de sitio, o dispositivo necesita un camiño de entrega cara á subrede de carga de traballo, e a subrede de carga de traballo necesita unha ruta de volta cara á sucursal.
Decida pronto se o deseño conserva o enderezo de orixe da sucursal ou o traduce. O NAT cambia o que ve a carga de traballo, así que as súas regras de acceso deberían describir o modelo que escolleu realmente e non un enderezo de pasarela suposto.
Unha aperta de mans correcta demostra un elo desa cadea. O camiño está completo cando a resposta volve polo mesmo dispositivo e a política da propia carga de traballo o permite.