El VPN al VPC funciona, però el servei gestionat esgota el temps
El túnel acaba a la vostra vora, no a la porta d'entrada del proveïdor. Classifiqueu l'objectiu com a allotjat en VM, connectat al VPC o només públic abans de canviar cap ruta.
Arribar a una base de dades gestionada a través d'un VPN sol fallar per un motiu que ningú no va escriure al manual: el túnel acaba a la vora de la vostra xarxa, mentre que el servei mai no ha estat al vostre costat. La taula de rutes sembla correcta, el túnel informa que està actiu i la connexió s'esgota igualment. Feu les quatre comprovacions següents en ordre i atureu-vos a la primera que no compleixi la condició d'èxit, perquè cada comprovació posterior assumeix que les anteriors s'han complert.
Comprovació primera: on viu realment el punt de connexió?
Una passarel·la VPN uneix dues xarxes l'adreçament de les quals controleu vosaltres. Un servei gestionat s'opera darrere la porta d'entrada pròpia del proveïdor, i aquesta porta adopta una de tres formes segons el producte. Si no sabeu amb quina forma tracteu, cap feina de rutes no us ajudarà, perquè la fallada pot no ser una fallada d'encaminament.
| 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 |
La major part de tardes perdudes vénen de saltar-se aquesta classificació i anar directament a la taula de rutes. Un servei allotjat al proveïdor amb punt de connexió públic no és darrere el vostre túnel digui el que digui el diagrama, i un de connectat al VPC no apareixerà mai en una resposta DNS pública.
Comprovació segona: un servei connectat al VPC com ElastiCache
Les memòries cau d'aquest tipus s'adrecen dins del vostre propi VPC i no tenen cap oient orientat a internet. Un VPN de client acabat en aquest mateix VPC hi pot arribar, però només quan coincideixen tres condicions. El punt de connexió de la memòria cau ha d'estar associat a subxarxes que el vostre túnel pugui veure, el seu grup de seguretat ha de permetre l'adreça d'on arriben els vostres clients, i el costat client necessita una ruta que cobreixi les subxarxes de la memòria cau.
L'error habitual és suposar que una connexió en algun lloc proper compta. Connectar el VPN a un altre VPC, o confiar només en l'emparellament, no estén el grup de seguretat de la memòria cau ni la taula de rutes de la seva subxarxa als vostres clients. Quan el túnel existent acaba en un altre lloc, un host de salt o un servidor VPN col·locat dins d'aquell VPC és l'alternativa habitual. Aquesta alternativa és una solució provisional i no un disseny, i cal etiquetar-la com a tal al manual.
Comprovació tercera: un punt de connexió PaaS amb nom públic
Azure Database for PostgreSQL presenta un nom de servidor públic. No us lliura una adreça privada que pugueu fixar en un fitxer hosts i encaminar per una passarel·la. Els punts de connexió de servei de xarxa virtual limiten quines subxarxes poden arribar a un recurs; no autoritzen un client local que arriba per un VPN.
Obtenir accés privat vol dir introduir un punt de connexió privat o un disseny d'enllaç privat, i després afegir una zona DNS privada perquè el nom públic respongui amb aquest punt de connexió en lloc d'internet. Un VPN combinat amb una regla de punt de connexió de servei és una arquitectura diferent que només sembla igual en un diagrama. App Service segueix la mateixa lògica des de l'altra direcció: la integració amb VNet permet a l'aplicació fer crides sortints cap a un VNet i no crea cap camí privat entrant des del vostre túnel. L'accés privat entrant requereix, per tant, un punt de connexió privat, un App Service Environment o una passarel·la davant l'aplicació, i quin d'aquests podeu fer servir depèn del pla.
Comprovació quarta: productes amb porta d'entrada pròpia
Firebase Hosting no es pot connectar a un Cloud VPN, perquè el nivell d'allotjament és un frontal global i no una cosa dins del VPC d'un projecte. L'alternativa documentada és construir el punt d'entrada controlat vosaltres mateixos, amb una instància de proxy o un balancejador de càrrega recolzat en un contenidor. En qualsevol cas el lloc deixa de ser un producte d'allotjament pur i es converteix en infraestructura que ara gestioneu vosaltres. Val la pena anomenar aquest intercanvi abans que algú prometi que el túnel el cobrirà.
Private API Gateway és més a prop del costat dels serveis de VPC: un punt de connexió VPC d'interfície publica un nom d'amfitrió les respostes del qual són adreces privades, i el trànsit de les vostres instal·lacions arriba pel túnel o per una interconnexió dedicada. El punt de connexió ha d'estar associat a l'API, i el certificat i el nom d'amfitrió han de coincidir amb el domini personalitzat que fan servir els qui hi criden.
Els túnels de Google Cloud VPN s'enllacen a adreces IP de parells, no a noms. El reenviament de DNS es configura a part, i per això un túnel pot estar perfectament sa mentre les consultes a la zona privada remota encara fallen.
Després localitzeu la frontera
Executeu la mateixa connexió des d'una VM dins del VPC. Quan allà funciona i falla des del client VPN, el buit és entre el camí del client i el punt de connexió del servei: una ruta, un grup de seguretat, una política de punt de connexió o un nom. Quan fallen tots dos intents, res d'aquella xarxa no pot arribar al servei, i el VPN no era mai l'obstacle.
getent hosts db.internal.example
nc -vz db.internal.example 5432Feu la consulta de nom i la comprovació de port per separat, perquè fallen per motius diferents i la parella us diu quina meitat del camí està trencada. Un nom que es resol a una adreça pública us diu que la zona DNS privada no hi és present.