UDR din Azure către o poartă VPN: o singură destinație, nu tot traficul de ieșire

Adaugi o rută definită de utilizator pentru un prefix extern, o îndrepți spre gateway-ul VPN, iar traficul tot iese pe calea de internet a Azure. Sau iese corect și răspunsul nu se întoarce niciodată. Ambele rezultate provin din aceeași greșeală: a trata următorul hop din Azure ca întregul proiect. Tabelul de rute decide doar ce ieșire ia un pachet în interiorul Azure. Ce se întâmplă cu el după tunel și cum se întoarce răspunsul este a doua jumătate pe care trebuie să o construiți.

Următorul hop este un gateway, nu IP-ul unui echipament

O UDR trimite un prefix potrivit către un tip de următor hop, iar VirtualNetworkGateway este un tip, nu o adresă. Oamenii lipesc IP-ul privat al gateway-ului într-o rută VirtualAppliance și apoi se întreabă de ce nimic nu se potrivește, pentru că acel tip așteaptă mai degrabă o placă de rețea sau un balansator de încărcare intern. Documentația de rutare a Microsoft limitează și următorul hop al gateway-ului la o rețea virtuală al cărei gateway este un gateway VPN. ExpressRoute, Route Server și un hub Virtual WAN nu sunt adresate de acea opțiune.

Verificați ce are de fapt rețeaua virtuală înainte de a scrie ruta. Dacă proiectul rutează printr-un hub, ruta aparține proprietarului rutării hub-ului, nu spoke-ului pe care îl editați.

Citiți ruta efectivă înainte de a modifica ceva

Azure combină rute de sistem, prefixe învățate prin BGP și UDR-uri într-un tabel de rute efectiv pentru fiecare placă de rețea, iar prefixul potrivit cel mai lung câștigă indiferent de unde provine. Pentru același prefix, o UDR învinge o rută BGP. Această ordine este motivul pentru care o UDR veche dintr-un experiment anterior poate suprascrie în tăcere prefixul pe care tocmai l-ați învățat prin tunel.

Priviți mai întâi tabelul efectiv, apoi decideți dacă adăugați o rută sau o înlocuiți:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Citiți și coloana sursă, nu doar prefixul. O rută cu prefixul corect și sursa greșită vă spune ce obiect să editați și vă scutește de a adăuga o a doua rută care pierde în fața primei.

Scrieți ruta pe prefixul și subrețeaua reale

Folosiți prefixul real al destinației, luat din serviciul pe care îl atingeți efectiv, în locul unui interval public copiat dintr-o postare pe forum. Începeți cu un singur serviciu aprobat înainte de a lua în calcul o rută implicită care mută toată ieșirea. Apoi atașați tabelul de rute la subrețeaua sarcinii de lucru. Subrețeaua gateway-ului are cerințele ei, iar atașarea tabelului acolo sparge gateway-ul în loc să direcționeze sarcina.

Creați ruta, apoi legați tabelul de subrețeaua care găzduiește sarcina de lucru:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

Și propagarea contează. Cu propagarea BGP activată pe acel tabel, prefixele învățate apar lângă cele scrise de dvs., iar un prefix învățat mai specific poate învinge o UDR mai largă. Dezactivați propagarea doar când doriți ca setul de UDR-uri să fie autoritar pentru acea subrețea.

Terminați jumătatea locală, altfel fluxul moare acolo

Gateway-ul local trebuie să accepte sursa Azure, să o trimită mai departe la destinație și să permită aplicația. Calea sa ulterioară poate fi o ieșire de internet sau un alt hop privat, dar acea decizie aparține planului, nu tabelului de rute Azure. Eșecul obișnuit este întoarcerea. O destinație de internet nu va ruta o sursă privată Azure înapoi la dvs., așa că răspunsul merge la propriul gateway implicit și moare, sau nu pleacă deloc.

Două proiecte rezolvă asta și nu sunt interschimbabile. Traduceți sursa la ieșire, astfel încât destinația să răspundă la o adresă publică deținută de rețeaua locală. Sau păstrați sursa și construiți o relație de retur rutată, ca răspunsurile să se întoarcă prin tunel. Alegeți una și notați ce adresă va vedea aplicația.

Selectorii și listele de permisiuni sunt separate de toate acestea. Alegerea unui următor hop Azure nu lărgește selectorii de trafic VPN și nu schimbă lista de surse permise a unui serviciu extern.

Verificați cu sursa observată de destinație

Trimiteți cererea din sarcina reală, nu dintr-un host de salt din altă subrețea, apoi citiți adresa sursă observată de destinație. Acea singură valoare vă spune care dintre cele două proiecte de retur este în vigoare. Verificați apoi calea răspunsului și confirmați că traficul obișnuit de administrare către VM încă funcționează, pentru că o rută implicită adăugată din greșeală se manifestă ca sesiune SSH ruptă mult înainte de a se manifesta ca aplicație ruptă.

Un tranzit printr-un prefix selectat este o schimbare mult mai îngustă decât tunelarea forțată. Păstrați-l îngust și revenirea este ștergerea unei rute.