Trafyk tusken twa filialen liede troch in Azure VPN-gateway
Twa Site-to-Site-ferbiningen op ien Azure VPN-gateway kinne filiaaltrafyk trochjaan, mar allinnich as beide einen it prefiks leare en it LAN-werompaad bestiet.
Twa filialen kinne trafyk útwikselje troch in Azure VPN-gateway sûnder direkte tunnel tusken har. Elk filiaal iepenet in Site-to-Site-ferbining nei deselde gateway, en de gateway jout de learde prefiksen troch tusken de twa ferbiningen. Wat dit wurkje lit is net de twadde tunnel, mar de rûtútwikseling: filiaal A moat it prefiks fan filiaal B leare, en B dat fan A. Wurkje de kontrôles hjirûnder yn folchoarder troch en stop by de earste dy't mislearret, want elke lettere stap hinget dêrfan ôf.
Betinksten, foardat jo wat konfigurearje
Fjouwer betingsten beslute oft dit ûntwerp hielendal wurkje kin. De gateway moat rût-basearre wêze en op in SKU dy't BGP stipet, beide ferbiningen moatte BGP ynskeakele hawwe, de adresromten fan de filialen meie net oerlaapje, en gjin kant mei op NAT fertrouwe om syn echte prefiks te ferbergjen.
Plan de ASN's bewust. De dokumintearre standert fan Azure is 65515, en elke filiaalrûter hat syn eigen privee ASN nedich dy't net botst mei de gateway of it oare filiaal. In standertwerd brûke sûnder in besteande gateway-konfiguraasje te kontrolearjen is hoe't in AS-paad letter wegere wurdt.
Befêstigje ek dat jo gjin VNet-peeringgedrach ferwachtsje. De gateway wikselet rûtes út tusken de twa ferbiningen dy't jo konfigurearre hawwe; it makket willekeurige peerings net transityf. As in tredde netwurk beide filialen berikke moat, hat it syn eigen ferbining of syn eigen rûtpaad nedich, net de oanname dat de gateway trafyk ferspriede sil. Skriuw dy grins op foar it earste feroaringsfinster, want it is de ûntwerpbeslissing dêr't minsken op weromkomme as letter in side tafoege wurdt.
Konfigurearje yn dizze folchoarder
Elke stap hat in waarnimber resultaat, dus gean net fierder oant it ferskynt.
- Skeakelje BGP yn op de firtuele netwurk-gateway en notearje syn ASN en peer-adres.
- Meitsje in lokale netwurk-gateway per filiaal mei it echte adresromte fan dat filiaal, syn ASN en syn BGP-peer-adres.
- Meitsje elke Site-to-Site-ferbining en skeakelje BGP yn op de ferbining sels.
- Konfigurearje de filiaalrûter om mei it gateway-adres dat Azure tawiisd hat te pearen, net mei it publike IKE-einpunt fan de gateway op grûn fan in oanname.
Stap fjouwer is wêr't de measte besykjen fêstrinne. It BGP-peer-adres dat Azure rapportearret is it adres dat de filiaalrûter as buorman brûke moat, en it is net altyd it adres dat minsken fan it tunnelskema ferwachtsje.
Advertearje it filiaalprefiks sels, bygelyks 10.10.0.0/16 fan A en 10.20.0.0/16 fan B. Advertearje gjin standertrûte of in breed aggregaat om in ûntbrekkend spesifyk netwurk te dekken; it gat komt letter werom as in stil swart gat.
Ferifiearje de rûtútwikseling oan beide kanten
Ferbiningsstatus is net de kontrôle. IPsec kin op beide ferbiningen omheech wêze wylst gjin prefiks tusken har oergiet. Lês de BGP-peers fan de gateway en syn learde rûtes, en befêstigje dan dat de rûte nei it oare filiaal as in brûkber paad ferskynt.
| 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 |
In prefiks dat yn in BGP-tabel stiet kin de trochstjoerbeslissing noch ferlieze oan in statyske rûte of in spesifiker prefiks. Kontrolearje de selektearre rûte, net allinnich de ûntfongen.
Folgje it werompaad oan de LAN-kant
Dit is it diel dat yn Azure korrekt liket en op it plak mislearret. In host yn filiaal A stjoert syn pakket nei A's VPN-rûter allinnich as dy rûter syn standertgateway is, of as de host of syn gateway in rûte foar B syn prefiks hat. Itselde moat yn de oare rjochting jilde.
As in aparte kearnswitch de standertgateway fan it LAN is, hat it de rûte nei it oare filiaal nedich dy't nei de VPN-rûter wiist. Sûnder dy komt it fersyk oan en giet it antwurd fuort troch it ynternetpaad, en de brûker sjocht in ferbining dy't iepenet en dan hinget.
Gryp net nei in netwurkfeiligensgroep op it gateway-subnet om dit te reparearjen. Dat subnet hat syn eigen easken en in NSG dêr is gjin stipe ferfanging foar belied oan de filiaalkant. Filtering heart op de filiaalfirewalls en op de workloads sels, wêr't de regels troch de eigners besjoen wurde kinne. Dizze regels nei in subnet-NSG ferpleatse ferberget se ek foar it team dat de folgjende steuring ûntbaarchje sil.
Lit de operaasje ta en bewiis it dan mei in wegere test
In learde rûte is gjin tastimming. Lit de boarne, bestimming en tsjinst dy't jo echt nedich hawwe troch de filiaalfirewalls en it einpuntbelied, en lit de rest wegere.
Test fan in gewoane workload yn filiaal A nei in echte tsjinst yn filiaal B, befêstigje it antwurd, en besykje dan in operaasje dy't ferbean bliuwe moat. Trafyk dy't troch it VPN-apparaat sels generearre wurdt kin in oar boarne-adres brûke en de LAN-rûteringstap oerslaan, dus in suksesfolle ping fan de rûter bewiist minder as it liket.
Einigje troch fjouwer feiten op te skriuwen: de útwiksele prefiksen, de brûkte ASN's, it LAN-werompaad foar elke kant en it belied dat de tsjinst tastiet. As ien fan har ûntbrekt, wurket de opset oant de earste feroaring, en dan kin nimmen ferklearje wêrom.