Miksi point-to-site tarvitsee reitityspohjaisen Azure VPN -yhdyskäytävän

Käytäntöpohjainen yhdyskäytävä rakentaa liikenteen valitsimien valitseman IPsec-tunnelin, eikä sillä ole liitäntää, jolle asiakasreitit voisi luovuttaa. Point-to-site on reititysominaisuus: yhdyskäytävä omistaa asiakasosoitepoolin ja asentaa reitit näihin asiakkaisiin virtuaaliverkossa. Juuri tämä ristiriita on syy siihen, ettei portaalissa näy vaihtoehtoa sen lisäämiseksi. Nykyisessä yhdyskäytävässä ei voi kytkeä mitään, mikä loisi liitännän, joten muutos on korvaus eikä kokoonpanon muokkaus.

Järjestys on tärkeämpi kuin yksittäiset vaiheet. Jos järjestys menee pieleen, sivustojen välinen katkos venyy huoltokatkon yli.

Mitä käytäntöpohjainen yhdyskäytävä todella tekee

Käytäntöpohjainen yhdyskäytävä täsmäyttää paketit yhteydelle määritettyihin liikenteen valitsimiin ja lähettää osumat yhteen tunneliin. Ei ole osoitteellista tunneliliitäntää, eikä virtuaaliverkossa näy missään reittiä asiakaskohtaisesti. Reititystaulu saa yksinkertaisesti paikalliset etuliitteet, jotka osoittavat yhdyskäytävään. Tämä malli riittää sivustojen väliseen yhteyteen kahden kiinteän osoiteavaruuden välillä.

Reitityspohjainen yhdyskäytävä toimii päinvastoin: se esittää tunneliliitännän, ja reitit päättävät, mitä siihen tulee. Point-to-site ja mikä tahansa suunnittelu, jonka vertaisten joukko muuttuu, riippuvat kyseisen liitännän olemassaolosta.

Miksi asiakaspooli tarvitsee tuon liitännän

Kun kannettava tietokone yhdistää, yhdyskäytävä antaa sille osoitteen point-to-site-poolista. Virtuaaliverkko tarvitsee silloin reitin, joka kertoo, että tämä osoite on tavoitettavissa yhdyskäytävän kautta. Ilman tunneliliitäntää ei ole mitään, mihin reitin voisi liittää.

Pooli tulee alueesta, jonka te määritätte, ja yhdyskäytävä jakaa siitä. Jos alue menee päällekkäin paikallisen verkon tai vertaisverkon kanssa, ristiriita tulee esiin vasta asiakkaan yhdistämisen jälkeen, mikä on huono hetki havaita sitä. Varaa pooli ennen migraation alkua.

Tyyppi ei ole yhteyksittäinen asetus. Yhdellä yhdyskäytävällä on yksi tyyppi, ja jokainen sen pitämä yhteys toimii sen mukaisesti, joten yhdistetty suunnittelu tarvitsee toisen yhdyskäytävän eikä toista yhteyttä.

Tyyppi on kiinnitetty luontivaiheessa

Microsoft ilmoittaa, että virtuaaliverkon yhdyskäytävää ei voi vaihtaa käytäntöpohjaisesta reitityspohjaiseksi tai päinvastoin käyttöönoton jälkeen. Muunnoskomentoa ei ole eikä portaalissa ole kytkintä. Toisen yhdyskäytävän luominen samaan aliverkkoon ei ole myöskään kiertotie, koska Azure sallii yhden yhdyskäytävän virtuaaliverkkoa kohden. Migraatio on siis poista, rakenna uudelleen, yhdistä uudelleen.

Tämä liittää myös SKU-päätöksen samaan rakennukseen. Siirtyminen suurempaan SKU:hun myöhemmin on uusi yhdyskäytävän korvaus ja uusi katkos.

Yksi yhdyskäytävä, yksi GatewaySubnet

Yhdyskäytävä sijaitsee GatewaySubnet-nimisessä aliverkossa, ja vain yksi yhdyskäytävä vie sitä. Aliverkon mitoitus kuuluu valmisteluun, koska suurempi SKU tarvitsee enemmän osoitteita eikä aliverkkoa voi pienentää jälkeenpäin. Kirjaa nykyiset sivustojen väliset asetukset, jaettu avain, paikallisen verkon yhdyskäytävä ja tehokkaat reitit ennen kuin kosket mihinkään. Käsittele ikkunaa sitten katkoksena, koska sivustojen välinen tunneli pysyy alas, kunnes uusi yhteys on määritetty.

Uudelleenrakennusjärjestys, joka pitää katkoksen rajattuna: luo reitityspohjainen yhdyskäytävä, luo sivustojen välinen yhteys uudelleen samaan paikallisen verkon yhdyskäytävään, vahvista tunneli ja yksi isäntä-isäntä-pyyntö, ja vasta sitten lisää point-to-site ja luo uusi asiakaspaketti.

Mitä korvaus ei korjaa

Toinen rajoitus kuuluu vertaiselle eikä Azurelle. Käytäntöpohjainen paikallinen laite tavoittaa vain sen virtuaaliverkon, johon se yhdistää, eikä voi välittää liikennettä muihin paikallisiin verkkoihin tai muihin virtuaaliverkkoihin saman yhdyskäytävän kautta. Azure-puolen korvaaminen ei muuta sitä, mitä vertainen voi valita.

Jos vaatimus on todella siirtymä sivustojen välillä, vastaus on reitityspohjainen vertaislaite tai topologia, jossa jokainen kohde päättyy erikseen. Ratkaise se ennen päivämäärän lupaamista, koska pelkkä yhdyskäytävän korvaus ei sitä toimita.

Toimintojen ja tarkistusten järjestys

Tarkista jokainen kyvykkyys erikseen. Ensin sivustojen välisen tunnelin tila ja yksi isäntä-isäntä-pyyntö, sitten point-to-site-yhteys ja yksi yksityinen resurssi, sitten mikä tahansa siirtymäpolku, jonka suunnittelu väittää. Vihreä yhdyskäytävän tila todistaa vain, että suojausyhdistys nousi, eikä mitään muuta. Pidä tarkistukset tässä järjestyksessä, jotta vika osoittaa vaiheeseen, joka sen toi.

Luo asiakaspaketit uudelleen jokaisen topologiamuutoksen jälkeen ja pidä pooli erillään jokaisesta paikallisesta ja vertaisalueesta. Rajoitukset ja SKU-erot on koottu Azure VPN Gateway -asetusten viitteeseen.