Zašto veza od točke do lokacije zahtijeva Azure VPN pristupnik zasnovan na rutiranju

Pristupnik zasnovan na pravilima gradi IPsec tunel koji odabiru selektori prometa i nema sučelje kojemu bi predao rute klijenata. Veza od točke do lokacije značajka je rutiranja: pristupnik posjeduje bazen adresa klijenata i ugrađuje rute prema tim klijentima u virtualnu mrežu. Upravo zbog te neusklađenosti portal ne prikazuje mogućnost da se ona doda. Ništa na postojećem pristupniku ne može se prebaciti tako da stvori sučelje, pa je promjena zamjena, a ne uređivanje konfiguracije.

Redoslijed je važniji od pojedinačnih koraka. Pogriješite li slijed, prekid veze između lokacija protegnut će se preko roka održavanja.

Što pristupnik zasnovan na pravilima zapravo radi

Pristupnik zasnovan na pravilima uparuje pakete sa selektorima prometa konfiguriranima na vezi i šalje podudaranja u jedan tunel. Nema tunelskog sučelja s adresom i nigdje se u virtualnoj mreži ne pojavljuje ruta za pojedinog klijenta. Tablica ruta jednostavno dobiva lokalne prefikse koji pokazuju na pristupnik. Taj je model dovoljan za vezu između lokacija s dva fiksna adresna prostora.

Pristupnik zasnovan na rutiranju radi obrnuto: predstavlja tunelsko sučelje, a rute odlučuju što u njega ulazi. Veza od točke do lokacije i svaki dizajn kojemu se skup partnera mijenja ovise o postojanju tog sučelja.

Zašto bazenu klijenata treba to sučelje

Kada se prijenosno računalo poveže, pristupnik mu dodjeljuje adresu iz bazena od točke do lokacije. Virtualna mreža tada treba rutu koja kaže da je ta adresa dostupna kroz pristupnik. Bez tunelskog sučelja nema čemu pričvrstiti tu rutu.

Bazen dolazi iz raspona koji vi odredite, a pristupnik iz njega dodjeljuje. Ako se taj raspon preklapa s lokalnom mrežom ili povezanom virtualnom mrežom, sukob se pokaže tek nakon što se klijent poveže, a to je loš trenutak za otkrivanje. Rezervirajte bazen prije početka migracije.

Ni tip nije postavka za pojedinu vezu. Jedan pristupnik ima jedan tip i svaka veza koju drži ponaša se u skladu s tim, pa mješoviti dizajn treba drugi pristupnik, a ne drugu vezu.

Tip je fiksiran pri stvaranju

Microsoft navodi da se pristupnik virtualne mreže ne može nakon implementacije promijeniti između zasnovanog na pravilima i zasnovanog na rutiranju. Nema naredbe za pretvorbu ni prekidača na portalu. Stvaranje drugog pristupnika u istoj podmreži također nije zaobilazno rješenje jer Azure dopušta jedan pristupnik po virtualnoj mreži. Migracija je zato uklanjanje, ponovna izgradnja i ponovno povezivanje.

To i odluku o SKU-u uvlači u istu izgradnju. Prelazak na veći SKU kasnije je još jedna zamjena pristupnika s još jednim prekidom.

Jedan pristupnik, jedna GatewaySubnet

Pristupnik živi u podmreži nazvanoj GatewaySubnet i samo ga jedan pristupnik zauzima. Određivanje veličine te podmreže dio je pripreme jer veći SKU treba više adresa, a podmreža se poslije ne može smanjiti. Zapišite trenutačne postavke veze između lokacija, zajednički ključ, pristupnik lokalne mreže i efektivne rute prije nego što bilo što dotaknete. Zatim prozor tretirajte kao prekid jer tunel između lokacija ostaje isključen dok se nova veza ne konfigurira.

Redoslijed ponovne izgradnje koji drži prekid ograničenim: stvorite pristupnik zasnovan na rutiranju, ponovno uspostavite vezu između lokacija prema istom pristupniku lokalne mreže, potvrdite tunel i jedan zahtjev od hosta do hosta, pa tek onda dodajte vezu od točke do lokacije i generirajte novi paket za klijente.

Što zamjena ne ispravlja

Drugo ograničenje pripada partneru, a ne Azureu. Lokalni uređaj zasnovan na pravilima može dosegnuti samo virtualnu mrežu na koju se povezuje i ne može tranzitirati prema drugim lokalnim mrežama ni drugim virtualnim mrežama kroz isti pristupnik. Zamjena Azureove strane ne mijenja ono što partner može odabrati.

Ako zahtjev doista jest tranzit između lokacija, odgovor je partnerski uređaj zasnovan na rutiranju ili topologija u kojoj svako odredište završava zasebno. Riješite to prije nego što obećate datum jer sama zamjena pristupnika to neće isporučiti.

Redoslijed radnji i provjera

Provjerite svaku mogućnost zasebno. Najprije stanje tunela između lokacija i jedan zahtjev od hosta do hosta, zatim vezu od točke do lokacije i jedan privatni resurs, zatim svaku tranzitnu putanju koju dizajn tvrdi. Zeleno stanje pristupnika dokazuje samo da je sigurnosna asocijacija uspostavljena i ništa više. Držite provjere tim redoslijedom kako bi kvar pokazao na fazu koja ga je uvela.

Ponovno generirajte pakete za klijente nakon svake promjene topologije i držite bazen podalje od svakog lokalnog i povezanog raspona. Ograničenja i razlike među SKU-ovima skupljeni su u referenci postavki Azure VPN Gateway.