Hvorfor en Azure-VM med VPN-enhet mister returveien
En VPN-enhet i en Azure-VM trenger at UDR-en, videresendingsflagget på nettverkskortet og gjestepolicyen stemmer overens. Følg én forespørsel fra filialen gjennom alle tre.
En Azure-VM som kjører en VPN-enhet, står inne i to uavhengige beslutningssystemer. Azure bestemmer hvor en pakke forlater et subnett, ved hjelp av rutetabeller og nettverkskortets videresendingsinnstilling. Enhetens eget operativsystem bestemmer om den videresender den dekrypterte pakken. En tunnel som kommer perfekt opp, kan likevel feile på det andre systemet, og det er der de fleste av disse utrullingene stopper.
Tre eiere av én vei
Ta et filialnett på 192.168.50.0/24 og et arbeidsbelastningssubnett på 10.0.10.0/24, med enheten på 10.0.0.4 i sitt eget subnett. Én enkelt forespørsel berører tre separate konfigurasjoner.
| 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 rad eies av et ulikt team i de fleste organisasjoner, og derfor kommer denne feilen vanligvis som tre billetter i stedet for én.
Ruten som peker på enheten
Knytt en rutetabell til arbeidsbelastningssubnettet og gi filialprefikset et neste hopp av typen Virtual appliance med 10.0.0.4 som adresse. Bruk enhetens tilgjengelige private adresse, aldri dens offentlige VPN-inngangspunkt. Det neste hoppet må være en adresse som arbeidsbelastningssubnettet allerede kan nå. La resten av rutingen til arbeidsbelastningen være i fred, med mindre du bevisst har bestemt deg for å erstatte standardruten.
Hold enheten i sitt eget subnett, og sørg for at ruten som sender filialtrafikk til enheten, ikke også fanger enhetens egen utgående vei. En slik løkke ser ut som en sunn tunnel uten svar, og det er en elendig ting å feilsøke klokken 2 om natten.
Nettverkskortflagget som alle glemmer
Azure har en IP-videresendingsinnstilling per nettverkskort, og den er av som standard. Den finnes fordi et videresendende kort mottar pakker adressert til noe annet, og å droppe dem lydløst er den trygge standarden for alle andre.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true slår den på for ett grensesnitt. Microsofts veiledning for videresending på nettverkskortet krever innstillingen på hvert tilkoblede kort som videresender trafikk, så en enhet med ett kort trenger den likevel satt på det kortet.
Flagget er ikke en rute, og det er ikke en brannmurregel. Å slå det på gir tillatelse og ingenting annet.
Hva gjesten gjør med den dekrypterte pakken
Når tunnelen avsluttes, tar enhetens egen stakk den neste beslutningen. På en Linux-gjest er IPv4-videresending en innstilling under kjøring, og sysctl -w net.ipv4.ip_forward=1 varer til neste oppstart. Lagre den i en fil under /etc/sysctl.d/ i stedet. En leverandørenhet har sin egen ekvivalent, og Linux-instruksjoner som limes inn i en leverandørplattform, gjør vanligvis absolutt ingenting.
Gjestens brannmurpolicy er igjen separat, og det samme er arbeidsbelastningens nettverkssikkerhetsgruppe. Å tillate UDP 500 og 4500 til VM-ens offentlige adresse beskytter tunnelen; det sier ingenting om hvorvidt en dekryptert filialforespørsel kan nå en arbeidsbelastningsport.
Følg én forespørsel og svaret på den
Velg én tillatt flyt og spor den fra ende til annen. Filialen trenger en rute for 10.0.10.0/24 over stedsforbindelsen, enheten trenger en leveringsvei til arbeidsbelastningssubnettet, og arbeidsbelastningssubnettet trenger en returrute mot filialen.
Bestem tidlig om designet bevarer filialens kildeadresse eller oversetter den. NAT endrer det arbeidsbelastningen ser, så tilgangsreglene bør beskrive modellen du faktisk valgte, ikke en gjettet gatewayadresse.
En vellykket håndtrykk beviser én lenke i den kjeden. Veien er komplett når svaret kommer tilbake gjennom samme enhet, og arbeidsbelastningens egen policy tillater det.