VPN naar de VPC werkt, maar de beheerde service loopt in een time-out

Een beheerde database bereiken via een VPN mislukt meestal om een reden die niemand in de runbook schreef: de tunnel eindigt aan de rand van je netwerk, terwijl de service nooit aan jouw kant daarvan heeft gestaan. De routetabel ziet er correct uit, de tunnel meldt zich actief, en de verbinding loopt toch in een time-out. Werk de vier controles hieronder in volgorde af en stop bij de eerste waarvan de slaagvoorwaarde niet klopt, want elke controle daarna veronderstelt dat de vorige zijn geslaagd.

Controle één: waar leeft het eindpunt werkelijk?

Een VPN-gateway verbindt twee netwerken waarvan jij de adressering beheert. Een beheerde service draait achter de eigen voordeur van de provider, en die deur heeft afhankelijk van het product een van drie vormen. Als je niet weet met welke vorm je te maken hebt, helpt geen enkele hoeveelheid routewerk, want de storing is misschien helemaal geen routestoring.

De meeste verspilde middagen ontstaan doordat deze classificatie wordt overgeslagen en meteen naar de routetabel wordt gegaan. Een bij de provider gehoste service met een openbaar eindpunt zit niet achter je tunnel wat het diagram ook zegt, en een VPC-gekoppelde zal nooit in een openbaar DNS-antwoord opduiken.

Controle twee: een VPC-gekoppelde service zoals ElastiCache

Caches van dat soort worden binnen je eigen VPC geadresseerd en hebben helemaal geen naar internet gerichte luisteraar. Een client-VPN die in dezelfde VPC eindigt kan ze bereiken, maar alleen wanneer drie voorwaarden samenvallen. Het cache-eindpunt moet gekoppeld zijn aan subnetten die je tunnel ziet, de beveiligingsgroep moet het adres toestaan waar je clients vandaan komen, en de clientkant heeft een route nodig die de cachesubnetten dekt.

De gebruikelijke fout is aannemen dat een verbinding ergens in de buurt meetelt. De VPN aan een andere VPC koppelen, of alleen op peering leunen, breidt de beveiligingsgroep van de cache of de routetabel van het subnet niet uit naar je clients. Wanneer de bestaande tunnel elders eindigt, is een jump host of een VPN-server binnen die VPC de gebruikelijke terugvaloptie. Die terugvaloptie is een omweg en geen ontwerp, en zou als zodanig in de runbook moeten worden gemarkeerd.

Controle drie: een PaaS-eindpunt met een openbare naam

Azure Database for PostgreSQL presenteert een openbare servernaam. Het geeft je geen privéadres dat je in een hosts-bestand kunt vastpinnen en via een gateway kunt routeren. Service-eindpunten voor virtuele netwerken beperken welke subnetten een resource mogen bereiken; ze machtigen geen lokaal client die via een VPN binnenkomt.

Privétoegang krijgen betekent een privé-eindpunt of een private-linkontwerp invoeren en daarna een privé-DNS-zone toevoegen zodat de openbare naam met dat eindpunt antwoordt in plaats van met het internet. Een VPN gecombineerd met een service-eindpuntregel is een andere architectuur die alleen op een diagram hetzelfde lijkt. App Service volgt dezelfde logica uit de tegenovergestelde richting: VNet-integratie laat de app uitgaande oproepen naar een VNet doen, en ze maakt geen inkomend privépad vanaf je tunnel. Inkomende privétoegang vereist daarom een privé-eindpunt, een App Service Environment of een gateway vóór de app, en welke daarvan je kunt gebruiken hangt van het plan af.

Controle vier: producten met hun eigen voordeur

Firebase Hosting kan niet aan een Cloud VPN worden gekoppeld, omdat de hostinglaag een wereldwijd front is en niet iets binnen de VPC van een project. Het gedocumenteerde alternatief is het gecontroleerde toegangspunt zelf te bouwen, met een proxy-instantie of een load balancer die op een bucket steunt. Hoe dan ook houdt de site op een puur hostingproduct te zijn en wordt het infrastructuur die je nu beheert. Die ruil is het waard te benoemen voordat iemand belooft dat de tunnel hem dekt.

Private API Gateway staat dichter bij de VPC-servicekant: een interface-VPC-eindpunt publiceert een hostnaam waarvan de antwoorden privéadressen zijn, en verkeer vanaf jouw locatie komt via de tunnel of een speciale interconnect binnen. Het eindpunt moet aan de API gekoppeld zijn, en het certificaat plus de hostnaam moeten overeenkomen met het aangepaste domein dat bellers gebruiken.

Google Cloud VPN-tunnels binden aan peer-IP-adressen, niet aan namen. DNS-doorsturing wordt apart geconfigureerd, waardoor een tunnel volkomen gezond kan zijn terwijl opzoekingen in de externe privézone nog steeds mislukken.

Localiseer dan de grens

Voer dezelfde verbinding uit vanaf een VM binnen de VPC. Wanneer het daar lukt en vanaf de VPN-client mislukt, zit de kloof tussen het clientpad en het service-eindpunt: een route, een beveiligingsgroep, een eindpuntbeleid of een naam. Wanneer beide pogingen mislukken, kan niets in dat netwerk de service bereiken, en was de VPN nooit het obstakel.

getent hosts db.internal.example
nc -vz db.internal.example 5432

Doe de naamopzoeking en de poortcontrole apart, want ze mislukken om verschillende redenen en het paar vertelt je welke helft van het pad stuk is. Een naam die naar een openbaar adres oplost, vertelt je dat de privé-DNS-zone niet in het spel is.