Аддалены доступ распрацоўшчыка да 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, затым прызначэнне, якое абавязана заставацца забароненым. Запускайце кожны тэст з таго ж кліента, які будзе выкарыстоўваць шлях у прадукцыі, бо паспяховы тэст з працоўнай станцыі адміністратара мала што даказвае пра ноўтбук распрацоўшчыка з іншай сеткай.

Запішыце выбраную мадэль, прызначэнні, якія яна ахоплівае, ідэнтычнасці, якія яна аўтэнтыфікуе, і паводзіны пры збоі, калі шлях недаступны. Гэты запіс здольны прадухіліць наступны запыт ад маўклівага пашырэння тунеля замест дадання аднаго прызначэння ў задокументаваны дызайн.