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.
Атрыманне прыватнага доступу азначае ўвядзенне прыватнага канцавога пункта або схемы private link, а затым даданне прыватнай зоны DNS, каб публічнае імя адказвала гэтым пунктам замест інтэрнэту. VPN у спалучэнні з правілам канцавога пункта службы — гэта іншая архітэктура, якая выглядае падобнай толькі на схеме. App Service ідзе па той жа логіцы з процілеглага боку: інтэграцыя з VNet дазваляе праграме рабіць зыходныя выклікі ў VNet і не стварае ўваходнага прыватнага шляху з вашага тунэля. Таму ўваходны прыватны доступ патрабуе прыватнага канцавога пункта, асяроддзя App Service або шлюза перад праграмай, і тое, што з гэтага вам даступна, залежыць ад плана.
Праверка чацвёртая: прадукты з уласнымі ўваходнымі дзвярыма
Firebase Hosting нельга далучыць да Cloud VPN, бо ўзровень хостынгу — гэта глабальны фронтэнд, а не нешта ўнутры VPC праекта. Дакументаваная альтэрнатыва — пабудаваць кантраляваную кропку ўваходу самастойна, з дапамогай проксі-інстанса або балансіроўшчыка нагрузкі на аснове бакета. У любым выпадку сайт перастае быць чыста хостынгавым прадуктам і становіцца інфраструктурай, якой вы цяпер кіруеце. Гэты абмен варта назваць перад тым, як хтосьці паабяцае, што тунэль яго пакрые.
Private API Gateway стаіць бліжэй да боку сэрвісаў VPC: канцавы пункт VPC тыпу interface публікуе імя хоста, адказы якога — прыватныя адрасы, а трафік з вашага офіса прыходзіць праз тунэль або выдзелены інтэрконект. Канцавы пункт павінен быць звязаны з API, а сертыфікат і імя хоста — адпавядаць уласнаму дамену, які выкарыстоўваюць выклікальнікі.
Тунэлі Google Cloud VPN прывязваюцца да IP-адрасоў партнёраў, а не да імёнаў. Перанакіраванне DNS наладжваецца асобна, і менавіта таму тунэль можа быць цалкам здаровым, пакуль запыты ў аддаленай прыватнай зоне ўсё яшчэ не ўдаюцца.
Затым вызначце мяжу
Выканайце тое ж злучэнне з VM унутры VPC. Калі там яно ўдаецца, а ад кліента VPN не, разрыў знаходзіцца паміж шляхам кліента і канцавым пунктам сэрвісу: маршрут, група бяспекі, палітыка канцавога пункта або імя. Калі ж не ўдаюцца абодва запыты, нішто ў гэтай сетцы не можа дасягнуць сэрвісу, і VPN ніколі не быў перашкодай.
getent hosts db.internal.example
nc -vz db.internal.example 5432Рабіце пошук імені і праверку порта асобна, бо яны не ўдаюцца з розных прычын, і гэтая пара паказвае, якая палова шляху зламаная. Імя, якое вырашаецца ў публічны адрас, кажа вам, што прыватная зона DNS не задзейнічана.