VPN do VPC funguje, ale spravované službě vyprší časový limit

Přístup ke spravované databázi přes VPN obvykle selhává z důvodu, který nikdo nezapsal do runbooku: tunel končí na hraně vaší sítě, zatímco služba nikdy nebyla na vaší straně. Směrovací tabulka vypadá správně, tunel hlásí, že je vzhůru, a spojení přesto vyprší. Projděte čtyři níže uvedené kontroly popořadě a zastavte se u první, jejíž podmínka úspěchu neplatí, protože každá další kontrola předpokládá, že předchozí prošly.

Kontrola první: kde koncový bod vlastně žije?

Brána VPN spojuje dvě sítě, jejichž adresaci ovládáte vy. Spravovaná služba běží za vlastními vstupními dveřmi poskytovatele a tyto dveře mají v závislosti na produktu jeden ze tří tvarů. Pokud nevíte, se kterým tvarem máte co do činění, žádná práce se směrováním nepomůže, protože selhání nemusí být selháním směrování.

Většina promarněných odpolední vzniká tím, že se tato klasifikace přeskočí a jde se rovnou k směrovací tabulce. Služba hostovaná u poskytovatele s veřejným koncovým bodem není za vaším tunelem, ať diagram říká cokoli, a služba připojená k VPC se nikdy neobjeví ve veřejné odpovědi DNS.

Kontrola druhá: služba připojená k VPC, například ElastiCache

Cache tohoto druhu se adresují uvnitř vašeho vlastního VPC a nemají vůbec žádný posluchač obrácený do internetu. Klientská VPN ukončená ve stejném VPC se k nim dostane, ale jen když se sejdou tři podmínky. Koncový bod cache musí být přidružen k podsítím, které váš tunel vidí, jeho bezpečnostní skupina musí povolit adresu, ze které přicházejí vaši klienti, a na straně klienta je potřeba trasa, která pokrývá podsítě cache.

Častou chybou je předpokládat, že se spojení někde poblíž počítá. Připojení VPN k jinému VPC nebo spoléhání jen na peering nerozšíří bezpečnostní skupinu cache ani směrovací tabulku její podsítě na vaše klienty. Když stávající tunel končí jinde, obvyklou náhradou je jump host nebo server VPN umístěný uvnitř onoho VPC. Taková náhrada je obchvat, nikoli návrh, a v runbooku to tak má být označeno.

Kontrola třetí: koncový bod PaaS s veřejným jménem

Azure Database for PostgreSQL nabízí veřejné jméno serveru. Nedává vám privátní adresu, kterou byste mohli připnout do souboru hosts a směrovat přes bránu. Koncové body služby virtuální sítě omezují, které podsítě mohou dosáhnout na prostředek; neopravňují místního klienta, který přichází přes VPN.

Získání privátního přístupu znamená zavést privátní koncový bod nebo návrh privátního propojení a poté přidat privátní zónu DNS, aby veřejné jméno odpovídalo tímto koncovým bodem místo internetu. VPN v kombinaci s pravidlem koncového bodu služby je jiná architektura, která vypadá stejně jen v diagramu. App Service sleduje stejnou logiku z opačného směru: integrace s VNet umožňuje aplikaci odchozí volání do VNet a nevytváří příchozí privátní cestu z vašeho tunelu. Příchozí privátní přístup proto vyžaduje privátní koncový bod, prostředí App Service nebo bránu před aplikací, a které z toho můžete použít, závisí na plánu.

Kontrola čtvrtá: produkty s vlastními vstupními dveřmi

Firebase Hosting nelze připojit k Cloud VPN, protože vrstva hostingu je globální fronta, nikoli něco uvnitř VPC projektu. Dokumentovanou alternativou je postavit řízený vstupní bod sami, pomocí proxy instance nebo nástroje pro vyrovnávání zátěže podepřeného bucketem. V obou případech web přestává být čistě hostingovým produktem a stává se infrastrukturou, kterou nyní provozujete vy. Tuto výměnu stojí za to pojmenovat dřív, než někdo slíbí, že ji tunel pokryje.

Private API Gateway stojí blíže straně služeb VPC: koncový bod VPC typu interface zveřejňuje jméno hostitele, jehož odpovědi jsou privátní adresy, a provoz z vašich prostor přichází přes tunel nebo vyhrazený propoj. Koncový bod musí být přidružen k API a certifikát spolu se jménem hostitele musí odpovídat vlastní doméně, kterou volající používají.

Tunely Google Cloud VPN se vážou na IP adresy protějšků, nikoli na jména. Předávání DNS se konfiguruje zvlášť, a proto může být tunel naprosto zdravý, zatímco vyhledávání ve vzdálené privátní zóně stále selhává.

Poté najděte hranici

Spusťte stejné spojení z VM uvnitř VPC. Když tam uspěje a z klienta VPN selže, mezera je mezi cestou klienta a koncovým bodem služby: trasa, bezpečnostní skupina, zásada koncového bodu nebo jméno. Když selžou oba pokusy, nic v této síti na službu nedosáhne a VPN nikdy nebyla překážkou.

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

Provádějte vyhledání jména a kontrolu portu odděleně, protože selhávají z různých důvodů a tato dvojice vám řekne, která polovina cesty je rozbitá. Jméno, které se přeloží na veřejnou adresu, vám říká, že privátní zóna DNS není ve hře.