Azure-VM sem keyrir VPN-tæki stendur innan tveggja óháðra ákvörðunarkerfa. Azure ákveður hvaðan pakki yfirgefur undirnet, með því að nota leiðartöflur og framsendingarstillingu netkortsins. Stýrikerfi tækisins sjálfs ákveður hvort það sendir afkóðaða pakkann áfram. Göng sem koma fullkomlega upp geta samt mistekist í seinna kerfinu, og þar stöðvast flestar þessar uppsetningar.

Þrír eigendur að einni leið

Taktu útibúsnet 192.168.50.0/24 og vinnuálagsundirnet 10.0.10.0/24, tækið er á 10.0.0.4 í sínu eigin undirneti. Ein beiðni snertir þrjár aðskildar stillingar.

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

Hver röð er í eigu annars teymis í flestum samtökum, og þess vegna kemur þessi bilun venjulega sem þrjú mál í stað eins.

Leiðin sem bendir á tækið

Tengdu leiðartöflu við vinnuálagsundirnetið og gefðu útibúsforskeytinu næsta stökk af gerðinni Virtual appliance með 10.0.0.4 sem heimilisfang. Notaðu aðgengilegt einkarefsheimilisfang tækisins, aldrei opinberan VPN-inngangspunkt þess. Næsta stökk verður að vera heimilisfang sem vinnuálagsundirnetið getur þegar náð til. Láttu afganginn af leiðavali vinnuálagsins ósnortinn, nema þú hafir viljandi ákveðið að skipta út sjálfgefnu leiðinni.

Haltu tækinu í sínu eigin undirneti og tryggðu að leiðin sem sendir umferð útibúsins til tækisins grípi ekki líka eigin útleið tækisins. Slík lykkja lítur út eins og heilbrigð göng án svara, og það er mjög óþægilegt að villuleita klukkan 2 að nóttu.

Netkortsflagið sem allir gleyma

Azure hefur IP-framsendingarstillingu fyrir hvert netkort, og hún er slökkt að sjálfgefnu. Hún er til vegna þess að framsendingarkort tekur við pökkum sem eru stílaðir á eitthvað annað, og að sleppa þeim hljóðlaust er örugga sjálfgefna stillingin fyrir alla aðra.

az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true kveikir á henni fyrir eitt tengi. Leiðbeiningar Microsoft um framsendingu á netkortinu krefjast stillingarinnar á hverju tengdu korti sem sendir umferð áfram, svo tæki með eitt kort þarf hana samt setta á það kort.

Flagið er ekki leið og ekki eldveggjarregla. Að kveikja á því veitir leyfi og ekkert annað.

Hvað gesturinn gerir við afkóðaða pakkann

Þegar göngin enda tekur eigin stakkur tækisins næstu ákvörðun. Á Linux gesti er IPv4-framsending keyrslutímastilling, og sysctl -w net.ipv4.ip_forward=1 varir til næstu ræsingar. Vistaðu hana í skrá undir /etc/sysctl.d/ í staðinn. Tæki frá framleiðanda hefur sína eigin samsvarandi lausn, og Linux-leiðbeiningar sem límdar eru inn í vettvang framleiðanda gera venjulega alls ekki neitt.

Eldveggjarstefna gestsins er aftur aðskilin, og það sama á við um netöryggishóp vinnuálagsins. Að leyfa UDP 500 og 4500 á opinbert heimilisfang VM-sins verndar göngin; það segir ekkert um hvort afkóðuð beiðni frá útibúi geti náð porti vinnuálagsins.

Fylgdu einni beiðni og svarinu við henni

Veldu eitt leyft flæði og fylgdu því frá upphafi til enda. Útibúið þarf leið fyrir 10.0.10.0/24 yfir staðartenginguna, tækið þarf afhendingarleið að vinnuálagsundirnetinu, og vinnuálagsundirnetið þarf afturleið til útibúsins.

Ákveddu snemma hvort hönnunin varðveitir upprunheimilisfang útibúsins eða þýðir það. NAT breytir því sem vinnuálagið sér, svo aðgangsreglur þess ættu að lýsa því líkani sem þú valdir í raun og veru, ekki giskað heimilisfang gáttar.

Árangursrík handaband sannar eina hlekk í þeirri keðju. Leiðin er heil þegar svarið kemur til baka um sama tæki og eigin stefna vinnuálagsins leyfir það.

Tengdir greinar