Miks punktist kohta ühendus vajab marsruudipõhist Azure VPN-lüüsi
Põhimõttel põhineval lüüsil puudub kliendimarsruutide jaoks tunneliliides. Mis tuleb uuesti üles ehitada, mis järjekorras ja millised piirangud asendamise üle elavad.
Põhimõttel põhinev lüüs ehitab liiklusselektoritega valitava IPsec-tunneli ja sellel puudub liides, millele kliendimarsruute üle anda. Punktist kohta ühendus on marsruutimisfunktsioon: lüüsile kuulub kliendiadresside kogum ja see paigaldab virtuaalvõrku marsruudid nende klientideni. Just see lahknevus on põhjus, miks portaal ei näita selle lisamise valikut. Olemasoleval lüüsil ei saa midagi ümber lülitada, et liidest tekitada, seega on muudatus asendamine, mitte konfiguratsiooni muutmine.
Järjekord on tähtsam kui üksikud sammud. Kui järjestus läheb sassi, venib saidi ja saidi vaheline katkestus üle hooldusakna.
Mida põhimõttel põhinev lüüs tegelikult teeb
Põhimõttel põhinev lüüs võrdleb pakette ühendusel konfigureeritud liiklusselektoritega ja saadab vasted ühte tunnelisse. Tunneli liidest aadressiga ei ole ja virtuaalvõrgus ei ilmu kuskil ühegi kliendi marsruuti. Marsruutimistabel saab lihtsalt lüüsile osutavad kohalikud prefiksid. See mudel on piisav kahe fikseeritud aadressiruumi vaheliseks saidi ja saidi vaheliseks ühenduseks.
Marsruudipõhine lüüs töötab vastupidi: see esitab tunneliliidese ja marsruudid otsustavad, mis sinna siseneb. Punktist kohta ühendus ja iga lahendus, mille partnerite kogum muutub, sõltuvad selle liidese olemasolust.
Miks kliendikogum seda liidest vajab
Kui sülearvuti ühendub, määrab lüüs sellele aadressi punktist kohta kogumist. Virtuaalvõrk vajab siis marsruuti, mis ütleb, et see aadress on lüüsi kaudu kättesaadav. Ilma tunneliliideseta pole seda marsruuti millegi külge kinnitada.
Kogum pärineb vahemikust, mille te ise määrate, ja lüüs jaotab sealt. Kui see vahemik kattub kohaliku võrgu või partneriks oleva virtuaalvõrguga, ilmneb konflikt alles pärast kliendi ühendumist, mis on selle avastamiseks halb hetk. Broneerige kogum enne migratsiooni algust.
Ka tüüp ei ole ühendusepõhine säte. Ühel lüüsil on üks tüüp ja iga selle hoitav ühendus käitub vastavalt, seega vajab segalahendus teist lüüsi, mitte teist ühendust.
Tüüp on loomisel fikseeritud
Microsoft märgib, et virtuaalvõrgu lüüsi ei saa pärast juurutamist põhimõttel põhineva ja marsruudipõhise vahel muuta. Konversioonikäsku ega portaali lülitit ei ole. Teise lüüsi loomine samasse alamvõrku ei ole samuti lahendus, sest Azure lubab ühe lüüsi virtuaalvõrgu kohta. Migratsioon on seega eemaldamine, uuesti ülesehitamine ja uuesti ühendamine.
See toob ka SKU-otsuse samasse ehitusse. Hiljem suuremale SKU-le üleminek on veel üks lüüsi asendamine veel ühe katkestusega.
Üks lüüs, üks GatewaySubnet
Lüüs elab alamvõrgus nimega GatewaySubnet ja seda hõivab ainult üks lüüs. Selle alamvõrgu mõõtmete määramine kuulub ettevalmistuse juurde, sest suurem SKU vajab rohkem aadresse ja alamvõrku ei saa hiljem väiksemaks teha. Kirjutage üles praegused saidi ja saidi vahelised sätted, jagatud võti, kohaliku võrgu lüüs ja kehtivad marsruudid, enne kui millegi külge puutute. Seejärel käsitlege akent katkestusena, sest saidi ja saidi vaheline tunnel jääb maas, kuni uus ühendus on konfigureeritud.
Ülesehitamise järjekord, mis hoiab katkestuse piiratud: looge marsruudipõhine lüüs, looge saidi ja saidi vaheline ühendus uuesti sama kohaliku võrgu lüüsiga, kinnitage tunnel ja üks host-host-päring ning alles siis lisage punktist kohta ühendus ja genereerige uus kliendipakett.
Mida asendamine ei paranda
Teine piirang kuulub partnerile, mitte Azureile. Põhimõttel põhinev kohalik seade jõuab ainult virtuaalvõrku, millega see ühendub, ega saa sama lüüsi kaudu transiidiga teistesse kohalikesse võrkudesse või teistesse virtuaalvõrkudesse. Azurei poole asendamine ei muuda seda, mida partner saab valida.
Kui nõue on tõesti transiit kohtade vahel, on vastuseks marsruudipõhine partneri seade või topoloogia, kus iga sihtkoht lõpeb eraldi. Lahendage see enne kuupäeva lubamist, sest ainult lüüsi asendamine seda ei anna.
Toimingute ja kontrollide järjekord
Kontrollige iga võimekust eraldi. Kõigepealt saidi ja saidi vahelise tunneli olek ja üks host-host-päring, seejärel punktist kohta ühendus ja üks privaatne ressurss, seejärel mis tahes transiiditee, mida lahendus väidab. Roheline lüüsi olek tõestab ainult seda, et turbeseos tõusis, ja mitte enamat. Hoidke kontrollid selles järjekorras, et tõrge osutaks etapile, mis selle sisse tõi.
Genereerige kliendipaketid uuesti pärast igasugust topoloogiamuudatust ja hoidke kogum eemal igast kohalikust ja partneriks olevast vahemikust. Piirangud ja SKU-erinevused on kogutud Azure VPN Gateway seadete viitesse.