Azure privé-IP-VPN over ExpressRoute zonder NVA

De mythe is dat het versleutelen van verkeer via ExpressRoute private peering een virtueel netwerkapparaat vereist. Dat is niet zo. Azure ondersteunt een Site-to-Site VPN Gateway waarvan het tunnel-eindpunt een privé RFC1918-adres is dat over het circuit wordt vervoerd, en het apparaat is optioneel in plaats van structureel. Wat de apparaatmythe verbergt, is het deel dat echt pijn doet: het privé-eindpunt inschakelen op één object in plaats van twee, en een directe peering-route stil laten winnen van het versleutelde pad.

Waar de mythe vandaan komt

De bewering heeft een respectabele afkomst. Jarenlang was het praktische recept voor IPsec via private peering een NVA, omdat de beheerde gateway alleen openbare eindpunten aanbood. Dat veranderde, en antwoorden die vóór de verandering zijn geschreven, worden nog steeds geciteerd in threads waar niemand de datum controleert. De correctie is smal: er bestaat een VPN-gateway met privéadres, en die verandert het eindpunt, niet de routeringslogica eromheen.

Niets hiervan zet de NVA met pensioen. Het zet de aanname met pensioen dat een apparaat de enige weg naar de eis is.

Schakel het privé-eindpunt op beide niveaus in

Begin met een werkende ExpressRoute private-peeringverbinding die is gekoppeld aan het VNet met de VPN-gateway. De on-premises kant moet de relevante privéadressen al via dat circuit bereiken, omdat de tunnel die adressen als transport gebruikt. Dan de gateway-voorwaarde: de Microsoft-procedure voor privé-IP-VPN vereist een gateway op een Standaard openbare IP-resource. Privé-tunneladressering haalt die eis niet weg, wat mensen verrast die aannemen dat ‘privé’ ‘nergens een openbaar IP’ betekent.

Schakel nu de vlag op beide plaatsen in. De gatewayconfiguratie heeft zijn eigen schakelaar voor privé-IP's, en de afzonderlijke Site-to-Site-verbinding heeft een tweede die die verbinding het privéadres laat gebruiken. Eén instellen en de andere niet is de meest voorkomende onvolledige configuratie; de tunnel komt niet tot stand of komt tot stand naar het verkeerde eindpunt.

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

Controleer de eigenschapsnamen tegen de geïnstalleerde CLI-versie, want portaal-labels en CLI-eigenschappen hebben niet altijd dezelfde formulering. Een actief-actieve gateway biedt twee privé-tunneladressen, en het on-premises apparaat moet beide peers geconfigureerd hebben als die redundantie iets moet betekenen. BGP is niet nodig om alleen deze privé-geadresseerde tunnel op te zetten, hoewel het meestal deel uitmaakt van de manier waarop u prefixen distribueert.

De tweede mythe: een opgezette tunnel versleutelt uw verkeer

Twee paden bereiken nu het applicatienetwerk: het directe private-peeringpad en het pad via de VPN. Beide werken. Slechts één past deze IPsec-laag toe. Microsoft documenteert dat wanneer identieke prefixen via ExpressRoute en via de VPN worden aangekondigd, Azure het directe ExpressRoute-pad verkiest, dus een gezonde tunnel met gezonde tellers bewijst niets over waar de applicatiepakketten heen gingen.

De gedocumenteerde stuurmethoden zijn een dekkend bereik op ExpressRoute met een specifieker beschermd bereik op de VPN, of disjuncte prefixen op de twee paden. Ter illustratie kan private peering 10.40.0.0/16 dragen terwijl de VPN 10.40.12.0/24 aankondigt. Het specifiekere prefix wint en de rest van het bereik blijft direct.

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

Doe dezelfde controle in de on-premises richting, want de voorkeur van uw router bepaalt via welke kant uitgaand verkeer vertrekt. En houd het eigen transport van de tunnel op het ExpressRoute-pad; een route die het privé-eindpunt van de gateway de tunnel in trekt, maakt de tunnel afhankelijk van zichzelf.

Bepaal wat er gebeurt als de tunnel wegvalt

Een specifiekere VPN-route verdwijnt wanneer de tunnel wegvalt, terwijl de bredere directe route blijft. Het verkeer stroomt dan onversleuteld en alles lijkt gezond, wat de slechtste faalmodus is voor een eis die bestaat om versleuteling te garanderen. Als de eis die terugval verbiedt, moeten de routering en het toegangsbeleid dat expliciet zeggen in plaats van te vertrouwen op de beschikbaarheid van de tunnel.

Noteer welke prefixen direct bereikbaar mogen blijven en welke moeten stoppen wanneer het versleutelde pad ontbreekt. Test daarna het toegestane geval met echt verkeer en vergelijk de verbindingstellers, want de routetabel alleen vertelt u niet of de versleutelingseis nog steeds geldt.

Dat kader laat u ook een NVA beoordelen op zijn werkelijke functies, zoals meerdere tunnels, doorvoer of leveranciersinspectie, in plaats van er een te kopen omdat het eindpunt privé is.