Kvifor point-to-site treng ei rutebasert Azure VPN-gateway
Ei politikkbasert gateway har ingen tunnelgrensesnitt for klientruter. Kva som må byggjast på nytt, i kva rekkjefølgje, og kva grenser som overlever utskiftinga.
Ei politikkbasert gateway byggjer ein IPsec-tunnel som blir vald av trafikkveljarar, og ho har ingen grensesnitt å levere klientruter til. Point-to-site er ein rutefunksjon: gatewaya eig ein klientadressepool og installerer ruter til desse klientane i det virtuelle nettet. Denne uoverensstemminga er grunnen til at portalen ikkje viser noko moglegheit for å leggje han til. Ingenting på den eksisterande gatewaya kan slåast om for å lage grensesnittet, så endringa er ei utskifting og ikkje ei konfigureringsendring.
Rekkjefølgja tyder meir enn dei enkelte trinna. Tek du feil av sekvensen, strekkjer avbrotet mellom nettstadene seg utover vedlikehaldsvindauget.
Kva ei politikkbasert gateway faktisk gjer
Ei politikkbasert gateway matchar pakkar mot trafikkveljarane som er konfigurerte på tilkoplinga, og sender treffa inn i ein tunnel. Det finst ikkje noko tunnelgrensesnitt med adresse, og inga rute per klient viser seg nokon stad i det virtuelle nettet. Rutetabellen får berre dei lokale prefiksa som peikar på gatewaya. Den modellen er tilstrekkeleg for ei tilkopling mellom nettstader mellom to faste adresserom.
Ei rutebasert gateway fungerer motsett: ho presenterer eit tunnelgrensesnitt, og ruter avgjer kva som kjem inn i det. Point-to-site, og eitkvart design der settet av partar endrar seg, er avhengig av at dette grensesnittet finst.
Kvifor klientpoolen treng dette grensesnittet
Når ein berbar PC koplar til, tildeler gatewaya han ein adresse frå point-to-site-poolen. Det virtuelle nettet treng då ei rute som seier at denne adressa er nåbar gjennom gatewaya. Utan eit tunnelgrensesnitt er det ingenting å feste den ruta til.
Poolen kjem frå eit område du angir, og gatewaya tildeler frå det. Viss området overlappar det lokale nettet eller eit peer-tilkopla virtuelt nett, viser konflikten seg først etter at ein klient har kopla til, noko som er eit dårleg tidspunkt å oppdage han på. Reserver poolen før migreringa byrjar.
Typen er heller ikkje ei innstilling per tilkopling. Ei gateway har éin type, og kvar tilkopling ho held oppfører seg deretter, så eit blanda design treng ei anna gateway og ikkje ei anna tilkopling.
Typen er fastlåst ved opprettinga
Microsoft oppgir at ei gateway for virtuelle nett ikkje kan endrast mellom politikkbasert og rutebasert etter distribusjon. Det finst ingen konverteringskommando og ingen brytar i portalen. Å opprette ei anna gateway i same subnett er heller ikkje nokon omveg, fordi Azure tillèt éi gateway per virtuelt nett. Migreringa er derfor fjern, bygg på nytt, kople til på nytt.
Det legg også SKU-avgjerda inn i same bygginga. Å flytte til ein større SKU seinare er ei ny gateway-utskifting med eit nytt avbrot.
Éi gateway, eitt GatewaySubnet
Gatewaya bur i eit subnett som heiter GatewaySubnet, og berre éi gateway opptek det. Dimensjoneringa av dette subnettet høyrer til førebuinga, fordi ein større SKU treng fleire adresser, og eit subnett kan ikkje krympast etterpå. Noter dei noverande innstillingane mellom nettstader, den delte nøkkelen, den lokale nettverksgatewaya og dei effektive rutene før du rører noko. Behandle deretter vindauget som eit avbrot, fordi tunnelen mellom nettstadene blir verande nede til den nye tilkoplinga er konfigurert.
Ei gjenoppbyggingsrekkjefølgje som held avbrotet avgrensa: opprett den rutebaserte gatewaya, gjenopprett tilkoplinga mellom nettstadene til den same lokale nettverksgatewaya, stadfest tunnelen og éin førespurnad frå vert til vert, og legg først deretter til point-to-site og generer ein ny klientpakke.
Kva utskiftinga ikkje fiksar
Ei andre grense høyrer til parten og ikkje Azure. Ei politikkbasert lokal eining kan berre nå det virtuelle nettet ho blir kopla til, og kan ikkje gå via den same gatewaya til andre lokale nett eller andre virtuelle nett. Å skifte ut Azure-sida endrar ikkje kva parten kan velje.
Viss kravet verkeleg er gjennomgang mellom nettstader, er svaret ei rutebasert partseining eller ein topologi der kvar destinasjon blir avslutta separat. Avklar det før du lovar ein dato, fordi gateway-utskiftinga åleine leverer det ikkje.
Rekkjefølgje for operasjonar og kontrollar
Stadfest kvar eigenskap for seg. Først tunnelstatus mellom nettstadene og éin førespurnad frå vert til vert, deretter ei point-to-site-tilkopling og éin privat ressurs, deretter kvar gjennomgangsveg designet hevdar. Ein grøn gateway-status beviser berre at sikkerheitstilknytinga kom opp, og ikkje noko meir. Hald kontrollane i den rekkjefølgja slik at ein feil peikar på trinnet som innførte han.
Generer klientpakkar på nytt etter kvar topologiendring, og hald poolen unna kvart lokalt og peer-tilkopla område. Grensene og SKU-skilnadene er samla i referansen for Azure VPN Gateway-innstillingar.