Cloud SQL Auth Proxy наспроти директен VPN маршрут до базата на податоци
Auth Proxy и директниот VPN маршрут решаваат различни половини од истиот проблем. Најпрво споредете ја авторизацијата на конекторот, портите и пријавувањето во базата.
Постојат два разумни начина да се стигне до приватна Cloud SQL инстанца од лаптоп на VPN. Едниот е директна врска до приватната адреса на инстанцата преку маршрутот што веќе го имате. Другиот е Cloud SQL Auth Proxy, кој слуша на loopback и сам ја отвора врската кон Cloud SQL. Тие се помалку конкурентни производи, а повеќе два различни одговори на прашањето кој ги држи акредитивите и кој го држи маршрутот. Лошиот избор најчесто се појавува како грешка во авторизацијата што се чита како мрежна грешка.
Еве ја споредбата што би ја ставил пред тим, а потоа проверките што навистина одлучуваат.
Два пата до истата инстанца
Директниот пат го користи маршрутот private-services-access од вашата мрежа во VPC на проектот. Вашиот клиент зборува PostgreSQL со приватната адреса на инстанцата, а врската живее или умира на рутирањето, firewall правилата и акредитивите на базата.
Патот преку proxy го користи истиот маршрут, но додава локален процес. Proxy се автентицира на Google API со default credentials на вашата апликација, отвора врска до инстанцата преку конекторот и изложува loopback порта што вашиот клиент ја третира како PostgreSQL. Два скока стануваат три, а средниот носи IAM авторизација. VPN маршрутот останува ваш за одржување, и proxy никогаш не го смета за замена за таа проверка.
Што всушност авторизира секој пат
Најважната разлика е што може да авторизира секоја опција наместо вас:
| 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 проверката на proxy и пријавувањето во базата се одделни порти, и поминувањето низ едната не ја отвора другата. Тим што ќе го вклучи proxy и ќе претпостави дека сметката на апликацијата повеќе не е потребна ќе помине попладне со грешки со лозинки што немаат никаква врска со мрежата.
Порти и маршрути, еден до друг
Proxy бара излезен TCP 443 за API и TCP 3307 за врската со инстанцата, и двете опишани во Google прегледот на Auth Proxy. Вашиот VPN маршрут го покрива вториот; првиот обично излегува по вообичаениот пат.
Директната врска бара PostgreSQL портата на инстанцата да биде достапна преку приватниот маршрут, што е сосема друг firewall разговор. Ако вашиот мрежен тим дозволува само излезен 443 од клиентските подмрежи, proxy се вклопува без промена на правило, а директниот пат не. Овој единствен факт го одлучува изборот почесто од било која архитектонска преференција.
Ниту еден пат не бара инстанцата да има јавна адреса, и ниту еден не оправдува додавање на таква.
Каде proxy не помага
Proxy не поправа маршрут што недостига. Ако маршрутот private-services-access недостига, или VPN не го пренесува, конекторот паѓа додека локалниот слушател сè уште седи таму и слуша, и тоа е збунувачкиот дел.
Тој исто така не го штити делот меѓу вашата апликација и proxy. На еден лаптоп тој дел е loopback и сè е во ред. Ако го врзете слушателот на wildcard адреса за колегата да може да стигне до него, сте изградиле неавтентицирана порта кон базата и сте ја нарекле удобност. Држете го на loopback и оставете колегата да си ги обезбеди сопствените акредитиви.
И не ги прави Private Service Connect и private services access взаемно заменливи. PSC инстанцата бара сопствен DNS распоред и повикот --psc наместо формата --private-ip.
Избор, а потоа проверка во секој случај
Изберете го proxy кога сакате IAM на патот, краткотрајни акредитиви и без промена на влезниот firewall.
Изберете го директниот маршрут кога поддржаниот клиент веќе има силни акредитиви за базата и мрежниот тим е удобно да ја отвори портата. Во секој случај проверете со вистинско барање, а не со успешна врска: поврзете се, извршете едно читање врз позната табела и проверете што гледа серверот за вашата сесија.
По повторно поврзување на VPN, третирајте ги истечените акредитиви, маршрутот што недостига и одбивањето на пријавување во базата како три различни дефекти. Само еден од нив е мрежен проблем, и само еден некогаш треба да доведе до промена на firewall правило.