VPN-ul către VPC funcționează, dar serviciul gestionat expiră
Tunelul se termină la marginea dumneavoastră, nu la ușa de intrare a furnizorului. Clasificați ținta ca găzduită pe VM, conectată la VPC sau doar publică înainte de a schimba o rută.
Atingerea unei baze de date gestionate prin VPN eșuează de obicei dintr-un motiv pe care nimeni nu l-a scris în runbook: tunelul se termină la marginea rețelei dumneavoastră, iar serviciul nu a fost niciodată de partea dumneavoastră a acesteia. Tabelul de rute pare corect, tunelul raportează că este activ, iar conexiunea tot expiră. Parcurgeți cele patru verificări de mai jos în ordine și opriți-vă la prima a cărei condiție de succes nu este îndeplinită, pentru că fiecare verificare ulterioară presupune că precedentele au trecut.
Prima verificare: unde trăiește de fapt punctul final?
Un gateway VPN unește două rețele a căror adresare o controlați dumneavoastră. Un serviciu gestionat rulează în spatele propriei uși de intrare a furnizorului, iar acea ușă ia una dintre trei forme în funcție de produs. Dacă nu știți cu ce formă aveți de-a face, nicio muncă la rute nu va ajuta, pentru că defecțiunea poate să nu fie deloc o defecțiune de rutare.
| 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 |
Majoritatea după-amiezelor pierdute provin din omiterea acestei clasificări și din mersul direct la tabelul de rute. Un serviciu găzduit la furnizor cu un punct final public nu este în spatele tunelului dumneavoastră orice ar spune diagrama, iar unul conectat la VPC nu va apărea niciodată într-un răspuns DNS public.
A doua verificare: un serviciu conectat la VPC precum ElastiCache
Cache-urile de acel tip sunt adresate în interiorul propriului VPC și nu au niciun ascultător orientat spre internet. Un VPN de client terminat în același VPC le poate atinge, dar numai când trei condiții coincid. Punctul final al cache-ului trebuie să fie asociat cu subrețele pe care tunelul dumneavoastră le vede, grupul său de securitate trebuie să permită adresa de la care vin clienții dumneavoastră, iar partea client are nevoie de o rută care acoperă subrețelele cache-ului.
Greșeala obișnuită este să presupuneți că o conexiune undeva în apropiere contează. Conectarea VPN-ului la alt VPC sau bazarea doar pe peering nu extinde grupul de securitate al cache-ului sau tabelul de rute al subrețelei lui la clienții dumneavoastră. Când tunelul existent se termină în altă parte, un jump host sau un server VPN plasat în acel VPC este alternativa obișnuită. Acea alternativă este o ocolire și nu un proiect, și ar trebui marcată ca atare în runbook.
A treia verificare: un punct final PaaS cu nume public
Azure Database for PostgreSQL prezintă un nume de server public. Nu vă oferă o adresă privată pe care să o fixați într-un fișier hosts și să o rutati printr-un gateway. Punctele finale de serviciu ale rețelei virtuale limitează ce subrețele pot atinge o resursă; ele nu autorizează un client local care sosește printr-un VPN.
Obținerea accesului privat înseamnă introducerea unui punct final privat sau a unui proiect de legătură privată și apoi adăugarea unei zone DNS private pentru ca numele public să răspundă cu acel punct final în locul internetului. Un VPN combinat cu o regulă de punct final de serviciu este altă arhitectură care arată la fel doar într-o diagramă. App Service urmează aceeași logică din direcția opusă: integrarea cu VNet permite aplicației să facă apeluri de ieșire într-un VNet și nu creează o cale privată de intrare din tunelul dumneavoastră. Accesul privat de intrare necesită deci un punct final privat, un mediu App Service sau un gateway în fața aplicației, iar care dintre ele poate fi folosit depinde de plan.
A patra verificare: produse cu propria ușă de intrare
Firebase Hosting nu poate fi conectat la un Cloud VPN, pentru că stratul de găzduire este un front global și nu ceva din interiorul VPC-ului unui proiect. Alternativa documentată este să construiți singur punctul de intrare controlat, cu o instanță proxy sau un balanceator de încărcare susținut de un bucket. În orice caz site-ul încetează să fie un produs pur de găzduire și devine infrastructură pe care o operați acum. Acel schimb merită numit înainte ca cineva să promită că tunelul îl va acoperi.
Private API Gateway stă mai aproape de partea serviciilor VPC: un punct final VPC de tip interface publică un nume de gazdă ale cărui răspunsuri sunt adrese private, iar traficul din sediul dumneavoastră sosește prin tunel sau printr-o interconectare dedicată. Punctul final trebuie să fie asociat cu API-ul, iar certificatul împreună cu numele de gazdă trebuie să corespundă domeniului personalizat folosit de cei care apelează.
Tunelurile Google Cloud VPN se leagă de adrese IP de parteneri, nu de nume. Redirecționarea DNS se configurează separat, motiv pentru care un tunel poate fi perfect sănătos în timp ce căutările în zona privată îndepărtată încă eșuează.
Apoi localizați granița
Rulați aceeași conexiune de pe o VM din interiorul VPC-ului. Când reușește acolo și eșuează de pe clientul VPN, decalajul se află între calea clientului și punctul final al serviciului: o rută, un grup de securitate, o politică de punct final sau un nume. Când ambele încercări eșuează, nimic din acea rețea nu poate atinge serviciul, iar VPN-ul nu a fost niciodată obstacolul.
getent hosts db.internal.example
nc -vz db.internal.example 5432Faceți căutarea numelui și verificarea portului separat, pentru că eșuează din motive diferite, iar perechea vă spune care jumătate a căii este ruptă. Un nume care se rezolvă la o adresă publică vă spune că zona DNS privată nu este în joc.