Ein Azure-VM som køyrer ei VPN-eining, står inne i to uavhengige avgjerdsystem. Azure avgjer kvar ei pakke forlèt eit subnett, ved hjelp av rutetabellar og vidaresendingsinnstillinga til nettverkskortet. Operativsystemet til eininga sjølv avgjer om det vidaresender den dekrypterte pakka. Ein tunnel som kjem perfekt opp, kan likevel feile på det andre systemet, og det er der dei fleste av desse utrullingane stoppar.

Tre eigarar av éin veg

Ta eit filialnett på 192.168.50.0/24 og eit arbeidslastsubnett på 10.0.10.0/24, med eininga på 10.0.0.4 i sitt eige subnett. Éin einaste førespurnad rører tre separate konfigurasjonar.

DecisionConfigured inHow it fails
Where the workload subnet sends branch trafficAzure route table entryTraffic leaves the subnet and never reaches the appliance
Whether a NIC may accept traffic not addressed to itAzure NIC IP forwardingPackets arrive and disappear at the interface
Whether the guest forwards decrypted trafficGuest OS or vendor appliance policyTunnel is up, workload is unreachable
Whether the workload accepts the sourceNSG and service policyRequests delivered, replies refused

Kvar rad blir eigd av eit ulikt team i dei fleste organisasjonar, og difor kjem denne feilen vanlegvis som tre billettar i staden for éin.

Ruta som peikar på eininga

Knyt ein rutetabell til arbeidslastsubnettet og gje filialprefikset eit neste hopp av typen Virtual appliance med 10.0.0.4 som adresse. Bruk den tilgjengelege private adressa til eininga, aldri det offentlege VPN-innkøyringspunktet hennar. Det neste hoppet må vere ei adresse som arbeidslastsubnettet allereie kan nå. Lat resten av rutinga til arbeidslasta vere i fred, med mindre du medvite har bestemt deg for å bytte ut standardruta.

Hald eininga i sitt eige subnett, og sjå til at ruta som sender filialtrafikk til eininga, ikkje òg fangar den eigne utgåande vegen til eininga. Ei slik løkke ser ut som ein sunn tunnel utan svar, og det er ein elendig ting å feilsøkje klokka 2 om natta.

Nettverkskortflagget som alle gløymer

Azure har ei IP-vidaresendingsinnstilling per nettverkskort, og ho er av som standard. Ho finst fordi eit vidaresendande kort tek imot pakkar som er adresserte til noko anna, og å sleppe dei lydlaust er den trygge standarden for alle andre.

az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true slår ho på for eitt grensesnitt. Retningslinjene til Microsoft om vidaresending på nettverkskortet krev innstillinga på kvart tilkopla kort som vidaresender trafikk, så ei eining med eitt kort treng ho likevel sett på det kortet.

Flagget er ikkje ei rute, og det er ikkje ei brannmurregel. Å slå det på gir løyve og ingenting anna.

Kva gjesten gjer med den dekrypterte pakka

Når tunnelen er slutt, tek den eigne stablen til eininga den neste avgjerda. På ein Linux-gjest er IPv4-vidaresending ei innstilling under køyring, og sysctl -w net.ipv4.ip_forward=1 varer til neste oppstart. Lagre ho i ei fil under /etc/sysctl.d/ i staden. Ei eining frå ein leverandør har sin eigen ekvivalent, og Linux-instruksjonar som blir limde inn i ein leverandørplattform, gjer vanlegvis absolutt ingenting.

Brannmurpolicyen til gjesten er igjen separat, og det same er nettverkssikkerheitsgruppa til arbeidslasta. Å tillate UDP 500 og 4500 til den offentlege adressa til VM-en verner tunnelen; det seier ingenting om ein dekryptert filialførespurnad kan nå ein arbeidslastport.

Følg éin førespurnad og svaret på han

Vel éin tillaten flyt og spor han frå ende til annan. Filialen treng ei rute for 10.0.10.0/24 over stadstilkoplinga, eininga treng ein leveringsveg til arbeidslastsubnettet, og arbeidslastsubnettet treng ei returrute mot filialen.

Avgjer tidleg om designet bevarar kjeldeadressa til filialen eller omset ho. NAT endrar det arbeidslasta ser, så tilgangsreglane bør skildre modellen du faktisk valde, ikkje ei gjetta gatewayadresse.

Eit vellukka handtrykk beviser éi lenkje i den kjeda. Vegen er fullstendig når svaret kjem tilbake gjennom same eining og eigen policy for arbeidslasta tillèt det.

Relaterte artiklar