Cloud SQL Auth Proxy супраць прамога маршруту VPN да базы даных
Auth Proxy і прамы маршрут праз VPN вырашаюць розныя паловы адной задачы. Спачатку параўнайце аўтарызацыю канэктара, порты і ўваход у базу даных.
Ёсць два разумныя шляхі да прыватнага інстансу Cloud SQL з ноўтбука ў VPN. Першы — прамое падключэнне да прыватнага адрасу інстансу праз маршрут, які ў вас ужо ёсць. Другі — Cloud SQL Auth Proxy, які слухае на loopback і сам адкрывае злучэнне да Cloud SQL. Гэта хутчэй не канкуруючыя прадукты, а два розныя адказы на пытанне, хто трымае ўліковыя даныя, а хто — маршрут. Няправільны выбар звычайна ўсплывае як памылка аўтарызацыі, якая чытаецца як памылка сеткі.
Вось параўнанне, якое я паставіў бы перад камандай, а затым праверкі, якія фактычна ўсё вырашаюць.
Два шляхі да аднаго інстансу
Прамы шлях выкарыстоўвае маршрут private-services-access з вашай сеткі ў VPC праекта. Ваш кліент размаўляе на PostgreSQL з прыватным адрасам інстансу, і злучэнне жыве або памірае на маршрутызацыі, правілах firewall і ўліковых даных базы.
Шлях праз проксі выкарыстоўвае той жа маршрут, але дадае лакальны працэс. Проксі аўтэнтыфікуецца ў Google API з дапамогай default credentials вашай праграмы, адкрывае злучэнне да інстансу праз канэктар і прадстаўляе порт loopback, які ваш кліент успрымае як PostgreSQL. Два скачкі становяцца трыма, і сярэдні нясе аўтарызацыю IAM. Маршрут VPN усё яшчэ ваш для падтрымкі, і проксі ніколі не лічыць яго заменай гэтай праверкі.
Што насамрэч аўтарызуе кожны шлях
Самая важная розніца — што кожны варыянт можа аўтарызаваць за вас:
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
Праверка IAM у проксі і ўваход у базу даных — гэта асобныя брамы, і праход праз адну не адкрывае другую. Каманда, якая ўключыць проксі і будзе лічыць, што ўліковы запіс праграмы ўжо не патрэбны, правядзе паўдня над збоямі пароляў, якія не маюць ніякага дачынення да сеткі.
Порты і маршруты побач
Проксі патрабуе зыходны TCP 443 для API і TCP 3307 для злучэння з інстансам; абодва апісаны ў Агляд Auth Proxy. Ваш маршрут VPN пакрывае другі; першы звычайна выходзіць звычайным шляхам.
Прамое злучэнне патрабуе, каб порт PostgreSQL інстансу быў дасягальны праз прыватны маршрут, а гэта зусім іншая размова пра firewall. Калі ваша сеткавая каманда дазваляе толькі зыходны 443 з кліенцкіх падсетак, проксі падыходзіць без змены правіла, а прамы шлях — не. Гэты адзіны факт вырашае выбар часцей за любую архітэктурную перавагу.
Ні адзін з шляхоў не патрабуе, каб інстанс меў публічны адрас, і ні адзін не апраўдвае даданне такога.
Дзе проксі не дапамагае
Проксі не выпраўляе адсутны маршрут. Калі маршрут private-services-access адсутнічае або VPN яго не нясе, канэктар падае, пакуль лакальны слухач усё яшчэ сядзіць і слухае, — і менавіта гэта заблытвае.
Ён таксама не абараняе ўчастак паміж вашай праграмай і проксі. На адным ноўтбуку гэты ўчастак — loopback, і гэта нармальна. Калі вы прывяжаце слухач да адрасу wildcard, каб калега мог да яго дабрацца, вы пабудавалі шлюз да базы даных без аўтэнтыфікацыі і назвалі гэта зручнасцю. Трымайце яго на loopback і дайце калегу атрымаць свае ўласныя ўліковыя даныя.
І ён не робіць Private Service Connect і private services access узаемазаменнымі. Інстансу PSC патрэбна ўласная схема DNS і выклік --psc, а не форма --private-ip.
Выбар, а затым праверка ў любым выпадку
Выбірайце проксі, калі хочаце IAM у шляху, кароткачасовыя ўліковыя даныя і ніякіх змен уваходнага firewall.
Выбірайце прамы маршрут, калі падтрыманы кліент ужо мае моцныя ўліковыя даныя базы і сеткавая каманда гатова адкрыць порт. У любым выпадку правярайце рэальным запытам, а не паспяховым злучэннем: падключыцеся, выканайце адно чытанне з вядомай табліцы і праверце, што сервер бачыць для вашай сесіі.
Пасля перападключэння VPN разглядайце скончаныя ўліковыя даныя, адсутны прыватны маршрут і адмову ўваходу ў базу як тры розныя збоі. Толькі адзін з іх — сеткавая праблема, і толькі адзін павінен прыводзіць да змены правіла firewall.