Azure VM, kuriame veikia VPN įrenginys, yra dviejose nepriklausomose sprendimų sistemose. Azure nusprendžia, iš kur paketas palieka potinklį, naudodamas maršrutų lenteles ir tinklo kortelės persiuntimo nuostatą. Pati įrenginio operacinė sistema nusprendžia, ar persiųsti iššifruotą paketą toliau. Tobulai pakylantis tunelis vis tiek gali nepavykti antrojoje sistemoje, ir būtent ten sustoja dauguma tokių diegimų.

Trys vieno kelio savininkai

Paimkite filialo tinklą 192.168.50.0/24 ir darbo krūvio potinklį 10.0.10.0/24, o įrenginys yra adresu 10.0.0.4 savo potinklyje. Viena užklausa paliečia tris atskiras konfigūracijas.

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

Daugumoje organizacijų kiekvieną eilutę valdo skirtinga komanda, todėl šis gedimas paprastai atkeliauja kaip trys bilietai, o ne vienas.

Maršrutas, kuris nurodo į įrenginį

Susiekite maršrutų lentelę su darbo krūvio potinkliu ir suteikite filialo prefiksui kito šuolio tipą Virtual appliance su 10.0.0.4 kaip adresu. Naudokite pasiekiamą privatų įrenginio adresą, niekada ne jo viešą VPN įėjimo tašką. Kitas šuolis turi būti adresas, kurį darbo krūvio potinklis jau gali pasiekti. Palikite likusį darbo krūvio maršrutizavimą ramybėje, nebent sąmoningai nusprendėte pakeisti numatytąjį maršrutą.

Laikykite įrenginį savo potinklyje ir įsitikinkite, kad maršrutas, siunčiantis filialo srautą į įrenginį, neužgriebia ir paties įrenginio išeinančio kelio. Tokia kilpa atrodo kaip sveikas tunelis be jokių atsakymų, o tai labai nemalonus dalykas derinti 2 valandą nakties.

Tinklo kortelės vėliavėlė, kurią visi pamiršta

Azure turi IP persiuntimo nuostatą kiekvienai tinklo kortelei, ir ji pagal numatytuosius nustatymus išjungta. Ji egzistuoja todėl, kad persiunčianti kortelė gauna paketus, adresuotus kam nors kitam, o jų tylus atmetimas yra saugus numatytasis nustatymas visiems kitiems.

az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true įjungia ją vienai sąsajai. Microsoft tinklo kortelės persiuntimo gairės reikalauja šios nuostatos kiekvienoje prijungtoje kortelėje, kuri persiunčia srautą, todėl vienos kortelės įrenginiui jos vis tiek reikia toje kortelėje.

Vėliavėlė nėra maršrutas ir nėra ugniasienės taisyklė. Jos įjungimas suteikia leidimą ir nieko daugiau.

Ką svečias daro su iššifruotu paketu

Kai tunelis baigiasi, paties įrenginio stekas priima kitą sprendimą. Linux svečiame IPv4 persiuntimas yra vykdymo laiko nuostata, ir sysctl -w net.ipv4.ip_forward=1 galioja iki kito įkrovimo. Išsaugokite ją faile /etc/sysctl.d/ vietoj to. Gamintojo įrenginys turi savo atitikmenį, o Linux instrukcijos, įklijuotos į gamintojo platformą, paprastai nedaro visiškai nieko.

Svečio ugniasienės politika vėl atskira, kaip ir darbo krūvio tinklo saugos grupė. UDP 500 ir 4500 leidimas į VM viešąjį adresą apsaugo tunelį; tai nieko nesako apie tai, ar iššifruota filialo užklausa gali pasiekti darbo krūvio prievadą.

Sekite vieną užklausą ir jos atsakymą

Pasirinkite vieną leidžiamą srautą ir sekite jį nuo pradžios iki pabaigos. Filialui reikia maršruto 10.0.10.0/24 per vietos ryšį, įrenginiui reikia pristatymo kelio į darbo krūvio potinklį, o darbo krūvio potinkliui reikia grįžtamojo maršruto link filialo.

Anksti nuspręskite, ar projektas išsaugo filialo šaltinio adresą, ar jį verčia. NAT keičia tai, ką mato darbo krūvis, todėl jo prieigos taisyklės turėtų aprašyti modelį, kurį iš tikrųjų pasirinkote, o ne spėjamą šliuzo adresą.

Sėkmingas rankos paspaudimas įrodo vieną tos grandinės grandį. Kelias yra pilnas, kai atsakymas grįžta per tą patį įrenginį ir paties darbo krūvio politika tai leidžia.

Susiję straipsniai