Cloud SQL Auth Proxy немесе дерекқорға тікелей VPN маршруты
Auth Proxy мен тікелей VPN маршруты бір есептің әртүрлі жартысын шешеді. Алдымен коннектордың авторизациясын, порттарды және дерекқорға кіруді салыстырыңыз.
VPN-ге қосылған ноутбуктен жеке Cloud SQL инстанциясына жетудің екі ақылға қонымды жолы бар. Бірі — қазірде бар маршрут арқылы инстанцияның жеке мекенжайына тікелей қосылу. Екіншісі — loopback-те тыңдайтын және Cloud SQL-ге қосылымды өзі ашатын Cloud SQL Auth Proxy. Бұлар бәсекелес өнімдерден гөрі «тіркемені кім ұстайды және маршрутты кім ұстайды» деген сұраққа екі түрлі жауап. Қате таңдау әдетте желі қатесіндей оқылатын авторизация қатесі ретінде көрінеді.
Міне, команданың алдына қоятын салыстыру, одан кейін шешімді шынымен қабылдайтын тексерулер.
Бір инстанцияға екі жол
Тікелей жол сіздің желіңізден жобаның VPC-сіне private-services-access маршрутын пайдаланады. Клиентіңіз инстанцияның жеке мекенжайымен PostgreSQL тілінде сөйлеседі, ал қосылым маршруттауға, firewall ережелеріне және дерекқор тіркемелеріне байланысты өмір сүреді немесе өледі.
Proxy жолы сол маршрутты пайдаланады, бірақ жергілікті процесті қосады. Proxy қолданбаңыздың default credentials көмегімен Google API-ге аутентификация жасайды, коннектор арқылы инстанцияға қосылым ашады және клиентіңіз PostgreSQL деп қарайтын loopback портын ұсынады. Екі секіріс үшке айналады, ал ортаңғысы 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 |
Proxy-дің IAM тексеруі мен дерекқорға кіру — екі бөлек қақпа, және біреуінен өту екіншісін ашпайды. Proxy-ді қосып, қолданба тіркелгісі енді қажет емес деп ойлайтын команда желіге еш қатысы жоқ құпиясөз сәтсіздіктеріне жарты күн жұмсайды.
Порттар мен маршруттар, қатар
Proxy-ге API үшін шығыс TCP 443 және инстанция қосылымы үшін 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 реттеуі және --private-ip формасының орнына --psc шақыруы қажет.
Таңдау, содан кейін екі жағдайда да тексеру
Жолда IAM, қысқа мерзімді тіркемелер және кіріс firewall-інде өзгеріссіз болғанын қаласаңыз, proxy-ді таңдаңыз.
Қолдау көрсетілетін клиентте қазірдің өзінде күшті дерекқор тіркемелері болса және желілік команда портты ашуға дайын болса, тікелей маршрутты таңдаңыз. Кез келген жағдайда сәтті қосылыммен емес, нақты сұраныспен тексеріңіз: қосылыңыз, белгілі кестеге бір оқу жүргізіңіз және сервер сессияңыз туралы нені көретінін қараңыз.
VPN қайта қосылғаннан кейін мерзімі өткен тіркемені, жоғалған жеке маршрутты және дерекқорға кіруден бас тартуды үш түрлі істен шығу ретінде қарастырыңыз. Олардың тек біреуі ғана желі мәселесі, және тек біреуі ғана firewall ережесін өзгертуге әкелуі керек.