Hvorfor en Azure-VM med VPN-enhed taber returvejen
En VPN-enhed i en Azure-VM kræver, at UDR'en, videresendelsesflaget på netværkskortet og gæstens politik stemmer overens. Følg en enkelt anmodning fra filialen gennem alle tre.
En Azure-VM, der kører en VPN-enhed, står inde i to uafhængige beslutningssystemer. Azure bestemmer, hvor en pakke forlader et undernet, ved hjælp af rutetabeller og netværkskortets videresendelsesindstilling. Enhedens eget styresystem bestemmer, om det videresender den dekrypterede pakke. En tunnel, der kommer perfekt op, kan stadig fejle på det andet system, og det er der, de fleste af disse udrulninger stopper.
Tre ejere af én vej
Tag et filialnetværk på 192.168.50.0/24 og et arbejdsbelastningsundernet på 10.0.10.0/24, med enheden på 10.0.0.4 i sit eget undernet. En enkelt anmodning berører tre separate 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 |
Hver række ejes af et forskelligt team i de fleste organisationer, og derfor ankommer denne fejl normalt som tre billetter i stedet for én.
Ruten, der peger på enheden
Knyt en rutetabel til arbejdsbelastningsundernettet, og giv filialpræfikset et næste hop af typen Virtual appliance med 10.0.0.4 som adresse. Brug enhedens tilgængelige private adresse, aldrig dens offentlige VPN-indgangspunkt. Det næste hop skal være en adresse, som arbejdsbelastningsundernettet allerede kan nå. Lad resten af arbejdsbelastningens routing være i fred, medmindre du bevidst har besluttet at erstatte standardruten.
Hold enheden i sit eget undernet, og sørg for, at den rute, der sender filialtrafik til enheden, ikke også fanger enhedens egen udgående vej. En sådan løkke ser ud som en sund tunnel uden svar, og det er en elendig ting at fejlfinde klokken 2 om natten.
Det netværkskortflag, som alle glemmer
Azure har en IP-videresendelsesindstilling per netværkskort, og den er slået fra som standard. Den findes, fordi et videresendende kort modtager pakker adresseret til noget andet, og at droppe dem lydløst er den sikre standard for alle andre.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true slår den til for ét interface. Microsofts vejledning om videresendelse på netværkskortet kræver indstillingen på hvert tilsluttet kort, der videresender trafik, så en enhed med ét kort skal stadig have den sat på det kort.
Flaget er ikke en rute, og det er ikke en firewallregel. At slå det til giver tilladelse og intet andet.
Hvad gæsten gør med den dekrypterede pakke
Når tunnelen slutter, træffer enhedens egen stak den næste beslutning. På en Linux-gæst er IPv4-videresendelse en indstilling under kørsel, og sysctl -w net.ipv4.ip_forward=1 holder indtil næste opstart. Gem den i en fil under /etc/sysctl.d/ i stedet. En leverandørenhed har sin egen ækvivalent, og Linux-instruktioner, der indsættes på en leverandørplatform, gør normalt slet ingenting.
Gæstens firewallpolitik er igen adskilt, og det samme er arbejdsbelastningens netværkssikkerhedsgruppe. At tillade UDP 500 og 4500 til VM'ens offentlige adresse beskytter tunnelen; det siger intet om, hvorvidt en dekrypteret filialanmodning kan nå en arbejdsbelastningsport.
Følg én anmodning og dens svar
Vælg én tilladt flow, og spor den fra ende til anden. Filialen har brug for en rute til 10.0.10.0/24 over stedforbindelsen, enheden har brug for en leveringsvej til arbejdsbelastningsundernettet, og arbejdsbelastningsundernettet har brug for en returrute mod filialen.
Beslut tidligt, om designet bevarer filialens kildeadresse eller oversætter den. NAT ændrer, hvad arbejdsbelastningen ser, så dens adgangsregler bør beskrive den model, du faktisk valgte, og ikke en gættet gatewayadresse.
Et vellykket håndtryk beviser ét led i den kæde. Vejen er komplet, når svaret vender tilbage gennem samme enhed, og arbejdsbelastningens egen politik tillader det.