VPN į VPC veikia, bet valdoma paslauga baigia laukti
Tunelis baigiasi jūsų krašte, o ne paslaugų teikėjo priekinėse durys. Prieš keisdami maršrutą, priskirkite tikslą prie VM talpinamo, prie VPC prijungto arba tik viešo.
Pasiekti valdomą duomenų bazę per VPN paprastai nepavyksta dėl priežasties, kurios niekas neįrašė į vadovą: tunelis baigiasi jūsų tinklo krašte, o paslauga niekada nebuvo toje jo pusėje. Maršrutų lentelė atrodo teisingai, tunelis praneša esąs aktyvus, o ryšys vis tiek baigia laukti. Atlikite keturis patikrinimus žemiau iš eilės ir sustokite ties pirmuoju, kurio sėkmės sąlyga netenkinama, nes kiekvienas vėlesnis patikrinimas daro prielaidą, kad ankstesnieji pavyko.
Pirmas patikrinimas: kur iš tikrųjų yra galinis taškas?
VPN tarpinė sujungia du tinklus, kurių adresaciją kontroliuojate jūs. Valdoma paslauga veikia už paties teikėjo priekinių durų, o tos durys įgauna vieną iš trijų formų priklausomai nuo produkto. Jei nežinote, su kuria forma susiduriate, joks maršrutų darbas nepadės, nes gedimas gali būti visai ne maršruto gedimas.
| 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 |
Dauguma praleistų popiečių atsiranda dėl to, kad ši klasifikacija praleidžiama ir einama tiesiai prie maršrutų lentelės. Teikėjo talpinama paslauga su viešu galiniu tašku nėra už jūsų tunelio, kad ir ką sakytų schema, o prie VPC prijungta niekada nepasirodys viešame DNS atsakyme.
Antras patikrinimas: prie VPC prijungta paslauga, pavyzdžiui, ElastiCache
Tokio tipo podėliai adresuojami jūsų pačių VPC viduje ir visai neturi į internetą atsukto klausytojo. Kliento VPN, pasibaigiantis tame pačiame VPC, gali juos pasiekti, bet tik kai sutampa trys sąlygos. Podėlio galinis taškas turi būti susietas su poaibiais, kuriuos mato jūsų tunelis, jo saugos grupė turi leisti adresą, iš kurio ateina jūsų klientai, o kliento pusėje reikia maršruto, apimančio podėlio poaibius.
Įprasta klaida manyti, kad netoliese esantis ryšys skaičiuojasi. Prijungus VPN prie kito VPC arba pasikliaujant vien peering, podėlio saugos grupė ar jo poaibio maršrutų lentelė neišplečiama jūsų klientams. Kai esamas tunelis baigiasi kitur, įprasta atsarginė priemonė yra peršokimo serveris arba VPN serveris, patalpintas tame VPC. Tokia atsarginė priemonė yra apėjimas, o ne projektas, ir vadove ji turėtų būti taip paženklinta.
Trečias patikrinimas: PaaS galinis taškas su viešu vardu
Azure Database for PostgreSQL pateikia viešą serverio vardą. Jis neduoda jums privataus adreso, kurį galėtumėte įtvirtinti hosts faile ir nukreipti per tarpinę. Virtualaus tinklo paslaugos galiniai taškai riboja, kurie poaibiai gali pasiekti išteklių; jie neįgalioja vietinio kliento, atvykstančio per VPN.
Gauti privatų prieigą reiškia įdiegti privatų galinį tašką arba privatų ryšį, o tada pridėti privačią DNS zoną, kad viešas vardas atsakytų tuo tašku, o ne internetu. VPN kartu su paslaugos galinio taško taisykle yra kita architektūra, kuri panašiai atrodo tik schemoje. App Service laikosi tos pačios logikos iš priešingos pusės: VNet integracija leidžia programai atlikti išeinančius skambučius į VNet, ir ji nesukuria iš jūsų tunelio ateinančio privataus kelio. Todėl įeinamajai privačiai prieigai reikia privataus galinio taško, App Service aplinkos arba tarpinės prieš programą, o kurią iš jų galite naudoti, priklauso nuo plano.
Ketvirtas patikrinimas: produktai su savo priekinėmis durimis
Firebase Hosting negalima prijungti prie Cloud VPN, nes talpinimo sluoksnis yra pasaulinė priekinė dalis, o ne kažkas projekto VPC viduje. Dokumentuota alternatyva yra pačiam pastatyti kontroliuojamą įėjimo tašką su tarpinio serverio egzemplioriumi arba apkrovos balansuokliu, paremtu saugykle. Bet kokiu atveju svetainė nustoja būti grynu talpinimo produktu ir tampa infrastruktūra, kurią dabar valdote jūs. Tą mainus verta įvardyti prieš kam nors pažadant, kad tunelis jį apims.
Private API Gateway stovi arčiau VPC paslaugų pusės: interface tipo VPC galinis taškas paskelbia pagrindinio kompiuterio vardą, kurio atsakymai yra privatūs adresai, o srautas iš jūsų patalpų ateina per tunelį arba dedikuotą tarpusavio ryšį. Galinis taškas turi būti susietas su API, o sertifikatas ir pagrindinio kompiuterio vardas turi atitikti pasirinktinį domeną, kurį naudoja skambinantieji.
Google Cloud VPN tuneliai rišasi prie partnerio IP adresų, o ne prie vardų. DNS persiuntimas konfigūruojamas atskirai, todėl tunelis gali būti visiškai sveikas, kol paieškos nutolusioje privačioje zonoje vis tiek nepavyksta.
Tada raskite ribą
Paleiskite tą patį ryšį iš VM, esančios VPC viduje. Kai ten pavyksta, o iš VPN kliento nepavyksta, tarpas yra tarp kliento kelio ir paslaugos galinio taško: maršrutas, saugos grupė, galinio taško politika arba vardas. Kai nepavyksta abu bandymai, niekas tame tinkle negali pasiekti paslaugos, ir VPN niekada nebuvo kliūtis.
getent hosts db.internal.example
nc -vz db.internal.example 5432Vardo paiešką ir prievado patikrinimą atlikite atskirai, nes jie nepavyksta dėl skirtingų priežasčių, ir pora pasako, kuri kelio pusė sugedusi. Vardas, kuris išsprendžiamas į viešą adresą, pasako, kad privati DNS zona neveikia.