Удаљени приступ програмера 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, па одредиште које мора да остане одбијено. Покрените сваки тест са истог клијента који ће пут користити у продукцији, јер успешан тест са администраторске радне станице мало доказује о преносном рачунару програмера са другом мрежом.

Запишите изабрани модел, одредишта која покрива, идентитете које проверава и понашање при квару када пут није доступан. Тај запис спречава да следећи захтев тихо прошири тунел уместо да дода једно одредиште документованом дизајну.