VPN кон VPC работи, но управуваната услуга истекува
Тунелот завршува на вашиот раб, а не на влезната врата на добавувачот. Класифицирајте ја целта како хостирана на VM, поврзана со VPC или само јавна пред да смените рута.
Пристапот до управувана база на податоци преку VPN обично не успева поради причина што никој не ја запишал во прирачникот: тунелот завршува на работ на вашата мрежа, а услугата никогаш не била на вашата страна од него. Табелата со рути изгледа точна, тунелот известува дека е активен, а врската сепак истекува. Изведете ги четирите проверки подолу по ред и застанете на првата чиј услов за успех не е исполнет, бидејќи секоја следна проверка претпоставува дека претходните поминале.
Проверка прва: каде навистина живее крајната точка?
VPN порта поврзува две мрежи чие адресирање го контролирате вие. Управуваната услуга работи зад сопствената влезна врата на добавувачот, а таа врата има еден од три облици зависно од производот. Ако не знаете со кој облик имате работа, никаква работа со рути нема да помогне, бидејќи дефектот можеби воопшто не е дефект на рута.
| 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 |
Повеќето потрошени попладниња доаѓаат од прескокнување на оваа класификација и одење директно на табелата со рути. Услуга хостирана кај добавувачот со јавна крајна точка не е зад вашиот тунел што и да каже дијаграмот, а онаа поврзана со VPC никогаш нема да се појави во јавен DNS одговор.
Проверка втора: услуга поврзана со VPC, како ElastiCache
Кешови од тој вид се адресираат внатре во вашиот сопствен VPC и воопшто немаат слушател свртен кон интернет. Клиентски VPN што завршува во истиот VPC може да ги достигне, но само кога три услови се совпаѓаат. Крајната точка на кешот мора да биде поврзана со подмрежи што вашиот тунел ги гледа, неговата безбедносна група мора да ја дозволува адресата од која доаѓаат вашите клиенти, а клиентската страна има потреба од рута што ги покрива подмрежите на кешот.
Вообичаената грешка е да се претпостави дека врска некаде во близина се смета. Поврзувањето на VPN со друг VPC или потпирањето само на peering не ја проширува безбедносната група на кешот или табелата со рути на неговата подмрежа до вашите клиенти. Кога постојниот тунел завршува на друго место, вообичаеното резервно решение е скок-хост или VPN сервер поставен во тој VPC. Таквото резервно решение е заобиколување, а не проект, и во прирачникот треба така да се означи.
Проверка трета: PaaS крајна точка со јавно име
Azure Database for PostgreSQL претставува јавно име на сервер. Тоа не ви дава приватна адреса што можете да ја закачите во hosts датотека и да ја пренасочите преку порта. Крајните точки на услугата за виртуелна мрежа ограничуваат кои подмрежи можат да достигнат ресурс; тие не ја овластуваат локалниот клиент што доаѓа преку VPN.
Добивањето приватен пристап значи воведување приватна крајна точка или проект за приватно поврзување, потоа додавање приватна DNS зона за јавното име да одговара со таа крајна точка наместо со интернет. VPN комбиниран со правило за крајна точка на услуга е друга архитектура што изгледа слично само на дијаграм. App Service ја следи истата логика од другата насока: интеграцијата со VNet му овозможува на прилогот да прави излезни повици во VNet и не создава влезна приватна патека од вашиот тунел. Затоа влезниот приватен пристап бара приватна крајна точка, опкружување App Service или порта пред прилогот, а кое од нив можете да го користите зависи од планот.
Проверка четврта: производи со сопствена влезна врата
Firebase Hosting не може да се поврзе со Cloud VPN, бидејќи слојот за хостирање е глобален преден дел, а не нешто внатре во VPC на проект. Документираната алтернатива е сами да ја изградите контролираната влезна точка, со прокси примерок или балансер на оптоварување поддржан со корпа. Во секој случај страницата престанува да биде чист производ за хостирање и станува инфраструктура што сега ја управувате вие. Таа размена вреди да се именува пред некој да вети дека тунелот ќе ја покрие.
Private API Gateway стои поблизу до страната на VPC услугите: interface тип на VPC крајна точка објавува име на домаќин чии одговори се приватни адреси, а сообраќајот од вашите простории пристигнува преку тунелот или наменски меѓусебен поврзувач. Крајната точка мора да биде поврзана со API, а сертификатот заедно со името на домаќинот мора да одговараат на прилагодениот домен што го користат повикувачите.
Тунелите на Google Cloud VPN се врзуваат за IP адреси на партнери, не за имиња. DNS препраќањето се конфигурира одделно, поради што тунелот може да биде целосно здрав додека пребарувањата во оддалечената приватна зона сѐ уште не успеваат.
Потоа лоцирајте ја границата
Стартувајте ја истата врска од VM внатре во VPC. Кога таму успева, а од VPN клиентот не успева, разликата е помеѓу патеката на клиентот и крајната точка на услугата: рута, безбедносна група, правило за крајна точка или име. Кога не успеваат двата обиди, ништо во таа мрежа не може да ја достигне услугата, и VPN никогаш не бил пречка.
getent hosts db.internal.example
nc -vz db.internal.example 5432Правете го пребарувањето на име и проверката на порта одделно, бидејќи тие не успеваат од различни причини и парот ви кажува која половина од патеката е расипана. Име што се решава на јавна адреса ви кажува дека приватната DNS зона не е во игра.