Maršrutēt datplūsmu starp divām filiālēm caur Azure VPN vārteju
Divi Site-to-Site savienojumi vienā Azure VPN vārtejā var laist cauri filiāļu datplūsmu, bet tikai tad, kad abi gali apgūst prefiksu un pastāv LAN atgriešanās ceļš.
Divas filiāles var apmainīties ar datplūsmu caur Azure VPN vārteju bez tieša tuneļa starp tām. Katra filiāle atver Site-to-Site savienojumu ar to pašu vārteju, un vārteja pārsūta apgūtos prefiksus starp abiem savienojumiem. To darbina nevis otrais tunelis, bet maršrutu apmaiņa: filiālei A ir jāapgūst filiāles B prefikss, bet B — A prefikss. Veiciet zemāk minētās pārbaudes secīgi un apstājieties pie pirmās, kas neizdodas, jo katrs nākamais solis ir atkarīgs no tās.
Priekšnosacījumi, pirms kaut ko konfigurējat
Četri nosacījumi nosaka, vai šis risinājums vispār var darboties. Vārtejai jābūt balstītai uz maršrutiem un jābūt uz SKU, kas atbalsta BGP, abiem savienojumiem jābūt ieslēgtam BGP, filiāļu adrešu telpām nevajadzētu pārklāties, un nevienai pusei nevajadzētu paļauties uz NAT, lai slēptu savu īsto prefiksu.
Plānojiet ASN apzināti. Azure dokumentētā noklusējuma vērtība ir 65515, un katram filiāles maršrutētājam nepieciešams savs privātais ASN, kas nesaduras ar vārteju vai otru filiāli. Noklusējuma atkārtota izmantošana bez esošas vārtejas konfigurācijas pārbaudes ir veids, kā vēlāk AS ceļš tiek noraidīts.
Pārliecinieties arī, ka negaidāt VNet peering uzvedību. Vārteja apmainās ar maršrutiem starp diviem savienojumiem, kurus konfigurējāt; tā nepadara patvaļīgus peering savienojumus transitīvus. Ja trešajam tīklam jāsasniedz abas filiāles, tam nepieciešams savs savienojums vai savs maršruta ceļš, nevis pieņēmums, ka vārteja sadalīs datplūsmu. Pierakstiet šo robežu pirms pirmā izmaiņu loga, jo tas ir dizaina lēmums, pie kura cilvēki atgriežas, kad vēlāk tiek pievienota jauna vieta.
Konfigurējiet šādā secībā
Katram solim ir novērojams rezultāts, tāpēc nevirzieties tālāk, kamēr tas neparādās.
- Ieslēdziet BGP virtuālā tīkla vārtejā un pierakstiet tās ASN un peer adresi.
- Izveidojiet lokālu tīkla vārteju katrai filiālei ar tās īsto adrešu telpu, tās ASN un tās BGP peer adresi.
- Izveidojiet katru Site-to-Site savienojumu un ieslēdziet BGP pašā savienojumā.
- Konfigurējiet filiāles maršrutētāju, lai tas veidotu peer savienojumu ar Azure piešķirto vārtejas adresi, nevis ar vārtejas publisko IKE galapunktu, pamatojoties uz pieņēmumu.
Ceturtais solis ir vieta, kur iestrēgst lielākā daļa mēģinājumu. Azure ziņotā BGP peer adrese ir tā, kas filiāles maršrutētājam jāizmanto kā kaimiņam, un tā ne vienmēr ir adrese, ko cilvēki sagaida no tuneļa shēmas.
Reklamējiet pašu filiāles prefiksu, piemēram, 10.10.0.0/16 no A un 10.20.0.0/16 no B. Nereklamējiet noklusējuma maršrutu vai plašu agregātu, lai segtu trūkstošu konkrētu tīklu; robs vēlāk atgriežas kā klusa melnā bedre.
Pārbaudiet maršrutu apmaiņu abos galos
Savienojuma statuss nav pārbaude. IPsec var būt aktīvs abos savienojumos, kamēr starp tiem nešķērso neviens prefikss. Izlasiet vārtejas BGP peer savienojumus un tās apgūtos maršrutus, pēc tam apstipriniet, ka maršruts uz otru filiāli parādās kā lietojams ceļš.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
Prefikss, kas atrodas BGP tabulā, joprojām var zaudēt pārsūtīšanas lēmumu statiskam maršrutam vai konkrētākam prefiksam. Pārbaudiet izvēlēto maršrutu, ne tikai saņemto.
Sekojiet atgriešanās ceļam LAN pusē
Šī ir daļa, kas Azure izskatās pareizi un uz vietas neizdodas. Filiāles A resursdators sūta savu paketi A VPN maršrutētājam tikai tad, ja šis maršrutētājs ir tā noklusējuma vārteja, vai ja resursdatoram vai tā vārtejai ir maršruts uz B prefiksu. Tas pats jāievēro arī pretējā virzienā.
Ja atsevišķs pamata komutators ir LAN noklusējuma vārteja, tam nepieciešams maršruts uz otru filiāli, kas norāda uz VPN maršrutētāju. Bez tā pieprasījums ierodas, bet atbilde iziet pa interneta ceļu, un lietotājs redz savienojumu, kas atveras un pēc tam iestrēgst.
Neizmantojiet tīkla drošības grupu vārtejas apakštīklā, lai to izlabotu. Šim apakštīklam ir savas prasības, un NSG tur nav atbalstīts filiāles puses politikas aizstājējs. Filtrēšana pieder filiāļu ugunsmūriem un pašām darba slodzēm, kur noteikumus var pārskatīt to īpašnieki. Šo noteikumu pārvietošana uz apakštīkla NSG tos arī paslēpj no komandas, kas atkļūdos nākamo kļūmi.
Atļaujiet darbību, pēc tam pierādiet to ar noraidītu testu
Apgūts maršruts nav atļauja. Atļaujiet avotu, galamērķi un pakalpojumu, kas jums patiešām nepieciešams, caur filiāļu ugunsmūriem un galapunkta politiku, un atstājiet pārējo noraidītu.
Pārbaudiet no parastas darba slodzes filiālē A uz reālu pakalpojumu filiālē B, apstipriniet atbildi, pēc tam mēģiniet darbību, kurai jāpaliek aizliegtai. VPN ierīces ģenerētā datplūsma var izmantot citu avota adresi un izlaist LAN maršrutēšanas posmu, tāpēc veiksmīgs ping no maršrutētāja pierāda mazāk, nekā šķiet.
Pabeidziet, pierakstot četrus faktus: apmainītos prefiksus, izmantotos ASN, katras puses LAN atgriešanās ceļu un politiku, kas atļauj pakalpojumu. Ja kāds no tiem trūkst, iestatījums darbojas līdz pirmajai izmaiņai, un tad neviens nevar izskaidrot, kāpēc.