Частен 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 използва крайна точка в собствената ви подмрежа и DNS подредба, която контролирате, така че маршрутът до нея е обикновен маршрут до адрес, който притежавате. Настройките за експорт на peering не важат за този дизайн и копирането на peering промени в PSC внедряване добавя риск, без да добавя достижимост.

И двете ви дават частен адрес; приликата свършва дотук.

Тествайте пътя в правилния ред

От външния клиент първо тествайте TCP крайната точка на базата данни. Завършено TCP ръкостискане означава, че маршрутизацията, защитната стена и слушателят са на място, а следващият тест е разрешена удостоверена операция. Отказът при удостоверяване всъщност е добра новина в този момент, защото доказва, че слушател на базата данни е отговорил. Изтичането на ICMP не казва почти нищо за достъпа до базата данни, защото много пътища го изхвърлят, докато предават TCP без проблем.

Ако клиентските ви диапазони са извън RFC 1918, прегледайте допълнителните изисквания за експорт на маршрути и оторизация на мрежата, преди да заключите, че дизайнът не се поддържа.

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