VPN uz VPC strādā, bet pārvaldītais pakalpojums nokavējas
Tunelis beidzas jūsu malā, nevis piegādātāja priekšējās durvīs. Pirms maršruta maiņas klasificējiet mērķi kā VM mitinātu, VPC piesaistītu vai tikai publisku.
Piekļuve pārvaldītai datubāzei caur VPN parasti neizdodas tāda iemesla dēļ, ko neviens nav ierakstījis rokasgrāmatā: tunelis beidzas jūsu tīkla malā, bet pakalpojums nekad nav bijis tā jūsu pusē. Maršrutu tabula izskatās pareiza, tunelis ziņo, ka darbojas, un savienojums tomēr nokavējas. Veiciet četras pārbaudes zemāk pēc kārtas un apstājieties pie pirmās, kuras izpildes nosacījums nav izpildīts, jo katra nākamā pārbaude pieņem, ka iepriekšējās ir izturētas.
Pirmā pārbaude: kur galapunkts patiešām atrodas?
VPN vārteja savieno divus tīklus, kuru adresāciju kontrolējat jūs. Pārvaldītais pakalpojums darbojas aiz piegādātāja paša priekšējām durvīm, un šīs durvis atkarībā no produkta iegūst vienu no trim formām. Ja nezināt, ar kādu formu jums ir darīšana, nekāds maršrutu darbs nepalīdzēs, jo kļūme var nemaz nebūt maršruta kļūme.
| 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 |
Lielākā daļa izšķērdēto pēcpusdienu rodas, izlaižot šo klasifikāciju un ejot tieši pie maršrutu tabulas. Piegādātāja mitināts pakalpojums ar publisku galapunktu neatrodas aiz jūsu tuneļa, lai ko teiktu diagramma, un VPC piesaistītais nekad neparādīsies publiskā DNS atbildē.
Otrā pārbaude: VPC piesaistīts pakalpojums, piemēram, ElastiCache
Šāda veida kešatmiņas tiek adresētas jūsu pašu VPC iekšienē, un tām vispār nav internetam vērsta klausītāja. Klienta VPN, kas beidzas tajā pašā VPC, var tām piekļūt, bet tikai tad, kad vienlaikus sakrīt trīs nosacījumi. Kešatmiņas galapunktam jābūt saistītam ar apakštīkliem, ko redz jūsu tunelis, tās drošības grupai ir jāatļauj adrese, no kuras nāk jūsu klienti, un klienta pusē nepieciešams maršruts, kas aptver kešatmiņas apakštīklus.
Biežākā kļūda ir pieņemt, ka savienojums kaut kur tuvumā skaitās. VPN pievienošana citam VPC vai paļaušanās tikai uz peering nepaplašina kešatmiņas drošības grupu vai tās apakštīkla maršrutu tabulu līdz jūsu klientiem. Kad esošais tunelis beidzas citur, parastais rezerves risinājums ir lēciena resursdators vai VPN serveris, kas ievietots šajā VPC. Šāds rezerves risinājums ir apļošana, nevis projektējums, un rokasgrāmatā tas tā arī jāatzīmē.
Trešā pārbaude: PaaS galapunkts ar publisku nosaukumu
Azure Database for PostgreSQL piedāvā publisku servera nosaukumu. Tas nedod jums privātu adresi, ko varētu ierakstīt hosts failā un maršrutēt caur vārteju. Virtuālā tīkla pakalpojuma galapunkti ierobežo, kuri apakštīkli var sasniegt resursu; tie nepiešķir atļauju lokālam klientam, kas ierodas caur VPN.
Privātas piekļuves iegūšana nozīmē privāta galapunkta vai privāta savienojuma risinājuma ieviešanu un pēc tam privātas DNS zonas pievienošanu, lai publiskais nosaukums atbildētu ar šo galapunktu, nevis ar internetu. VPN kopā ar pakalpojuma galapunkta kārtulu ir cita arhitektūra, kas vienādi izskatās tikai diagrammā. App Service ievēro to pašu loģiku no pretējā virziena: VNet integrācija ļauj lietotnei veikt izejošos izsaukumus uz VNet, un tā neveido ienākošu privātu ceļu no jūsu tuneļa. Tāpēc ienākošajai privātajai piekļuvei nepieciešams privāts galapunkts, App Service vide vai vārteja lietotnes priekšā, un to, kuru no tiem varat izmantot, nosaka plāns.
Ceturtā pārbaude: produkti ar savām priekšējām durvīm
Firebase Hosting nevar pievienot Cloud VPN, jo mitināšanas slānis ir globāla priekšpuse, nevis kaut kas projekta VPC iekšienē. Dokumentētā alternatīva ir pašiem uzbūvēt kontrolēto ieejas punktu ar starpniekservera instanci vai slodzes līdzsvarotāju, kas balstīts uz kausu. Jebkurā gadījumā vietne pārstāj būt tīrs mitināšanas produkts un kļūst par infrastruktūru, ko tagad pārvaldāt jūs. Šo maiņu ir vērts nosaukt pirms tam, kad kāds sola, ka tunelis to segs.
Private API Gateway atrodas tuvāk VPC pakalpojumu pusei: interface tipa VPC galapunkts publicē resursdatora nosaukumu, kura atbildes ir privātas adreses, un trafiks no jūsu telpām ierodas pa tuneli vai dedikētu savstarpējo savienojumu. Galapunktam jābūt saistītam ar API, un sertifikātam kopā ar resursdatora nosaukumu jāatbilst pielāgotajam domēnam, ko izmanto izsaucēji.
Google Cloud VPN tuneļi saistās ar partnera IP adresēm, nevis nosaukumiem. DNS pārsūtīšana tiek konfigurēta atsevišķi, tāpēc tunelis var būt pilnīgi vesels, kamēr meklēšana attālajā privātajā zonā joprojām neizdodas.
Pēc tam atrodiet robežu
Palaidiet to pašu savienojumu no VM VPC iekšienē. Kad tur tas izdodas, bet no VPN klienta neizdodas, starpība ir starp klienta ceļu un pakalpojuma galapunktu: maršruts, drošības grupa, galapunkta politika vai nosaukums. Kad neizdodas abi mēģinājumi, nekas šajā tīklā nevar sasniegt pakalpojumu, un VPN nekad nav bijis šķērslis.
getent hosts db.internal.example
nc -vz db.internal.example 5432Veiciet nosaukuma meklēšanu un porta pārbaudi atsevišķi, jo tie neizdodas dažādu iemeslu dēļ, un pāris pasaka, kura ceļa puse ir bojāta. Nosaukums, kas atrisinās uz publisku adresi, pasaka, ka privātā DNS zona nedarbojas.