Kial la konekto punkt-al-ejo bezonas itineran Azure VPN-pordegon

Politik-bazita pordego konstruas IPsec-tunelon elektitan de trafik-selektiloj, kaj ĝi ne havas interfacon por transdoni klientajn itinerojn. Punkt-al-eja konekto estas itinada trajto: la pordego posedas klientan adresaron kaj instalas itinerojn al tiuj klientoj en la virtuala reto. Ĝuste tiu malkongruo estas la kialo, ke la portalo ne montras opcion aldoni ĝin. Nenio ĉe la ekzistanta pordego povas esti ŝaltita por krei la interfacon, do la ŝanĝo estas anstataŭigo, ne redakto de la agordo.

La ordo gravas pli ol la unuopaj paŝoj. Se vi eraros pri la sinsekvo, la haltiĝo inter ejoj daŭros preter la bontenada fenestro.

Kion politik-bazita pordego fakte faras

Politik-bazita pordego kongruigas pakaĵojn kun la trafik-selektiloj agorditaj ĉe la konekto kaj sendas la kongruaĵojn en unu tunelon. Ne ekzistas tunela interfaco kun adreso, kaj nenie en la virtuala reto aperas itinero por unuopa kliento. La itinera tabelo simple ricevas la lokajn prefiksojn direktantajn al la pordego. Tiu modelo sufiĉas por konekto inter ejoj inter du fiksaj adresspacoj.

Itiner-bazita pordego funkcias inverse: ĝi prezentas tunelan interfacon, kaj itineroj decidas, kio eniras ĝin. Punkt-al-eja konekto, kaj ĉiu dezajno kies aro da partneroj ŝanĝiĝas, dependas de tio, ke tiu interfaco ekzistas.

Kial la klienta adresaro bezonas tiun interfacon

Kiam tekkomputilo konektiĝas, la pordego asignas al ĝi adreson el la punkt-al-eja adresaro. La virtuala reto tiam bezonas itineron dirantan, ke tiu adreso atingeblas tra la pordego. Sen tunela interfaco mankas io, al kio ligi tiun itineron.

La adresaro venas el gamo, kiun vi mem difinas, kaj la pordego asignas el ĝi. Se tiu gamo interkovriĝas kun la loka reto aŭ kun para virtuala reto, la konflikto aperas nur post kiam kliento konektiĝis, kio estas malbona momento por malkovri ĝin. Rezervu la adresaron antaŭ ol la migrado komenciĝos.

Ankaŭ la tipo ne estas agordo por unuopa konekto. Unu pordego havas unu tipon, kaj ĉiu konekto, kiun ĝi tenas, kondutas laŭe, do miksita dezajno bezonas duan pordegon, ne duan konekton.

La tipo fiksiĝas ĉe kreado

Microsoft asertas, ke virtualreta pordego ne povas esti ŝanĝita inter politik-bazita kaj itiner-bazita post surmeto. Ne ekzistas konverta komando nek ŝaltilo en la portalo. Krei duan pordegon en la sama subreto ankaŭ ne estas solvo, ĉar Azure permesas unu pordegon por virtuala reto. La migrado do estas forigi, rekonstrui, rekonekti.

Tio ankaŭ kuntiras la decidon pri SKU en la saman konstruadon. Transiri al pli granda SKU poste estas alia pordega anstataŭigo kun alia haltiĝo.

Unu pordego, unu GatewaySubnet

La pordego loĝas en subreto nomata GatewaySubnet, kaj nur unu pordego okupas ĝin. Dimensioni tiun subreton apartenas al la preparo, ĉar pli granda SKU bezonas pli da adresoj kaj subreto ne povas esti malgrandigita poste. Notu la nunajn agordojn inter ejoj, la komunan ŝlosilon, la lokretan pordegon kaj la efektivajn itinerojn antaŭ ol tuŝi ion. Poste traktu la fenestron kiel haltiĝon, ĉar la tunelo inter ejoj restas malsupre ĝis la nova konekto estos agordita.

Rekonstrua ordo, kiu tenas la haltiĝon limigita: kreu la itiner-bazitan pordegon, rekreu la konekton inter ejoj al la sama lokreta pordego, konfirmu la tunelon kaj unu peton de gastiganto al gastiganto, kaj nur poste aldonu punkt-al-ejan konekton kaj generu novan klientan pakaĵon.

Kion la anstataŭigo ne riparas

Dua limo apartenas al la partnero, ne al Azure. Politik-bazita loka aparato povas atingi nur la virtualan reton, al kiu ĝi konektiĝas, kaj ne povas transiti al aliaj lokaj retoj aŭ aliaj virtualaj retoj tra la sama pordego. Anstataŭigi la Azure-flankon ne ŝanĝas, kion la partnero povas elekti.

Se la postulo vere estas transito inter ejoj, la respondo estas itiner-bazita partnera aparato aŭ topologio, en kiu ĉiu celloko finiĝas aparte. Klarigu tion antaŭ ol promesi daton, ĉar la pordega anstataŭigo sola ne liveros ĝin.

Ordo de operacioj kaj kontroloj

Kontrolu ĉiun kapablon aparte. Unue la staton de la tunelo inter ejoj kaj unu peton de gastiganto al gastiganto, poste punkt-al-ejan konekton kaj unu privatan rimedon, poste ĉiun transitan vojon, kiun la dezajno asertas. Verda pordega stato pruvas nur, ke la sekureca asocio supreniris, kaj nenion pli. Tenu la kontrolojn en tiu ordo, por ke malsukceso montru la etapon, kiu enkondukis ĝin.

Regeneru klientajn pakaĵojn post ĉiu topologia ŝanĝo kaj tenu la adresaron for de ĉiu loka kaj para gamo. La limoj kaj SKU-diferencoj estas kolektitaj en la referenco pri agordoj de Azure VPN Gateway.