VPN IP privat i Azure mbi ExpressRoute pa një NVA

Miti është se kriptimi i trafikut mbi peering-un privat të ExpressRoute kërkon një pajisje virtuale rrjeti. Nuk kërkon. Azure mbështet një Site-to-Site VPN Gateway, pika e fundit e tunelit të së cilës është një adresë private RFC1918 e transportuar përmes qarkut, dhe pajisja është opsionale, jo strukturore. Ajo që miti i pajisjes fsheh është pjesa që të vret vërtet: aktivizimi i pikës fundore private në një objekt në vend të dy, dhe lejimi që një rrugë peering direkte të fitojë në heshtje mbi rrugën e kriptuar.

Nga lindi miti

Pohimi ka një prejardhje të respektueshme. Për vite me radhë receta praktike për IPsec mbi peering privat ishte një NVA, sepse porta e menaxhuar ekspozonte vetëm pika fundore publike. Kjo ndryshoi, dhe përgjigjet e shkruara para ndryshimit citohen ende në tema ku askush nuk kontrollon datën. Korrigjimi është i ngushtë: ekziston një portë VPN me adresë private, dhe ajo ndryshon pikën fundore, jo logjikën e rrugëzimit rreth saj.

Asgjë nga kjo nuk e pensionon NVA-në. Ajo pensionon supozimin se pajisja është e vetmja rrugë drejt kërkesës.

Aktivizoni pikën fundore private në të dy nivelet

Filloni nga një lidhje peering privat i ExpressRoute që funksionon dhe është e lidhur me VNet-in që përmban portën VPN. Ana lokale duhet të ketë arritur tashmë adresat private përkatëse përmes atij qarku, sepse tuneli do t'i përdorë ato adresa si transport. Pastaj parakushti i portës: procedura e Microsoft për VPN me IP privat kërkon një portë të ndërtuar mbi një burim IP publik Standard. Adresimi privat i tunelit nuk e heq atë kusht, gjë që i befason ata që supozojnë se «privat» do të thotë «asnjë IP publike askund».

Tani aktivizoni flamurin në të dyja vendet. Konfigurimi i portës ka çelësin e vet për IP-të private, dhe lidhja individuale Site-to-Site ka një të dytë që e detyron atë lidhje të përdorë adresën private. Vendosja e njërës dhe jo e tjetrës është konfigurimi i paplotë më i zakonshëm; tuneli ose nuk vendoset ose vendoset drejt pikës fundore të gabuar.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

Verifikoni emrat e vetive kundrejt versionit të CLI të instaluar, sepse etiketat e portalit dhe vetitë e CLI nuk kanë gjithmonë të njëjtin formulim. Një portë aktive-aktive ekspozon dy adresa private tuneli, dhe pajisja lokale duhet t'i ketë të dyja palët të konfiguruara nëse doni që ai tepricë të thotë diçka. BGP nuk kërkohet thjesht për të ngritur këtë tunel me adresë private, megjithëse zakonisht është pjesë e mënyrës se si shpërndani prefikset.

Miti i dytë: një tunel i vendosur kripton trafikun tuaj

Dy rrugë tani arrijnë në rrjetin e aplikacionit: rruga e drejtpërdrejtë e peering-ut privat dhe rruga përmes VPN-së. Të dyja funksionojnë. Vetëm njëra zbaton këtë shtresë IPsec. Microsoft dokumenton se kur prefikset identike reklamohen përmes ExpressRoute dhe përmes VPN-së, Azure preferon rrugën direkte të ExpressRoute, kështu që një tunel i shëndetshëm me numërues të shëndetshëm nuk provon asgjë për vendin ku shkuan paketat e aplikacionit.

Metodat e drejtimit të dokumentuara janë një interval mbulues në ExpressRoute me një interval të mbrojtur më specifik në VPN, ose prefikse të ndara në dy rrugët. Për shembull, peering-u privat mund të mbajë 10.40.0.0/16 ndërsa VPN reklamon 10.40.12.0/24. Prefiksi më specifik fiton dhe pjesa tjetër e intervalit mbetet direkte.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

Bëni të njëjtin kontroll në drejtimin lokal, sepse preferenca e routerit tuaj vendos nga cila anë del trafiku në dalje. Dhe mbani transportin e vetë tunelit në rrugën e ExpressRoute; një rrugë që tërheq pikën fundore private të portës brenda tunelit e bën tunelin të varur nga vetja.

Vendosni çfarë ndodh kur tuneli bie

Një rrugë VPN më specifike zhduket kur tuneli bie, ndërsa rruga direkte më e gjerë mbetet. Trafiku atëherë rrjedh pa kriptim dhe gjithçka duket e shëndetshme, që është mënyra më e keqe e dështimit për një kërkesë që ekziston për të garantuar kriptimin. Nëse kërkesa e ndalon atë rikthim, rrugëzimi dhe politika e aksesit duhet ta thonë këtë në mënyrë eksplicite në vend që të mbështeten në disponueshmërinë e tunelit.

Shkruani cilat prefikse mund të mbeten të arritshme drejtpërdrejt dhe cilat duhet të ndalen kur mungon rruga e kriptuar. Më pas provoni rastin e lejuar me trafik real dhe krahasoni numëruesit e lidhjes, sepse tabela e rrugëve e vetme nuk do t'ju thotë nëse kërkesa e kriptimit vazhdon të zbatohet.

Ai kornizë ju lejon gjithashtu të vlerësoni një NVA sipas funksioneve të tij reale, si tunele të shumta, xhiroja ose inspektimi i furnizuesit, në vend që të blini një sepse pika fundore është private.