VPN do VPC funguje, ale spravovanej službe vyprší časový limit
Tunel sa končí na vašej hrane, nie pri vstupných dverách poskytovateľa. Pred zmenou trasy klasifikujte cieľ ako hostovaný na VM, pripojený k VPC alebo iba verejný.
Prístup k spravovanej databáze cez VPN zvyčajne zlyháva z dôvodu, ktorý nikto nezapísal do runbooku: tunel sa končí na hrane vašej siete, zatiaľ čo služba nikdy nebola na vašej strane tejto hrany. Smerovacia tabuľka vyzerá správne, tunel hlási, že je aktívny, a spojenie napriek tomu vyprší. Prejdite štyri kontroly nižšie v poradí a zastavte sa pri prvej, ktorej podmienka úspechu neplatí, pretože každá ďalšia kontrola predpokladá, že predchádzajúce prešli.
Kontrola prvá: kde koncový bod vlastne žije?
Brána VPN spája dve siete, ktorých adresáciu ovládate vy. Spravovaná služba beží za vlastnými vstupnými dverami poskytovateľa a tie dvere majú v závislosti od produktu jeden z troch tvarov. Ak neviete, s ktorým tvarom máte do činenia, žiadna práca so smerovaním nepomôže, pretože porucha nemusí byť poruchou smerovania.
| 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 |
Väčšina premárnených popoludní vzniká tým, že sa táto klasifikácia preskočí a ide sa rovno k smerovacej tabuľke. Služba hostovaná u poskytovateľa s verejným koncovým bodom nie je za vaším tunelom, nech diagram hovorí čokoľvek, a služba pripojená k VPC sa nikdy neobjaví vo verejnej odpovedi DNS.
Kontrola druhá: služba pripojená k VPC, napríklad ElastiCache
Cache tohto druhu sa adresujú vnútri vášho vlastného VPC a nemajú vôbec žiadneho poslucháča obráteného do internetu. Klientska VPN ukončená v tom istom VPC sa k nim dostane, ale len keď sa zhodujú tri podmienky. Koncový bod cache musí byť priradený podsietiam, ktoré váš tunel vidí, jeho bezpečnostná skupina musí povoliť adresu, z ktorej prichádzajú vaši klienti, a na strane klienta je potrebná trasa, ktorá pokrýva podsiete cache.
Častou chybou je predpokladať, že sa počíta spojenie niekde neďaleko. Pripojenie VPN k inému VPC alebo spoliehanie sa iba na peering nerozšíri bezpečnostnú skupinu cache ani smerovaciu tabuľku jej podsiete na vašich klientov. Keď sa existujúci tunel končí inde, zvyčajnou náhradou je jump host alebo server VPN umiestnený vnútri toho VPC. Taká náhrada je obchádzka, nie návrh, a v runbooku by mala byť tak označená.
Kontrola tretia: koncový bod PaaS s verejným menom
Azure Database for PostgreSQL prezentuje verejné meno servera. Nedáva vám privátnu adresu, ktorú by ste mohli pripnúť do súboru hosts a smerovať cez bránu. Koncové body služby virtuálnej siete obmedzujú, ktoré podsiete môžu dosiahnuť prostriedok; neoprávňujú lokálneho klienta, ktorý prichádza cez VPN.
Získanie privátneho prístupu znamená zaviesť privátny koncový bod alebo návrh privátneho prepojenia a potom pridať privátnu zónu DNS, aby verejné meno odpovedalo týmto koncovým bodom namiesto internetu. VPN v kombinácii s pravidlom koncového bodu služby je iná architektúra, ktorá vyzerá rovnako iba na diagrame. App Service nasleduje rovnakú logiku z opačného smeru: integrácia s VNet umožňuje aplikácii odchádzajúce volania do VNet a nevytvára prichádzajúcu privátnu cestu z vášho tunela. Prichádzajúci privátny prístup preto vyžaduje privátny koncový bod, prostredie App Service alebo bránu pred aplikáciou, a ktoré z toho môžete použiť, závisí od plánu.
Kontrola štvrtá: produkty s vlastnými vstupnými dverami
Firebase Hosting nie je možné pripojiť k Cloud VPN, pretože vrstva hostingu je globálny front a nie niečo vnútri VPC projektu. Dokumentovanou alternatívou je postaviť kontrolovaný vstupný bod sami, s inštanciou proxy alebo nástrojom na vyrovnávanie zaťaženia podopretým bucketom. V každom prípade stránka prestáva byť čistým hostingovým produktom a stáva sa infraštruktúrou, ktorú teraz prevádzkujete vy. Túto výmenu stojí za to pomenovať skôr, než niekto sľúbi, že ju tunel pokryje.
Private API Gateway stojí bližšie strane služieb VPC: koncový bod VPC typu interface zverejňuje meno hostiteľa, ktorého odpovede sú privátne adresy, a prevádzka z vašich priestorov prichádza cez tunel alebo vyhradené prepojenie. Koncový bod musí byť priradený k API a certifikát spolu s menom hostiteľa musia zodpovedať vlastnej doméne, ktorú používajú volajúci.
Tunely Google Cloud VPN sa viažu na IP adresy protistrany, nie na mená. Preposielanie DNS sa konfiguruje samostatne, a preto môže byť tunel úplne zdravý, zatiaľ čo vyhľadávanie vo vzdialenej privátnej zóne stále zlyháva.
Potom nájdite hranicu
Spustite to isté spojenie z VM vnútri VPC. Keď tam uspeje a z klienta VPN zlyhá, medzera je medzi cestou klienta a koncovým bodom služby: trasa, bezpečnostná skupina, pravidlo koncového bodu alebo meno. Keď zlyhajú oba pokusy, nič v tej sieti sa k službe nedostane a VPN nikdy nebol prekážkou.
getent hosts db.internal.example
nc -vz db.internal.example 5432Vyhľadanie mena a kontrolu portu robte oddelene, pretože zlyhávajú z rôznych dôvodov a dvojica vám povie, ktorá polovica cesty je pokazená. Meno, ktoré sa preloží na verejnú adresu, vám hovorí, že privátna zóna DNS nie je v hre.