Приватна IP на Cloud SQL преку VPN: рутата што никој не ја извезува

Многу тимови веруваат дека приватната IP на Cloud SQL работи само од внатрешноста на VPC, и тоа верување опстојува затоа што дефектот изгледа како проблем со базата на податоци. Google документира пристап од мрежи поврзани преку Cloud VPN или Cloud Interconnect. На тие мрежи не им треба посебна функција на базата, туку две размени на рути што лесно се оставаат половично конфигурирани. Тунелот се крева, пресметковните инстанци одговараат, а врската со базата истекува — точно таа комбинација што ги праќа луѓето во погрешната конзола.

Мит: приватната IP значи приватна за VPC

Пристапот до приватни услуги е VPC peering помеѓу вашата мрежа и производителска мрежа во сопственост на Google. Доделениот опсег за услугата живее на страната на производителот, а адресата на инстанцата е внатре во него. Поради тој peering базата во вашиот проект може да седи на адреса кон која вашата VPC рутира, иако ниту една ваша експлицитна подмрежа не ја содржи.

Бидејќи е peering, има и однесување на peering, вклучително делот каде прилагодените рути не преминуваат автоматски.

Мит: работниот тунел ја носи рутата до базата со себе

Два опсези мора да го преживеат патувањето. Првиот е клиентскиот префикс: вашата локална мрежа мора да биде позната на Cloud Router со конкретни префикси, бидејќи стандардната рута не може да го обезбеди увозот што и е потребен на производителската мрежа за повратниот пат. Вториот е доделениот опсег на услугата, што надворешната страна мора да го научи за нејзините пакети до базата да имаат каде да одат. Тоа се различни рути одржувани на различни граници, а поправката на едната ја остава другата скршена.

На страната на Google тоа значи вклучување на Export custom routes на соодветните peering врски и додавање на доделениот опсег на услугата во најавените рути на Cloud Router за тунелот.

Задржете ги најавите што веќе постојат. Додавањето на опсегот на услугата не смее да ги отстрани VPC рутите што истата BGP сесија ги носи за друг сообраќај, а целосно заменет сет на најави е втор прекин скриен зад првиот. Проверете ги и ефективните рути на надворешниот уред, бидејќи достигнувањето на VPN портата или друга подмрежа докажува само транспорт.

Мит: Cloud SQL Auth Proxy го решава мрежниот проблем

The Auth Proxy обезбедува поддржана автентикација и шифриран транспорт помеѓу вашата апликација и инстанцата. Тој не создава рута. Прокси стартувано на домаќин без пат до приватната мрежа ќе пропадне исто како директна врска, а неговите логови ќе бидат помалку корисни за причината. Преместувањето на проксито на домаќин што има поврзаност менува кој дел од патот мора да работи, и тоа е вистинска дизајнерска одлука, а не заобиколување.

Она што не го прави е да му овозможи на исклучено лаптоп да достигне инстанца достапна само приватно.

Мит: Private Service Connect ги следи истите правила

Private Service Connect користи endpoint во вашата сопствена подмрежа и DNS уредување што вие го контролирате, па рутата до него е обична рута до адреса што ја поседувате. Поставките за извоз на peering не важат за тој дизајн, а копирањето peering промени во PSC распоредување додава ризик без да додаде достапност.

Двете ви даваат приватна адреса; сличноста завршува таму.

Тестирајте го патот во правилен редослед

Од надворешниот клиент прво тестирајте го TCP endpoint-от на базата. Завршено TCP ракување значи дека рутирањето, заштитниот ѕид и слушателот се сите на место, а следниот тест е дозволена автентицирана операција. Одбивањето на автентикација во тој момент е всушност добра вест, бидејќи докажува дека слушател на базата одговорил. ICMP истекувањето речиси ништо не кажува за пристапот до базата, бидејќи многу патеки го отфрлаат додека TCP го пренесуваат без проблем.

Ако вашите клиентски опсези се надвор од RFC 1918, прегледајте ги дополнителните барања за извоз на рути и авторизација на мрежата пред да заклучите дека дизајнот не е поддржан.

Забележете четири објекти со врската: надворешниот префикс, доделениот опсег на услугата, вклучените peering врски и рутерот што најавува. Тие четири го објаснуваат целиот приватен пат и го заменуваат преданието дека Cloud SQL или секогаш бара прокси или воопшто не е достапен преку VPN.