Varför en Azure-VM med VPN-enhet tappar returvägen
En VPN-enhet i en Azure-VM behöver att UDR:en, vidarebefordringsflaggan på nätverkskortet och gästpolicyn stämmer överens. Följ en filialförfrågan genom alla tre.
En Azure-VM som kör en VPN-enhet står inne i två oberoende beslutsystem. Azure avgör var ett paket lämnar ett undernät, med hjälp av routtabeller och nätverkskortets vidarebefordringsinställning. Enhetens eget operativsystem avgör om det vidarebefordrar det dekrypterade paketet. En tunnel som kommer upp perfekt kan ändå misslyckas i det andra systemet, och det är där de flesta av dessa utrullningar stannar.
Tre ägare av en väg
Ta ett filialnät på 192.168.50.0/24 och ett arbetsbelastningsundernät på 10.0.10.0/24, med enheten på 10.0.0.4 i sitt eget undernät. En enda förfrågan berör tre separata konfigurationer.
| 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 |
Varje rad ägs av ett annat team i de flesta organisationer, och därför kommer det här felet vanligtvis som tre ärenden i stället för ett.
Rutten som pekar på enheten
Koppla en routtabell till arbetsbelastningsundernätet och ge filialprefixet ett nästa hopp av typen Virtual appliance med 10.0.0.4 som adress. Använd enhetens nåbara privata adress, aldrig dess offentliga VPN-ingångspunkt. Nästa hopp måste vara en adress som arbetsbelastningsundernätet redan kan nå. Låt resten av arbetsbelastningens routning vara ifred, om du inte medvetet har beslutat att ersätta standardrutten.
Håll enheten i sitt eget undernät och se till att rutten som skickar filialtrafik till enheten inte också fångar enhetens egen utgående väg. En sådan slinga ser ut som en frisk tunnel utan svar, och det är en eländig sak att felsöka klockan 2 på natten.
Nätverkskortsflaggan som alla glömmer
Azure har en IP-vidarebefordringsinställning per nätverkskort, och den är av som standard. Den finns eftersom ett vidarebefordrande kort tar emot paket adresserade till något annat, och att släppa dem tyst är standardvalet som är säkert för alla andra.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true slår på den för ett gränssnitt. Microsofts vägledning om vidarebefordring på nätverkskortet kräver inställningen på varje anslutet kort som vidarebefordrar trafik, så en enhet med ett kort behöver den ändå satt på det kortet.
Flaggan är inte en rutt och inte en brandväggsregel. Att slå på den ger tillstånd och ingenting annat.
Vad gästen gör med det dekrypterade paketet
När tunneln tar slut fattar enhetens egen stack nästa beslut. På en Linux-gäst är IPv4-vidarebefordring en inställning under körning, och sysctl -w net.ipv4.ip_forward=1 varar till nästa start. Spara den i en fil under /etc/sysctl.d/ i stället. En leverantörsenhet har sin egen motsvarighet, och Linux-instruktioner som klistras in i en leverantörsplattform gör vanligtvis absolut ingenting.
Gästens brandväggspolicy är återigen separat, och detsamma gäller arbetsbelastningens nätverkssäkerhetsgrupp. Att tillåta UDP 500 och 4500 till VM:ens offentliga adress skyddar tunneln; det säger ingenting om huruvida en dekrypterad filialförfrågan kan nå en arbetsbelastningsport.
Följ en förfrågan och dess svar
Välj ett tillåtet flöde och följ det från början till slut. Filialen behöver en rutt för 10.0.10.0/24 över platsanslutningen, enheten behöver en leveransväg till arbetsbelastningsundernätet, och arbetsbelastningsundernätet behöver en returrutt mot filialen.
Bestäm tidigt om designen bevarar filialens källadress eller översätter den. NAT ändrar vad arbetsbelastningen ser, så dess åtkomstregler bör beskriva den modell du faktiskt valde och inte en gissad gatewayadress.
Ett lyckat handskakning bevisar en länk i den kedjan. Vägen är komplett när svaret kommer tillbaka genom samma enhet och arbetsbelastningens egen policy tillåter det.