VPN na die VPC werk, maar die bestuurde diens verstek
Die tonnel eindig by jou rand, nie by die verskaffer se voordeur nie. Klassifiseer die teiken as VM-gehuis, VPC-gekoppel of slegs-openbaar voordat jy 'n roete verander.
Om 'n bestuurde databasis deur 'n VPN te bereik, misluk gewoonlik om 'n rede wat niemand in die runbook neergeskryf het nie: die tonnel eindig by jou netwerkrand, terwyl die diens nooit aan jou kant daarvan gesit het nie. Die roetetabel lyk korrek, die tonnel rapporteer op, en die verbinding verstek nietemin. Werk die vier kontroles hieronder in volgorde deur en stop by die eerste een waarvan die slaagvoorwaarde onwaar is, want elke kontrole daarna neem aan dat die voriges geslaag het.
Kontrole een: waar leef die eindpunt werklik?
'n VPN-hek verbind twee netwerke waarvan jy die adressering beheer. 'n Bestuurde diens word agter die verskaffer se eie voordeur bedryf, en daardie deur het een van drie vorms, afhangend van die produk. As jy nie weet watter vorm jy voor het nie, sal geen hoeveelheid roetewerk help nie, want die fout is dalk glad nie 'n roetefout nie.
| 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 |
Die meeste vermorste middae kom daarvan dat hierdie klassifikasie oorgeslaan word en reguit na die roetetabel gegaan word. 'n Verskaffer-gehuisde diens met 'n openbare eindpunt is nie agter jou tonnel nie, maak nie saak wat die diagram sê nie, en 'n VPC-gekoppelde een sal nooit in 'n openbare DNS-antwoord opduik nie.
Kontrole twee: 'n VPC-gekoppelde diens soos ElastiCache
Kassies van daardie aard word binne jou eie VPC geadresseer en het glad geen luisteraar wat na die internet wys nie. 'n Kliënt-VPN wat in dieselfde VPC eindig, kan hulle bereik, maar net wanneer drie voorwaardes saamval. Die kas-eindpunt moet aan subnette gekoppel wees wat jou tonnel kan sien, sy sekuriteitsgroep moet die adres toelaat waarvan jou kliënte aankom, en die kliëntkant het 'n roete nodig wat die kas-subnette dek.
Die algemene fout is om te aanvaar dat 'n verbinding iewers naby meetel. Om die VPN aan 'n ander VPC te koppel, of om alleen op peering te steun, brei nie die kas se sekuriteitsgroep of sy subnet-roetetabel na jou kliënte uit nie. Wanneer die bestaande tonnel elders eindig, is 'n spronggasheer of 'n VPN-bediener binne daardie VPC die gewone terugval. Daardie terugval is 'n noodoplossing eerder as 'n ontwerp, en dit behoort as sodanig in die runbook gemerk te word.
Kontrole drie: 'n PaaS-eindpunt met 'n openbare naam
Azure Database for PostgreSQL bied 'n openbare bedienernaam aan. Dit gee jou nie 'n private adres wat jy in 'n hosts-lêer kan vaspen en deur 'n hek kan roeteer nie. Virtuele-netwerkdiens-eindpunte beperk watter subnette 'n hulpbron mag bereik; hulle magtig nie 'n plaaslike kliënt wat oor 'n VPN arriveer nie.
Om private toegang te kry, beteken om 'n private eindpunt of 'n private-skakel-ontwerp in te bring en dan 'n private DNS-sone by te voeg sodat die openbare naam met daardie eindpunt antwoord in plaas van met die internet. 'n VPN gekombineer met 'n diens-eindpuntreël is 'n ander argitektuur wat net in 'n diagram soos dieselfde lyk. App Service volg dieselfde logika uit die ander rigting: VNet-integrasie laat die app uitgaande oproepe in 'n VNet maak, en dit skep nie 'n inkomende private pad vanaf jou tonnel nie. Inkomende private toegang vereis dus 'n private eindpunt, 'n App Service Environment of 'n hek voor die app, en watter van dié jy kan gebruik, hang van die plan af.
Kontrole vier: produkte met hul eie voordeur
Firebase Hosting kan nie aan 'n Cloud VPN gekoppel word nie, want die hosting-laag is 'n globale frontend eerder as iets binne 'n projek-VPC. Die gedokumenteerde alternatief is om die beheerde toegangspunt self te bou, met 'n proxie-instansie of 'n lasbalanseerder wat deur 'n emmer gerugsteun word. In elk geval hou die werf op om 'n suiwer hostingproduk te wees en word dit infrastruktuur wat jy nou bedryf. Daardie ruil is die moeite werd om te benoem voordat iemand belowe dat die tonnel dit sal dek.
Private API Gateway sit nader aan die VPC-dienskant: 'n koppelvlak-VPC-eindpunt publiseer 'n gasheernaam waarvan die antwoorde private adresse is, en verkeer vanaf jou perseel arriveer oor die tonnel of 'n toegewyde interkonneksie. Die eindpunt moet aan die API gekoppel wees, en die sertifikaat plus gasheernaam moet by die pasgemaakte domein pas wat oproepers gebruik.
Google Cloud VPN-tonnels bind aan eweknie-IP-adresse, nie aan name nie. DNS-aanstuur word afsonderlik opgestel, en daarom kan 'n tonnel heeltemal gesond wees terwyl opsoeke in die afgeleë private sone steeds misluk.
Bepaal dan waar die grens lê
Voer dieselfde verbinding uit vanaf 'n VM binne die VPC. Wanneer dit daar slaag en vanaf die VPN-kliënt misluk, lê die gaping tussen die kliëntpad en die diens-eindpunt: 'n roete, 'n sekuriteitsgroep, 'n eindpuntbeleid of 'n naam. Wanneer albei pogings misluk, kan niks in daardie netwerk die diens bereik nie, en was die VPN nooit die hindernis nie.
getent hosts db.internal.example
nc -vz db.internal.example 5432Doen die naamopsoek en die poortkontrole afsonderlik, want hulle misluk om verskillende redes en die paar vertel jou watter helfte van die pad gebreek is. 'n Naam wat na 'n openbare adres oplos, sê vir jou die private DNS-sone is nie in werking nie.