Wêrom point-to-site in rûte-basearre Azure VPN-gateway nedich hat

In beliedsbasearre gateway bout in IPsec-tunnel dy’t troch ferkearsselekteurs keazen wurdt, en hat gjin interface om klientrûtes oan te jaan. Point-to-site is in rûtefunksje: de gateway besit in klientadrespul en ynstallearret rûtes nei dy klanten yn it firtuele netwurk. Dy diskrepânsje is de reden dat it portaal gjin opsje toant om it ta te foegjen. Neat op de besteande gateway kin omklapt wurde om de interface te meitsjen, dus de feroaring is in ferfanging en gjin bewurking fan ’e konfiguraasje.

De oarder is wichtiger as de yndividuele stappen. Krigest de folchoarder ferkeard, dan rint de ûnderbrekking tusken sites foarby it ûnderhâldsfinster.

Wat in beliedsbasearre gateway eins docht

In beliedsbasearre gateway ferliket pakketten mei de ferkearsselekteurs dy’t op ’e ferbining konfigurearre binne en stjoert de oerienkomsten yn ien tunnel. Der is gjin tunnelinterface mei in adres, en nearne yn it firtuele netwurk ferskynt in rûte per klant. De rûtetabel krijt gewoan de lokale prefiksen dy’t nei de gateway wize. Dat model is genôch foar in ferbining tusken sites tusken twa fêste adresromten.

In rûte-basearre gateway wurket oarsom: hy presintearret in tunnelinterface, en rûtes beslisse wat der yn komt. Point-to-site, en elk ûntwerp wêrfan de set fan pearen feroaret, hingje ôf fan it bestean fan dy interface.

Wêrom it klientpul dy interface nedich hat

As in laptop ferbynt, jout de gateway him in adres út it point-to-site-pul. It firtuele netwurk hat dan in rûte nedich dy’t seit dat dit adres fia de gateway berikber is. Sûnder tunnelinterface is der neat om dy rûte oan te heakjen.

It pul komt út in berik dat jo beneame, en de gateway dielt dêrút. As dat berik oerlapet mei it lokale netwurk of in keppele firtueel netwurk, docht de konflikt him pas foar nei’t in klant ferbûn is, wat in min momint is om it te ûntdekken. Reservearje it pul foardat de migraasje begjint.

It type is ek gjin ynstelling per ferbining. Ien gateway hat ien type, en elke ferbining dy’t er hat draacht him dêrneffens, dus in mingd ûntwerp hat in twadde gateway nedich yn plak fan in twadde ferbining.

It type is fêst by it oanmeitsjen

Microsoft stelt dat in firtueel netwurk-gateway nei de útrôl net feroare wurde kin tusken beliedsbasearre en rûte-basearre. Der is gjin konverzje-opdracht en gjin skeakel yn it portaal. In twadde gateway yn itselde subnet oanmeitsje is ek gjin omwei, om’t Azure ien gateway per firtueel netwurk tastean. De migraasje is dus fuorthelje, wer opbouwe, wer ferbine.

Dat bringt ek de SKU-beslissing yn deselde bou. Letter nei in gruttere SKU oergean is wer in gateway-ferfanging mei wer in ûnderbrekking.

Ien gateway, ien GatewaySubnet

De gateway wennet yn in subnet mei de namme GatewaySubnet, en mar ien gateway beset it. It bemjitten fan dat subnet heart by de tarieding, om’t in gruttere SKU mear adressen nedich hat en in subnet letter net lytser makke wurde kin. Skriuw de hjoeddeiske ynstellingen tusken sites, de dielde kaai, de lokale netwurk-gateway en de effektive rûtes op foardat jo eat oanreitsje. Behannelje it finster dan as ûnderbrekking, om’t de tunnel tusken sites del bliuwt oant de nije ferbining konfigurearre is.

In weropbou-oarder dy’t de ûnderbrekking beheind hâldt: meitsje de rûte-basearre gateway oan, meitsje de ferbining tusken sites wer oan nei deselde lokale netwurk-gateway, befêstigje de tunnel en ien host-nei-host-fersyk, en foegje dan pas point-to-site ta en generearje in nij klientpakket.

Wat de ferfanging net oplost

In twadde beheining heart by de peer en net by Azure. In beliedsbasearre lokaal apparaat kin allinnich it firtuele netwurk berikke dêr’t it oan ferbûn is, en kin net troch deselde gateway nei oare lokale netwurken of oare firtuele netwurken trochgean. It ferfangen fan ’e Azure-kant feroaret net wat de peer kieze kin.

As de eask echt trochgong tusken sites is, is it antwurd in rûte-basearre peer-apparaat of in topology wêryn elke bestemming apart einiget. Beslis dat foardat jo in datum tasizze, om’t de gateway-ferfanging allinnich it net leveret.

Oarder fan aksjes en kontrôles

Kontrolearje elke mooglikheid apart. Earst de status fan ’e tunnel tusken sites en ien host-nei-host-fersyk, dan in point-to-site-ferbining en ien priveebarne, dan elk trochgongspaad dat it ûntwerp beweart. In griene gateway-status bewiist allinnich dat de befeiligingsassosjaasje omheech kaam, en net mear. Hâld de kontrôles yn dy oarder sadat in flater wiist nei de stap dy’t it yntrodusearre hat.

Generearje klientpakketten op ’e nij nei elke topologyferoaring en hâld it pul frij fan elk lokaal en keppele berik. De beheiningen en SKU-ferskillen binne sammele yn ’e referinsje foar Azure VPN Gateway-ynstellingen.