Azure privatus IP VPN per ExpressRoute be NVA

Mitas yra tas, kad srauto šifravimui per ExpressRoute privatų peering reikia virtualaus tinklo įrenginio. Nereikia. Azure palaiko Site-to-Site VPN Gateway, kurio tunelio galinis taškas yra privatus RFC1918 adresas, perduodamas per grandinę, o įrenginys yra neprivalomas, o ne struktūrinis. Ką įrenginio mitas slepia, yra ta dalis, kuri tikrai skauda: privataus galinio taško įjungimas viename objekte, o ne dviejuose, ir leidimas tiesioginiam peering maršrutui tyliai laimėti prieš užšifruotą kelią.

Iš kur atsirado mitas

Teiginys turi garbingą kilmę. Metų metus praktiškas IPsec per privatų peering receptas buvo NVA, nes valdoma vartų sąsaja siūlė tik viešuosius galinius taškus. Tai pasikeitė, o atsakymai, parašyti prieš pasikeitimą, vis dar cituojami gijose, kuriose niekas netikrina datos. Pataisa siaura: egzistuoja VPN vartai su privačiu adresu, ir jie keičia galinį tašką, o ne maršrutizavimo logiką aplink jį.

Niekas iš to neišleidžia NVA į pensiją. Tai išleidžia į pensiją prielaidą, kad įrenginys yra vienintelis kelias į reikalavimą.

Įjunkite privatų galinį tašką abiejuose lygiuose

Pradėkite nuo veikiančios ExpressRoute privataus peeringo jungties, susietos su VNet, kuriame yra VPN vartai. Vietinė pusė jau turi pasiekti atitinkamus privačius adresus per tą grandinę, nes tunelis naudos tuos adresus kaip transportą. Tada vartų išankstinė sąlyga: Microsoft privataus IP VPN procedūra reikalauja vartų, pastatytų ant Standard viešojo IP ištekliaus. Privatus tunelio adresavimas šios sąlygos nepanaikina, o tai stebina žmones, manančius, kad „privatus“ reiškia „niekur jokio viešo IP“.

Dabar įjunkite vėliavėlę abiejose vietose. Vartų konfigūracija turi savo jungiklį privatiems IP, o atskira Site-to-Site jungtis turi antrą, kuris verčia tą jungtį naudoti privatų adresą. Vieno nustatymas be kito yra dažniausia nepilna konfigūracija; tunelis arba nesudaromas, arba sudaromas prie neteisingo galinio taško.

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}'

Patikrinkite savybių pavadinimus pagal įdiegtą CLI versiją, nes portalo etiketės ir CLI savybės ne visada turi tą pačią formuluotę. Aktyvūs-aktyvūs vartai siūlo du privačius tunelio adresus, o vietiniam įrenginiui reikia sukonfigūruotų abiejų partnerių, jei norite, kad ta pertekliškumas ką nors reikštų. BGP nereikia vien tam, kad šis privataus adreso tunelis būtų pakeltas, nors jis paprastai yra prefiksų platinimo būdo dalis.

Antrasis mitas: sudarytas tunelis šifruoja jūsų srautą

Du keliai dabar pasiekia programos tinklą: tiesioginis privataus peeringo kelias ir kelias per VPN. Abu veikia. Tik vienas taiko šį IPsec sluoksnį. Microsoft dokumentuoja, kad kai identiški prefiksai skelbiami per ExpressRoute ir per VPN, Azure teikia pirmenybę tiesioginiam ExpressRoute keliui, todėl sveikas tunelis su sveikais skaitikliais nieko neįrodo apie tai, kur nuėjo programos paketai.

Dokumentuoti nukreipimo metodai yra aprėpiantis diapazonas ExpressRoute ir konkretesnis apsaugotas diapazonas VPN, arba nesusikertantys prefiksai abiejuose keliuose. Pavyzdžiui, privatus peering gali nešti 10.40.0.0/16, o VPN skelbia 10.40.12.0/24. Konkretesnis prefiksas laimi, o likusi diapazono dalis lieka tiesioginė.

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

Atlikite tą patį patikrinimą vietine kryptimi, nes jūsų maršrutizatoriaus nuostata nusprendžia, kuria puse išeina siunčiamas srautas. Ir laikykite paties tunelio transportą ExpressRoute kelyje; maršrutas, kuris įtraukia vartų privatų galinį tašką į tunelį, padaro tunelį priklausomą nuo savęs.

Nuspręskite, kas atsitinka, kai tunelis nukrenta

Konkretesnis VPN maršrutas išnyksta, kai tunelis nukrenta, o platesnis tiesioginis maršrutas lieka. Tada srautas teka nešifruotas ir viskas atrodo sveikai, o tai yra blogiausias gedimo režimas reikalavimui, kuris egzistuoja šifravimui garantuoti. Jei reikalavimas draudžia tą atsarginį variantą, maršrutizavimas ir prieigos politika turi tai pasakyti aiškiai, o ne pasikliauti tunelio prieinamumu.

Užsirašykite, kurie prefiksai gali likti tiesiogiai pasiekiami, o kurie turi sustoti, kai nėra užšifruoto kelio. Tada išbandykite leidžiamą atvejį su realiu srautu ir palyginkite jungties skaitiklius, nes vien maršrutų lentelė nepasakys, ar šifravimo reikalavimas vis dar galioja.

Ši sistema taip pat leidžia vertinti NVA pagal jo tikrąsias funkcijas, tokias kaip keli tuneliai, pralaidumas ar tiekėjo patikra, o ne pirkti jį todėl, kad galinis taškas yra privatus.