Waarom point-to-site 'n roetegebaseerde Azure VPN-gateway nodig het

'n Beleidsgebaseerde gateway bou 'n IPsec-tonnel wat deur verkeerskiesers gekies word, en dit het geen koppelvlak om kliëntroetes aan te oorhandig nie. Point-to-site is 'n roetefunksie: die gateway besit 'n kliëntadrespoel en installeer roetes na daardie kliënte in die virtuele netwerk. Daardie wanverhouding is die rede waarom die portaal geen opsie wys om dit by te voeg nie. Niks op die bestaande gateway kan omgeskakel word om die koppelvlak te skep nie, so die verandering is 'n vervanging eerder as 'n wysiging van die konfigurasie.

Die volgorde maak meer saak as die individuele stappe. Kry die volgorde verkeerd en die site-to-site-onderbreking loop verby die onderhoudsvenster.

Wat 'n beleidsgebaseerde gateway werklik doen

'n Beleidsgebaseerde gateway pas pakkette teen die verkeerskiesers wat op die verbinding gekonfigureer is, en stuur die ooreenstemmings in een tonnel in. Daar is geen tonnelkoppelvlak met 'n adres nie, en geen roete per kliënt verskyn enigsins in die virtuele netwerk nie. Die roetetabel kry bloot die plaaslike voorvoegsels wat na die gateway wys. Daardie model is voldoende vir 'n site-to-site-verbinding tussen twee vaste adresruimtes.

'n Roetegebaseerde gateway werk omgekeerd: dit bied 'n tonnelkoppelvlak aan, en roetes bepaal wat daarby instap. Point-to-site, en enige ontwerp wie se versameling eweknieë verander, hang daarvan af dat daardie koppelvlak bestaan.

Waarom die kliëntpoel daardie koppelvlak nodig het

Wanneer 'n skootrekenaar koppel, ken die gateway 'n adres uit die point-to-site-poel daaraan toe. Die virtuele netwerk benodig dan 'n roete wat sê dat hierdie adres deur die gateway bereikbaar is. Sonder 'n tonnelkoppelvlak is daar niks om daardie roete aan te heg nie.

Die poel kom uit 'n reeks wat jy benoem, en die gateway ken daaruit toe. As daardie reeks die plaaslike netwerk of 'n eweknie-virtuele netwerk oorvleuel, verskyn die konflik eers nadat 'n kliënt koppel, wat 'n swak oomblik is om dit te ontdek. Bespreek die poel voordat die migrasie begin.

Tipe is ook nie 'n instelling per verbinding nie. Een gateway het een tipe, en elke verbinding wat dit hou, tree dienooreenkomstig op, so 'n gemengde ontwerp benodig 'n tweede gateway eerder as 'n tweede verbinding.

Die tipe is by skepping vas

Microsoft verklaar dat 'n virtuele-netwerkpoort nie ná ontplooiing tussen beleidsgebaseerd en roetegebaseerd verander kan word nie. Daar is geen omskakelingsopdrag en geen portaal-skakelaar nie. Die skep van 'n tweede gateway in dieselfde subnet is ook nie 'n noodoplossing nie, want Azure laat een gateway per virtuele netwerk toe. Die migrasie is dus verwyder, herbou, herkoppel.

Dit vou ook die SKU-besluit in dieselfde bou in. Om later na 'n groter SKU oor te skakel, is nog 'n gateway-vervanging met nog 'n onderbreking.

Een gateway, een GatewaySubnet

Die gateway woon in 'n subnet met die naam GatewaySubnet, en slegs een gateway beslaan dit. Die grootte van daardie subnet hoort by die voorbereiding, want 'n groter SKU benodig meer adresse en 'n subnet kan daarna nie verklein word nie. Teken die huidige site-to-site-instellings, gedeelde sleutel, plaaslike netwerkpoort en effektiewe roetes aan voordat jy enigiets aanraak. Behandel dan die venster as 'n onderbreking, want die site-to-site-tonnel bly af totdat die nuwe verbinding gekonfigureer is.

'n Herbouvolgorde wat die onderbreking beperk: skep die roetegebaseerde gateway, herskep die site-to-site-verbinding na dieselfde plaaslike netwerkpoort, bevestig die tonnel en een gasheer-tot-gasheer-versoek, en voeg eers daarna point-to-site by en genereer 'n nuwe kliëntpakket.

Wat die vervanging nie regmaak nie

'n Tweede beperking hoort by die eweknie eerder as by Azure. 'n Beleidsgebaseerde plaaslike toestel kan slegs die virtuele netwerk bereik waaraan dit koppel, en kan nie deur dieselfde gateway na ander plaaslike netwerke of ander virtuele netwerke deurgang kry nie. Die vervanging van die Azure-kant verander nie wat die eweknie kan kies nie.

As die vereiste werklik deurgang tussen terreine is, is die antwoord 'n roetegebaseerde eweknie-toestel of 'n topologie waar elke bestemming afsonderlik termineer. Besleg dit voordat jy 'n datum belowe, want die gateway-vervanging alleen sal dit nie lewer nie.

Volgorde van bewerkings en kontroles

Verifieer elke vermoë op sy eie. Eers die site-to-site-tonnelstatus en een gasheer-tot-gasheer-versoek, dan 'n point-to-site-verbinding en een private hulpbron, dan enige deurgangspad wat die ontwerp beweer. 'n Groen gateway-status bewys dat die sekuriteitsassosiasie opgekom het en niks meer nie. Hou die kontroles in daardie volgorde sodat 'n fout wys na die stadium wat dit ingebring het.

Genereer kliëntpakkette weer ná enige topologieverandering, en hou die poel weg van elke plaaslike en eweknie-reeks. Die beperkings en SKU-verskille is in die Azure VPN Gateway-instellingsverwysing versamel.