Kodėl taško į svetainę ryšiui reikia maršrutais pagrįsto Azure VPN šliuzo

Politika pagrįstas šliuzas sukuria IPsec tunelį, kurį parenka srauto selektoriai, ir neturi sąsajos, kuriai būtų galima perduoti klientų maršrutus. Taško į svetainę ryšys yra maršrutizavimo funkcija: šliuzas turi klientų adresų telkinį ir virtualiame tinkle įdiegia maršrutus tiems klientams. Būtent šis neatitikimas yra priežastis, kodėl portale nerodoma jokia parinktis jį pridėti. Esamame šliuze nieko negalima perjungti, kad susidarytų sąsaja, todėl tai yra šliuzo pakeitimas, o ne konfigūracijos redagavimas.

Tvarka svarbesnė už atskirus veiksmus. Jei seka bus neteisinga, pertrauka tarp svetainių viršys techninės priežiūros langą.

Ką iš tikrųjų daro politika pagrįstas šliuzas

Politika pagrįstas šliuzas lygina paketus su srauto selektoriais, sukonfigūruotais ryšyje, ir atitikmenis siunčia į vieną tunelį. Nėra tunelio sąsajos su adresu, ir virtualiame tinkle niekur neatsiranda maršrutas atskiram klientui. Maršrutų lentelė tiesiog gauna vietinius prefiksus, nukreiptus į šliuzą. Šio modelio pakanka ryšiui tarp svetainių tarp dviejų fiksuotų adresų erdvių.

Maršrutais pagrįstas šliuzas veikia priešingai: jis pateikia tunelio sąsają, o maršrutai nusprendžia, kas į ją patenka. Taško į svetainę ryšys ir bet kuri konstrukcija, kurios partnerių rinkinys kinta, priklauso nuo šios sąsajos egzistavimo.

Kodėl klientų telkiniui reikia šios sąsajos

Kai nešiojamasis kompiuteris prisijungia, šliuzas priskiria jam adresą iš taško į svetainę telkinio. Tada virtualiam tinklui reikia maršruto, sakant, kad šis adresas pasiekiamas per šliuzą. Be tunelio sąsajos nėra prie ko pritvirtinti to maršruto.

Telkinys imamas iš jūsų nurodyto diapazono, ir šliuzas iš jo skirsto. Jei tas diapazonas persidengia su vietiniu tinklu ar suporuotu virtualiu tinklu, konfliktas paaiškėja tik po to, kai prisijungia klientas, o tai prastas metas jį aptikti. Rezervuokite telkinį prieš prasidedant migracijai.

Tipas taip pat nėra kiekvieno ryšio nustatymas. Vienas šliuzas turi vieną tipą, ir kiekvienas jo palaikomas ryšys elgiasi atitinkamai, todėl mišriai konstrukcijai reikia antro šliuzo, o ne antro ryšio.

Tipas nustatomas kuriant

Microsoft teigia, kad virtualaus tinklo šliuzo negalima pakeisti tarp politika pagrįsto ir maršrutais pagrįsto po diegimo. Nėra konvertavimo komandos ir nėra jungiklio portale. Antro šliuzo kūrimas tame pačiame potinkyje taip pat nėra apeities būdas, nes Azure leidžia vieną šliuzą vienam virtualiam tinklui. Todėl migracija yra pašalinti, perstatyti ir vėl prisijungti.

Tai taip pat įtraukia SKU sprendimą į tą pačią statybą. Vėliau perėjimas prie didesnio SKU yra dar vienas šliuzo pakeitimas su dar viena pertrauka.

Vienas šliuzas, vienas GatewaySubnet

Šliuzas gyvena potinkyje, pavadintame GatewaySubnet, ir jį užima tik vienas šliuzas. To potinkio dydžio nustatymas priklauso pasiruošimui, nes didesniam SKU reikia daugiau adresų, o potinkio vėliau sumažinti negalima. Užsirašykite dabartinius ryšio tarp svetainių nustatymus, bendrą raktą, vietinio tinklo šliuzą ir veiksmingus maršrutus prieš ką nors liesdami. Tada traktuokite langą kaip pertrauką, nes tunelis tarp svetainių lieka išjungtas, kol nesukonfigūruotas naujas ryšys.

Perstatymo tvarka, kuri apriboja pertrauką: sukurkite maršrutais pagrįstą šliuzą, iš naujo sukurkite ryšį tarp svetainių į tą patį vietinio tinklo šliuzą, patvirtinkite tunelį ir vieną užklausą iš mazgo į mazgą, ir tik tada pridėkite taško į svetainę ryšį bei sugeneruokite naują kliento paketą.

Ko pakeitimas nepataiso

Antrasis apribojimas priklauso partneriui, o ne Azure. Politika pagrįstas vietinis įrenginys gali pasiekti tik tą virtualų tinklą, prie kurio jungiasi, ir negali tranzitu patekti į kitus vietinius tinklus ar kitus virtualius tinklus per tą patį šliuzą. Azure pusės pakeitimas nekeičia to, ką partneris gali pasirinkti.

Jei reikalavimas iš tiesų yra tranzitas tarp svetainių, atsakymas yra maršrutais pagrįstas partnerio įrenginys arba topologija, kurioje kiekviena paskirties vieta baigiasi atskirai. Tai išspręskite prieš žadėdami datą, nes vien šliuzo pakeitimas to neužtikrins.

Operacijų ir patikrų tvarka

Tikrinkite kiekvieną galimybę atskirai. Pirmiausia tunelio tarp svetainių būseną ir vieną užklausą iš mazgo į mazgą, tada taško į svetainę ryšį ir vieną privatų išteklį, tada bet kurį tranzito kelią, kurį deklaruoja konstrukcija. Žalia šliuzo būsena įrodo tik tai, kad saugos asociacija pakilo, ir nieko daugiau. Laikykite patikras ta tvarka, kad gedimas rodytų į etapą, kuris jį įvedė.

Po bet kurio topologijos pakeitimo iš naujo sugeneruokite kliento paketus ir laikykite telkinį atokiau nuo kiekvieno vietinio ir suporuoto diapazono. Apribojimai ir SKU skirtumai surinkti Azure VPN Gateway nustatymų nuorodoje.