Per què una VM d’Azure amb un dispositiu VPN perd el camí de tornada
Un dispositiu VPN en una VM d’Azure necessita que la UDR, el flag de reenviament de la targeta i la política del convidat coincideixin. Seguiu una petició de sucursal pels tres.
Una VM d’Azure que executa un dispositiu VPN es troba dins de dos sistemes de decisió independents. Azure decideix per on surt un paquet d’una subxarxa, fent servir taules de rutes i el paràmetre de reenviament de la targeta de xarxa. El sistema operatiu del propi dispositiu decideix si reenvia el paquet desxifrat cap endavant. Un túnel que puja perfectament encara pot fallar al segon sistema, i aquí és on s’aturen la majoria d’aquests desplegaments.
Tres propietaris d’un sol camí
Agafeu una xarxa de sucursal 192.168.50.0/24 i una subxarxa de càrrega de treball 10.0.10.0/24, amb el dispositiu a 10.0.0.4 dins de la seva pròpia subxarxa. Una sola petició toca tres configuracions separades.
| 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 la gestiona un equip diferent a la majoria d’organitzacions, i per això aquesta fallada sol arribar com tres tiquets en lloc d’un.
La ruta que apunta al dispositiu
Associeu una taula de rutes a la subxarxa de càrrega de treball i doneu al prefix de la sucursal un salt següent de tipus Virtual appliance amb 10.0.0.4 com a adreça. Feu servir l’adreça privada accessible del dispositiu, mai el seu punt d’entrada públic de VPN. El salt següent ha de ser una adreça que la subxarxa de càrrega de treball ja pugui assolir. Deixeu la resta de l’encaminament de la càrrega de treball tal com és, tret que hàgiu decidit deliberadament substituir la ruta per defecte.
Mantingueu el dispositiu a la seva pròpia subxarxa i assegureu-vos que la ruta que envia el trànsit de sucursal al dispositiu no capturi també el camí de sortida del propi dispositiu. Aquest bucle sembla un túnel sa amb zero respostes, i és una cosa molt desagradable de depurar a les 2 de la matinada.
El flag de la targeta que tothom oblida
Azure té un paràmetre de reenviament d’IP per targeta, i està desactivat per defecte. Existeix perquè una targeta que reenvia rep paquets adreçats a una altra cosa, i descartar-los en silenci és el defecte segur per a tothom.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true l’activa per a una interfície. Les directrius de Microsoft sobre el reenviament a la targeta de xarxa requereixen el paràmetre a cada targeta connectada que reenviï trànsit, així que un dispositiu d’una sola targeta encara el necessita en aquesta targeta.
El flag no és una ruta i no és una regla de tallafocs. Activar-lo atorga permís i res més.
Què fa el convidat amb el paquet desxifrat
Un cop el túnel acaba, la pila del propi dispositiu pren la decisió següent. En un convidat Linux, el reenviament d’IPv4 és un paràmetre d’execució i sysctl -w net.ipv4.ip_forward=1 dura fins al proper reinici. Deseu-lo en un fitxer sota /etc/sysctl.d/ en lloc d’això. Un dispositiu de proveïdor té el seu equivalent, i les instruccions de Linux enganxades en una plataforma de proveïdor normalment no fan absolutament res.
La política de tallafocs del convidat torna a ser separada, i també el grup de seguretat de xarxa de la càrrega de treball. Permetre UDP 500 i 4500 cap a l’adreça pública de la VM protegeix el túnel; no diu res sobre si una petició de sucursal desxifrada pot arribar a un port de la càrrega de treball.
Seguiu una petició i la seva resposta
Trieu un flux permès i resseguiu-lo de punta a punta. La sucursal necessita una ruta per a 10.0.10.0/24 a través de la connexió del lloc, el dispositiu necessita un camí de lliurament cap a la subxarxa de càrrega de treball, i la subxarxa de càrrega de treball necessita una ruta de tornada cap a la sucursal.
Decidiu aviat si el disseny conserva l’adreça d’origen de la sucursal o la tradueix. El NAT canvia el que veu la càrrega de treball, així que les seves regles d’accés haurien de descriure el model que heu triat realment i no una adreça de passarel·la suposada.
Un handshake correcte demostra un enllaç d’aquesta cadena. El camí és complet quan la resposta torna pel mateix dispositiu i la política de la pròpia càrrega de treball ho permet.