Direcționarea traficului între două sucursale printr-un gateway VPN Azure
Două conexiuni site-to-site pe un singur gateway VPN Azure pot transporta traficul sucursalelor, dar numai când ambele capete învață prefixul și există calea de întoarcere în LAN.
Două sucursale pot schimba trafic printr-un gateway VPN Azure fără niciun tunel direct între ele. Fiecare sucursală deschide o conexiune site-to-site către același gateway, iar gateway-ul transmite prefixele învățate între cele două conexiuni. Ceea ce face asta să funcționeze nu este al doilea tunel, ci schimbul de rute: sucursala A trebuie să învețe prefixul sucursalei B, iar B pe cel al lui A. Parcurgeți verificările de mai jos în ordine și opriți-vă la prima care eșuează, pentru că fiecare pas ulterior depinde de ea.
Precondiții, înainte de a configura ceva
Patru condiții decid dacă acest proiect poate funcționa. Gateway-ul trebuie să fie bazat pe rute și pe un SKU care acceptă BGP, ambele conexiuni trebuie să aibă BGP activat, spațiile de adrese ale sucursalelor nu trebuie să se suprapună, iar niciuna dintre părți nu poate depinde de NAT pentru a-și ascunde prefixul real.
Planificați ASN-urile cu grijă. Valoarea implicită documentată a Azure este 65515, iar fiecare router de sucursală are nevoie de propriul ASN privat care nu intră în conflict cu gateway-ul sau cu cealaltă sucursală. Reutilizarea unei valori implicite fără verificarea unei configurații existente de gateway este modul în care o cale AS ajunge să fie respinsă mai târziu.
Confirmați și că nu vă așteptați la comportamentul de peering VNet. Gateway-ul schimbă rute între cele două conexiuni pe care le-ați configurat; nu face transitiv orice peering arbitrar. Dacă o a treia rețea trebuie să ajungă la ambele sucursale, are nevoie de propria conexiune sau de propria cale de rutare, nu de presupunerea că gateway-ul va distribui traficul. Notați această limită înainte de prima fereastră de schimbare, pentru că este decizia de proiectare la care oamenii revin când se adaugă mai târziu un nou sediu.
Configurați în această ordine
Fiecare pas are un rezultat observabil, așa că nu mergeți mai departe până nu apare.
- Activați BGP pe gateway-ul de rețea virtuală și notați ASN-ul și adresa de peer.
- Creați un gateway de rețea locală pentru fiecare sucursală cu spațiul de adrese real al sucursalei, ASN-ul și adresa de peer BGP.
- Creați fiecare conexiune site-to-site și activați BGP pe conexiunea în sine.
- Configurați routerul sucursalei să facă peering cu adresa de gateway atribuită de Azure, nu cu punctul final IKE public al gateway-ului pe baza unei presupuneri.
Al patrulea pas este locul unde se blochează majoritatea încercărilor. Adresa de peer BGP raportată de Azure este cea pe care routerul sucursalei trebuie să o folosească drept vecin, și nu este întotdeauna adresa pe care oamenii o așteaptă din diagrama tunelului.
Anunțați prefixul sucursalei în sine, de exemplu 10.10.0.0/16 din A și 10.20.0.0/16 din B. Nu anunțați o rută implicită sau un agregat larg pentru a acoperi o rețea specifică lipsă; golul revine mai târziu ca o gaură neagră tăcută.
Verificați schimbul de rute la ambele capete
Starea conexiunii nu este verificarea. IPsec poate fi activ pe ambele conexiuni fără ca vreun prefix să treacă între ele. Citiți peerii BGP ai gateway-ului și rutele învățate, apoi confirmați că ruta către cealaltă sucursală apare ca o cale utilizabilă.
| 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 |
Un prefix prezent într-un tabel BGP poate pierde totuși decizia de forwardare în fața unei rute statice sau a unui prefix mai specific. Verificați ruta selectată, nu doar pe cea primită.
Urmați calea de întoarcere pe partea LAN
Aceasta este partea care pare corectă în Azure și eșuează la fața locului. Un host din sucursala A își trimite pachetul către routerul VPN al lui A doar dacă acel router este gateway-ul său implicit, sau dacă hostul sau gateway-ul lui are o rută pentru prefixul lui B. Același lucru trebuie să fie valabil și în cealaltă direcție.
Dacă un switch de nucleu separat este gateway-ul implicit al LAN-ului, are nevoie de ruta către cealaltă sucursală care indică routerul VPN. Fără ea, cererea ajunge și răspunsul pleacă pe calea internetului, iar utilizatorul vede o conexiune care se deschide și apoi se blochează.
Nu apelați la un grup de securitate de rețea din subrețeaua gateway-ului pentru a remedia asta. Acea subrețea are propriile cerințe, iar un NSG acolo nu este un substitut acceptat pentru politica din partea sucursalei. Filtrarea aparține firewall-urilor sucursalelor și încărcărilor de lucru înseși, unde regulile pot fi revizuite de cei care le dețin. Mutarea acestor reguli într-un NSG de subrețea le ascunde și de echipa care va depana următoarea defecțiune.
Permiteți operațiunea și apoi demonstrați-o cu un test refuzat
O rută învățată nu este o permisiune. Permiteți sursa, destinația și serviciul de care aveți nevoie cu adevărat prin firewall-urile sucursalelor și prin politica punctului final, și lăsați restul refuzat.
Testați de la o încărcătură de lucru obișnuită din sucursala A către un serviciu real din sucursala B, confirmați răspunsul, apoi încercați o operațiune care trebuie să rămână interzisă. Traficul generat de aparatul VPN însuși poate folosi altă adresă de sursă și poate sări peste etapa de rutare LAN, așa că un ping reușit de pe router dovedește mai puțin decât pare.
Încheiați notând patru fapte: prefixele schimbate, ASN-urile folosite, calea de întoarcere LAN pentru fiecare parte și politica ce permite serviciul. Dacă lipsește unul, configurația funcționează până la prima schimbare, iar apoi nimeni nu poate explica de ce.