Отдалечен достъп на разработчик до Google Cloud VPC: изберете пътя

На разработчика е нужна една SSH сесия, порт на база данни или широк достъп до дузина частни услуги и всяка от тези заявки изглежда като същия въпрос. Не е така. Дестинациите, протоколите и участващите идентичности решават кой път за достъп до Google Cloud е подходящ, а изборът на най-широкия по подразбиране създава работа, която не е трябвало да притежавате.

Запишете дестинациите и протоколите

Избройте частните адреси, портове и протоколи, които работата действително изисква, след което отбележете кои идентичности трябва да се удостоверяват отделно. Портът на база данни и частната зона DNS са различни изисквания, а услуга с UDP напълно изключва една от опциите по-долу. Писменият списък показва също какво не предоставяте. Точно това питат рецензентите.

Направете това преди да отворите слушател. Списъкът по-късно се превръща в приемен тест и е единственият надежден начин да различите тесен тунел от широк, който просто случайно работи.

IAP за няколко TCP услуги

TCP препращането чрез Identity-Aware Proxy дава удостоверен тунел до подходящи VM ресурси, без да излага услугата на интернет. Ежедневната форма е gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, а един порт може да се препрати локално с gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a.

Три неща трябва да съвпадат: извикващият се нуждае от ролята за достъп до IAP тунел, защитната стена трябва да допуска диапазона на източника на IAP, а дестинацията трябва да е достъпна на инстанцията. Разрешението за създаване на тунел не е идентификационни данни за база данни, SSH вход или RDP сесия, затова задръжте удостоверяването на приложението там, където му е мястото.

TCP препращането чрез IAP не е VPN от трето ниво. То пренася TCP до избрана дестинация, а не произволен IP трафик или UDP, и е неподходящо, когато приложение се нуждае от частен DNS през много услуги.

VPN за отдалечен достъп за по-широка достъпност

Когато са необходими няколко дестинации, протокола или частни зони DNS, по-добрата форма е изрично управляван VPN за отдалечен достъп на VM или поддържано устройство. Това разгръщане е отделно от управлявания от Google Cloud VPN: вие притежавате регистрацията на идентичността на клиента, актуализациите на софтуера, клиентските маршрути и обратните маршрути във VPC.

Планирайте целия списък, а не само публичния слушател. Включете пула от тунели, маршрута във VPC обратно към него, контролите за препращане, разрешаването на DNS и политиката за достъп за всяка услуга. VPN, който се свързва, но не може да разрешава вътрешни имена, проваля работния процес на разработчика точно толкова пълно, колкото и такъв, който никога не се свързва.

Cloud VPN е шлюз за сайт, а не профил за лаптоп

Google Cloud VPN свързва партньорски шлюзове през IPsec и неговите често задавани въпроси отделят тази роля сайт-към-сайт от достъпа клиент-към-шлюз. Създаването на тунел не произвежда профил, който служител импортира на лаптоп. Разликата е важна, когато някой поиска профил за Cloud VPN. Отговорът е различен продукт.

Шлюзът прави добре едно: дава на машините зад офис мрежа маршрут към VPC. Той не удостоверява всеки служител и не дава разрешения на приложения, затова тези политики остават на мрежовото и приложното ниво, където могат да се прилагат за всяка идентичност.

Проверете и запишете

Тествайте първо най-тясната дестинация, после тази, която изисква DNS, а след това дестинация, която трябва да остане забранена. Изпълнявайте всеки тест от същия клиент, който ще използва пътя в продукция, защото работещ тест от администраторска работна станция доказва малко за лаптоп на разработчик с различна мрежа.

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