VPN do VPC działa, ale usługa zarządzana kończy się przekroczeniem czasu
Tunel kończy się na Twojej krawędzi, a nie przy drzwiach wejściowych dostawcy. Zanim zmienisz trasę, zaklasyfikuj cel jako hostowany na VM, podłączony do VPC lub tylko publiczny.
Dostęp do zarządzanej bazy danych przez VPN zwykle zawodzi z powodu, którego nikt nie zapisał w runbooku: tunel kończy się na krawędzi Twojej sieci, a usługa nigdy nie była po Twojej stronie tej krawędzi. Tabela tras wygląda poprawnie, tunel zgłasza, że działa, a połączenie i tak kończy się przekroczeniem czasu. Przejdź przez cztery kontrole poniżej w kolejności i zatrzymaj się na pierwszej, której warunek powodzenia nie jest spełniony, ponieważ każda kolejna kontrola zakłada, że poprzednie przeszły.
Kontrola pierwsza: gdzie naprawdę mieszka punkt końcowy?
Brama VPN łączy dwie sieci, których adresacją zarządzasz. Usługa zarządzana działa za własnymi drzwiami wejściowymi dostawcy, a te drzwi przyjmują jeden z trzech kształtów w zależności od produktu. Jeśli nie wiesz, z jakim kształtem masz do czynienia, żadna praca nad trasami nie pomoże, ponieważ awaria może wcale nie być awarią trasy.
| 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 |
Większość zmarnowanych popołudni bierze się z pominięcia tej klasyfikacji i pójścia prosto do tabeli tras. Usługa hostowana u dostawcy z publicznym punktem końcowym nie jest za Twoim tunelem, cokolwiek mówi diagram, a podłączona do VPC nigdy nie pojawi się w publicznej odpowiedzi DNS.
Kontrola druga: usługa podłączona do VPC, taka jak ElastiCache
Pamięci podręczne tego typu są adresowane wewnątrz Twojego VPC i nie mają żadnego nasłuchu skierowanego do internetu. Kliencki VPN kończący się w tym samym VPC może do nich dotrzeć, ale tylko gdy zbiegną się trzy warunki. Punkt końcowy pamięci podręcznej musi być powiązany z podsieciami, które widzi Twój tunel, jego grupa zabezpieczeń musi zezwalać na adres, z którego przychodzą Twoi klienci, a strona klienta potrzebuje trasy obejmującej podsieci pamięci podręcznej.
Częstym błędem jest zakładanie, że połączenie gdzieś w pobliżu się liczy. Podłączenie VPN do innego VPC lub poleganie wyłącznie na peeringu nie rozszerza grupy zabezpieczeń pamięci podręcznej ani tabeli tras jej podsieci na Twoich klientów. Gdy istniejący tunel kończy się gdzie indziej, zwykłym obejściem jest host skoku lub serwer VPN umieszczony w tym VPC. Takie obejście jest obejściem, a nie projektem, i w runbooku powinno być tak oznaczone.
Kontrola trzecia: punkt końcowy PaaS z publiczną nazwą
Azure Database for PostgreSQL przedstawia publiczną nazwę serwera. Nie daje Ci prywatnego adresu, który mógłbyś przypiąć w pliku hosts i skierować przez bramę. Punkty końcowe usługi sieci wirtualnej ograniczają, które podsieci mogą dotrzeć do zasobu; nie upoważniają lokalnego klienta, który przychodzi przez VPN.
Uzyskanie prywatnego dostępu oznacza wprowadzenie prywatnego punktu końcowego lub projektu prywatnego łącza, a następnie dodanie prywatnej strefy DNS, aby publiczna nazwa odpowiadała tym punktem końcowym zamiast internetem. VPN w połączeniu z regułą punktu końcowego usługi to inna architektura, która tylko na diagramie wygląda podobnie. App Service podąża tą samą logiką z przeciwnego kierunku: integracja z VNet pozwala aplikacji wykonywać połączenia wychodzące do VNet i nie tworzy przychodzącej prywatnej ścieżki z Twojego tunelu. Przychodzący prywatny dostęp wymaga więc prywatnego punktu końcowego, środowiska App Service lub bramy przed aplikacją, a to, którego z nich możesz użyć, zależy od planu.
Kontrola czwarta: produkty z własnymi drzwiami wejściowymi
Firebase Hosting nie można podłączyć do Cloud VPN, ponieważ warstwa hostingu jest globalnym frontem, a nie czymś wewnątrz VPC projektu. Udokumentowaną alternatywą jest samodzielne zbudowanie kontrolowanego punktu wejścia, z instancją proxy lub równoważnikiem obciążenia opartym na zasobniku. Tak czy inaczej witryna przestaje być czystym produktem hostingowym i staje się infrastrukturą, którą teraz obsługujesz. Warto nazwać tę wymianę, zanim ktoś obieca, że tunel ją obejmie.
Private API Gateway stoi bliżej strony usług VPC: punkt końcowy VPC typu interface publikuje nazwę hosta, której odpowiedziami są prywatne adresy, a ruch z Twojej siedziby przychodzi przez tunel lub dedykowane połączenie. Punkt końcowy musi być powiązany z API, a certyfikat wraz z nazwą hosta muszą odpowiadać domenie niestandardowej używanej przez wywołujących.
Tunele Google Cloud VPN wiążą się z adresami IP partnerów, a nie z nazwami. Przekazywanie DNS konfiguruje się osobno, dlatego tunel może być całkowicie zdrowy, podczas gdy wyszukiwania w zdalnej strefie prywatnej nadal zawodzą.
Następnie zlokalizuj granicę
Uruchom to samo połączenie z VM wewnątrz VPC. Gdy tam się udaje, a z klienta VPN zawodzi, luka leży między ścieżką klienta a punktem końcowym usługi: trasa, grupa zabezpieczeń, polityka punktu końcowego lub nazwa. Gdy obie próby zawodzą, nic w tej sieci nie może dotrzeć do usługi, a VPN nigdy nie był przeszkodą.
getent hosts db.internal.example
nc -vz db.internal.example 5432Wykonaj wyszukiwanie nazwy i sprawdzenie portu osobno, ponieważ zawodzą z różnych powodów, a ta para mówi Ci, która połowa ścieżki jest zepsuta. Nazwa, która rozwiązuje się na publiczny adres, mówi Ci, że prywatna strefa DNS nie działa.