VPN till VPC fungerar, men den förvaltade tjänsten får timeout
Tunneln slutar vid din kant, inte vid leverantörens ytterdörr. Klassificera målet som VM-hostat, VPC-anslutet eller endast offentligt innan du ändrar en rutt.
Att nå en förvaltad databas via VPN misslyckas oftast av en anledning som ingen skrev i runbooken: tunneln slutar vid kanten av ditt nätverk, medan tjänsten aldrig har legat på din sida av den. Ruttabellen ser korrekt ut, tunneln rapporterar att den är uppe, och anslutningen får timeout ändå. Gå igenom de fyra kontrollerna nedan i ordning och stanna vid den första där villkoret för godkänt inte är uppfyllt, eftersom varje kontroll därefter förutsätter att de föregående godkändes.
Kontroll ett: var bor slutpunkten egentligen?
En VPN-gateway förbinder två nätverk där du styr adresseringen. En förvaltad tjänst drivs bakom leverantörens egen ytterdörr, och den dörren har en av tre former beroende på produkten. Om du inte vet vilken form du har att göra med hjälper inget ruttarbete, eftersom felet kanske inte alls är ett ruttfel.
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
De flesta bortkastade eftermiddagarna kommer av att hoppa över den här klassificeringen och gå rakt till ruttabellen. En leverantörshostad tjänst med offentlig slutpunkt ligger inte bakom din tunnel vad diagrammet än säger, och en VPC-ansluten kommer aldrig att dyka upp i ett offentligt DNS-svar.
Kontroll två: en VPC-ansluten tjänst som ElastiCache
Cacheminnen av det slaget adresseras inne i din egen VPC och har ingen internetvänd lyssnare alls. En klient-VPN som slutar i samma VPC kan nå dem, men bara när tre villkor sammanfaller. Cacheminnets slutpunkt måste vara kopplad till subnät som din tunnel ser, dess säkerhetsgrupp måste tillåta adressen som dina klienter kommer från, och klientsidan behöver en rutt som täcker cachens subnät.
Det vanliga misstaget är att anta att en anslutning någonstans i närheten räknas. Att koppla VPN:en till en annan VPC, eller att luta sig enbart mot peering, utökar inte cachens säkerhetsgrupp eller dess subnäts ruttabell till dina klienter. När den befintliga tunneln slutar någon annanstans är en jump host eller en VPN-server placerad inne i den VPC:n den vanliga reservlösningen. Den reservlösningen är en kringgång och inte en design, och den bör märkas som sådan i runbooken.
Kontroll tre: en PaaS-slutpunkt med offentligt namn
Azure Database for PostgreSQL presenterar ett offentligt servernamn. Det ger dig ingen privat adress som du kan fästa i en hosts-fil och rutta genom en gateway. Tjänsteslutpunkter för virtuella nätverk begränsar vilka subnät som får nå en resurs; de auktoriserar inte en lokal klient som kommer över en VPN.
Att få privat åtkomst innebär att införa en privat slutpunkt eller en design för privat länk och sedan lägga till en privat DNS-zon så att det offentliga namnet svarar med den slutpunkten i stället för med internet. En VPN kombinerad med en tjänsteslutpunktsregel är en annan arkitektur som bara ser likadan ut i ett diagram. App Service följer samma logik från motsatt håll: VNet-integrering låter appen göra utgående anrop in i ett VNet, och den skapar inte en inkommande privat väg från din tunnel. Inkommande privat åtkomst kräver därför en privat slutpunkt, en App Service Environment eller en gateway framför appen, och vilka av dem du kan använda beror på planen.
Kontroll fyra: produkter med egen ytterdörr
Firebase Hosting kan inte kopplas till en Cloud VPN, eftersom hostinglagret är en global front och inte något inne i ett projekts VPC. Det dokumenterade alternativet är att bygga den kontrollerade ingången själv, med en proxyinstans eller en lastbalanserare som stöds av en hink. Hur som helst slutar webbplatsen vara en ren hostingprodukt och blir infrastruktur som du nu driftar. Den byteshandeln är värd att namnge innan någon lovar att tunneln kommer att täcka den.
Private API Gateway ligger närmare VPC-tjänstesidan: en interface-VPC-slutpunkt publicerar ett värdnamn vars svar är privata adresser, och trafik från dina lokaler kommer över tunneln eller en dedikerad sammankoppling. Slutpunkten måste vara kopplad till API:et, och certifikatet plus värdnamnet måste matcha den anpassade domän som anroparen använder.
Google Cloud VPN-tunnlar binder till peer-IP-adresser, inte till namn. DNS-vidarebefordran konfigureras separat, och därför kan en tunnel vara helt frisk medan uppslag i den avlägsna privata zonen fortfarande misslyckas.
Lokalisera sedan gränsen
Kör samma anslutning från en VM inne i VPC:n. När den lyckas där och misslyckas från VPN-klienten ligger gapet mellan klientens väg och tjänstens slutpunkt: en rutt, en säkerhetsgrupp, en slutpunktsprincip eller ett namn. När båda försöken misslyckas kan ingenting i det nätverket nå tjänsten, och VPN:en var aldrig hindret.
getent hosts db.internal.example
nc -vz db.internal.example 5432Gör namnuppslaget och portkontrollen var för sig, eftersom de misslyckas av olika skäl och paret berättar vilken halva av vägen som är bruten. Ett namn som löses till en offentlig adress berättar att den privata DNS-zonen inte är i spel.