Cloud SQL Auth Proxy наспрам директне VPN руте до базе података
Auth Proxy и директна VPN рута решавају различите половине истог проблема. Прво упоредите ауторизацију конектора, портове и пријаву у базу података.
Постоје два разумна начина да се са лаптопа на VPN-у стигне до приватне Cloud SQL инстанце. Један је директна веза на приватну адресу инстанце преко руте коју већ имате. Други је Cloud SQL Auth Proxy, који слуша на loopback-у и сам отвара везу ка Cloud SQL-у. Они нису толико конкурентски производи колико два различита одговора на питање ко држи акредитиве, а ко држи руту. Лош избор се обично појави као грешка ауторизације која се чита као мрежна грешка.
Ево поређења које бих ставио пред тим, а затим провере које заиста одлучују.
Два пута до исте инстанце
Директан пут користи руту private-services-access из ваше мреже у VPC пројекта. Ваш клијент говори PostgreSQL са приватном адресом инстанце, а веза живи или умире на рутирању, firewall правилима и акредитивима базе.
Пут преко проксија користи исту руту, али додаје локални процес. Прокси се аутентификује на Google API са default акредитивима ваше апликације, отвара везу ка инстанци преко конектора и излаже 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 за везу са инстанцом, а обоје је описано у Google-овом прегледу 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 правила.