Kāpēc savienojumam no punkta uz vietni vajadzīga maršrutēšanā balstīta Azure VPN vārteja

Uz politiku balstīta vārteja veido IPsec tuneli, ko izvēlas trafika selektori, un tai nav saskarnes, kurai nodot klientu maršrutus. Savienojums no punkta uz vietni ir maršrutēšanas funkcija: vārtejai pieder klientu adrešu baseins, un virtuālajā tīklā tā instalē maršrutus uz šiem klientiem. Tieši šī neatbilstība ir iemesls, kāpēc portāls nerāda nevienu opciju to pievienot. Esošajā vārtejā neko nevar pārslēgt, lai radītu saskarni, tāpēc izmaiņas ir aizstāšana, nevis konfigurācijas rediģēšana.

Secība ir svarīgāka par atsevišķiem soļiem. Ja secība ir nepareiza, pārtraukums starp vietnēm pārsniegs apkopes logu.

Ko uz politiku balstīta vārteja patiešām dara

Uz politiku balstīta vārteja salīdzina paketes ar trafika selektoriem, kas konfigurēti savienojumā, un sūta atbilstības vienā tunelī. Nav tuneļa saskarnes ar adresi, un virtuālajā tīklā nekur neparādās maršruts katram klientam. Maršrutu tabula vienkārši iegūst vietējos prefiksus, kas norāda uz vārteju. Šis modelis ir pietiekams savienojumam starp vietnēm starp divām fiksētām adrešu telpām.

Maršrutēšanā balstīta vārteja darbojas pretēji: tā piedāvā tuneļa saskarni, un maršruti izlemj, kas tajā iekļūst. Savienojums no punkta uz vietni un jebkurš dizains, kura partneru kopa mainās, ir atkarīgi no šīs saskarnes pastāvēšanas.

Kāpēc klientu baseinam vajadzīga šī saskarne

Kad klēpjdators pievienojas, vārteja tam piešķir adresi no punkta uz vietni baseina. Tad virtuālajam tīklam vajadzīgs maršruts, kas norāda, ka šī adrese ir sasniedzama caur vārteju. Bez tuneļa saskarnes nav kam pievienot šo maršrutu.

Baseins nāk no diapazona, ko jūs norādāt, un vārteja no tā piešķir. Ja šis diapazons pārklājas ar vietējo tīklu vai savienoto virtuālo tīklu, konflikts parādās tikai pēc tam, kad klients ir pievienojies, kas ir slikts brīdis tā atklāšanai. Rezervējiet baseinu pirms migrācijas sākuma.

Arī tips nav iestatījums katram savienojumam. Vienai vārtejai ir viens tips, un katrs savienojums, ko tā uztur, uzvedas atbilstoši, tāpēc jauktam dizainam vajadzīga otra vārteja, nevis otrs savienojums.

Tips tiek fiksēts izveides brīdī

Microsoft norāda, ka virtuālā tīkla vārteju pēc izvietošanas nevar mainīt starp uz politiku balstītu un maršrutēšanā balstītu. Nav konvertēšanas komandas un nav pārslēga portālā. Otras vārtejas izveide tajā pašā apakštīklā arī nav apejas ceļš, jo Azure atļauj vienu vārteju katram virtuālajam tīklam. Tāpēc migrācija ir noņemt, pārbūvēt un atkal savienot.

Tas iekļauj arī SKU lēmumu tajā pašā būvē. Vēlāka pāreja uz lielāku SKU ir vēl viena vārtejas aizstāšana ar vēl vienu pārtraukumu.

Viena vārteja, viens GatewaySubnet

Vārteja dzīvo apakštīklā ar nosaukumu GatewaySubnet, un to aizņem tikai viena vārteja. Šī apakštīkla izmēra noteikšana ietilpst sagatavošanā, jo lielākam SKU vajag vairāk adrešu, un apakštīklu pēc tam nevar samazināt. Pierakstiet pašreizējos starpvietņu iestatījumus, koplietoto atslēgu, vietējā tīkla vārteju un efektīvos maršrutus, pirms kaut ko aiztiekat. Pēc tam uzskatiet logu par pārtraukumu, jo tunelis starp vietnēm paliek izslēgts, līdz tiek konfigurēts jaunais savienojums.

Pārbūves secība, kas ierobežo pārtraukumu: izveidojiet maršrutēšanā balstīto vārteju, no jauna izveidojiet savienojumu starp vietnēm uz to pašu vietējā tīkla vārteju, apstipriniet tuneli un vienu pieprasījumu no resursdatora uz resursdatoru, un tikai tad pievienojiet savienojumu no punkta uz vietni un ģenerējiet jaunu klienta pakotni.

Ko aizstāšana neizlabo

Otrs ierobežojums pieder partnerim, nevis Azure. Uz politiku balstīta vietējā ierīce var sasniegt tikai to virtuālo tīklu, kuram tā pievienojas, un nevar tranzītā nokļūt citos vietējos tīklos vai citos virtuālajos tīklos caur to pašu vārteju. Azure puses aizstāšana nemaina to, ko partneris var izvēlēties.

Ja prasība patiešām ir tranzīts starp vietnēm, atbilde ir maršrutēšanā balstīta partnera ierīce vai topoloģija, kurā katrs galamērķis beidzas atsevišķi. Izlemiet to pirms datuma solīšanas, jo vien vārtejas aizstāšana to nenodrošinās.

Darbību un pārbaužu secība

Pārbaudiet katru iespēju atsevišķi. Vispirms tuneļa starp vietnēm stāvokli un vienu pieprasījumu no resursdatora uz resursdatoru, tad savienojumu no punkta uz vietni un vienu privātu resursu, tad jebkuru tranzīta ceļu, ko dizains apgalvo. Zaļš vārtejas statuss pierāda tikai to, ka drošības asociācija ir pacēlusies, un neko vairāk. Turiet pārbaudes šajā secībā, lai kļūme norādītu uz posmu, kas to ieviesa.

Pēc jebkuras topoloģijas izmaiņas ģenerējiet klienta pakotnes no jauna un turiet baseinu tālu no katra vietējā un savienotā diapazona. Ierobežojumi un SKU atšķirības ir apkopotas Azure VPN Gateway iestatījumu atsaucē.