Enkursigi trafikon inter du filioj tra Azure VPN-pordego
Du Site-to-Site-konektoj sur unu Azure VPN-pordego povas pasigi filian trafikon, sed nur kiam ambaŭ finoj lernas la prefikson kaj la LAN-revena vojo ekzistas.
Du filioj povas interŝanĝi trafikon tra Azure VPN-pordego sen iu rekta tunelo inter ili. Ĉiu filio malfermas Site-to-Site-konekton al la sama pordego, kaj la pordego transdonas la lernitajn prefiksojn inter la du konektoj. Tio, kio funkciigas tion, estas ne la dua tunelo sed la itinera interŝanĝo: filio A devas lerni la prefikson de filio B, kaj B tiun de A. Trapasu la subajn kontrolojn laŭvice kaj haltu ĉe la unua, kiu malsukcesas, ĉar ĉiu posta paŝo dependas de ĝi.
Antaŭkondiĉoj, antaŭ ol vi agordos ion ajn
Kvar kondiĉoj decidas, ĉu ĉi tiu dezajno povas entute funkcii. La pordego devas esti itinera kaj sur SKU, kiu subtenas BGP, ambaŭ konektoj devas havi BGP ŝaltita, la adresaj spacoj de la filioj ne rajtas interkovriĝi, kaj neniu flanko rajtas fidi je NAT por kaŝi sian realan prefikson.
Planu la ASN-ojn konscie. La dokumentita defaŭlto de Azure estas 65515, kaj ĉiu filia enkursigilo bezonas sian propran privatan ASN, kiu ne kolizias kun la pordego aŭ la alia filio. Reuzi defaŭlton sen kontroli ekzistantan pordegan agordon estas la maniero, kiel itinero AS poste malakceptiĝas.
Ankaŭ konfirmu, ke vi ne atendas konduton de VNet-samtavoligo. La pordego interŝanĝas itinerojn inter la du konektoj, kiujn vi agordis; ĝi ne faras arbitrajn samtavoligojn transiraj. Se tria reto devas atingi ambaŭ filiojn, ĝi bezonas sian propran konekton aŭ sian propran itineran vojon, ne la supozon, ke la pordego disventumos la trafikon. Skribu tiun limon antaŭ la unua ŝanĝa fenestro, ĉar ĝi estas la dezajna decido, al kiu homoj revenas, kiam poste aldoniĝas loko.
Agordi laŭ ĉi tiu ordo
Ĉiu paŝo havas observeblan rezulton, do ne antaŭeniru ĝis ĝi aperos.
- Ŝaltu BGP sur la virtuala reta pordego kaj notu ĝian ASN kaj samtavoligan adreson.
- Kreu lokan retan pordegon por ĉiu filio kun la reala adresa spaco de tiu filio, ĝia ASN kaj ĝia BGP-samtavoliga adreso.
- Kreu ĉiun Site-to-Site-konekton kaj ŝaltu BGP sur la konekto mem.
- Agordi la filian enkursigilon samtavoligi kun la pordega adreso, kiun Azure asignis, ne kun la publika IKE-finpunkto de la pordego laŭsupoze.
La kvara paŝo estas kie plej multaj provoj haltas. La BGP-samtavoliga adreso, kiun Azure raportas, estas tiu, kiun la filia enkursigilo devas uzi kiel najbaron, kaj ĝi ne ĉiam estas la adreso, kiun homoj atendas el la tunela diagramo.
Anoncu la filian prefikson mem, ekzemple 10.10.0.0/16 de A kaj 10.20.0.0/16 de B. Ne anoncu defaŭltan itineron aŭ vastan agregaton por kovri mankan specifan reton; la breĉo revenas poste kiel silenta nigra truo.
Kontrolu la itineran interŝanĝon ĉe ambaŭ finoj
Konekta statuso ne estas la kontrolo. IPsec povas esti aktiva sur ambaŭ konektoj dum neniu prefikso transiras inter ili. Legu la BGP-samtavoligojn de la pordego kaj ĝiajn lernitajn itinerojn, poste konfirmu, ke la itinero al la alia filio aperas kiel uzebla vojo.
| 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 |
Prefikso ĉeestanta en BGP-tabelo ankoraŭ povas perdi la plusendan decidon al statika itinero aŭ pli specifa prefikso. Kontrolu la elektitan itineron, ne nur la ricevitan.
Sekvu la revenan vojon ĉe la LAN-flanko
Ĉi tio estas la parto, kiu aspektas ĝusta en Azure kaj malsukcesas surloke. Gastigo en filio A sendas sian paketon al la VPN-enkursigilo de A nur se tiu enkursigilo estas ĝia defaŭlta pordego, aŭ se la gastigo aŭ ĝia pordego havas itineron por la prefikso de B. La samo devas validi en la alia direkto.
Se aparta kernkomutilo estas la defaŭlta pordego de la LAN, ĝi bezonas la itineron al la alia filio montrantan al la VPN-enkursigilo. Sen ĝi la peto alvenas kaj la respondo foriras per la interreta vojo, kaj la uzanto vidas konekton, kiu malfermiĝas kaj poste pendas.
Ne prenu retan sekurecan grupon sur la pordega subreto por ripari ĉi tion. Tiu subreto havas proprajn postulojn kaj NSG tie ne estas subtenata anstataŭaĵo por filia politiko. Filtrado apartenas al la filiaj fajroŝirmiloj kaj al la laborŝarĝoj mem, kie la reguloj povas esti reviziitaj de la homoj, kiuj posedas ilin. Movi tiujn regulojn al subreta NSG ankaŭ kaŝas ilin antaŭ la teamo, kiu sencimigos la sekvan paneon.
Permesu la operacion, poste pruvu ĝin per rifuzita testo
Lernita itinero ne estas permeso. Permesu la fonton, celon kaj servon, kiujn vi efektive bezonas, tra la filiaj fajroŝirmiloj kaj la finpunkta politiko, kaj lasu la reston rifuzita.
Testu de ordinara laborŝarĝo en filio A al reala servo en filio B, konfirmu la respondon, poste provu operacion, kiu devas resti malpermesita. La trafiko generita de la VPN-aparato mem povas uzi alian fontan adreson kaj preterpasi la LAN-enkursigan stadion, do sukcesa ping de la enkursigilo pruvas malpli, ol ĝi ŝajnas.
Finu skribante kvar faktojn: la interŝanĝitaj prefiksoj, la uzataj ASN-oj, la LAN-revena vojo por ĉiu flanko, kaj la politiko, kiu permesas la servon. Se unu el ili mankas, la aranĝo funkcias ĝis la unua ŝanĝo, kaj poste neniu povas klarigi kial.