Уключыць перанакіраванне IP на існуючым шлюзе GCE VPN

VM была створана без перанакіравання IP, яна ўжо запускае праграмнае забеспячэнне VPN, і інстынкт падказвае перабудаваць яе з шаблона з усталяваным сцягом. Такая перабудова не патрэбная. Compute Engine прадстаўляе canIpForward як абнаўляемую ўласцівасць, і дакументаваны шлях абнаўлення прымяняе яе з refresh, а не з перазапускам. Тое, што сцяг фактычна кантралюе, вузкае: без яго платформа адкідае пакеты, якія прыходзяць на інстанс, але не адрасаваныя ўласнаму адрасу інстанса. Шлюз, які перанакіроўвае трафік іншых машын, робіць менавіта гэта, таму сцяг павінен быць уключаны. Усё пасля гэтага — канфігурацыя гасця і маршрутызацыя, якіх сцяг не кранае.

Што сцяг дазваляе, а што не

Калі перанакіраванне адключана, платформа разглядае інстанс як канчатковы пункт. Пакеты, прызначэннем якіх з'яўляецца ўласны адрас інстанса, дастаўляюцца; пакеты, якія інстанс павінен перадаць ад імя кагосьці іншага, не.

Калі перанакіраванне ўключана, інстанс можа выступаць як наступны хоп для маршруту VPC, а гэта менавіта роля, патрэбная прыладзе VPN. Сцяг нічога не кажа пра фаерволы, маршрутызацыю гасця, канфігурацыю тунеля або зваротныя шляхі, і значэнне true на зламаным шлюзе ўсё яшчэ застаецца зламаным шлюзам.

Прачытайце бягучую ўласцівасць

Агледзьце наладу перад любым змяненнем, выкарыстоўваючы describe толькі для чытання супраць патрэбнага інстанса, праекта і зоны:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

Значэнне false мае значэнне толькі тады, калі гэтая VM павінна быць наступным хопам. Калі так, рэшту шляху ўсё роўна трэба правяраць асобна, бо ўласцівасць — гэта адзін радок у даўжэйшым ланцугу.

Абнавіце існуючы інстанс

Працэдура Google абнаўлення ўласцівасцей інстанса экспартуе бягучы рэсурс, змяняе ўласцівасць і адпраўляе вынік. Гэта іншы працоўны працэс, чым сцяг --can-ip-forward часу стварэння, і менавіта ён працуе на запушчанай VM.

Спачатку экспартуйце вызначэнне ў лакальны файл і захавайце нязменную копію для параўнання:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

У гэтым экспартаваным файле ўсталюйце ўласцівасць і не змяняйце нічога іншага:

canIpForward: true

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

Папрасіце механізм абнаўлення праверыць файл і паведаміць, што ён запатрабуе, перш чым будзе дазволена любое фактычнае змяненне:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

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

Прымявіце разгледжаны файл з лімітам refresh:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

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

Госць усё яшчэ павінен маршрутызаваць пакет

Дазвол у хмары не робіць прыладу маршрутызатарам. Пацвердзіце, што маршрут VPC выбірае гэтую VM як наступны хоп для прэфікса прызначэння, і што госць маршрутызуе паміж тунелем і патрэбным інтэрфейсам з уключанай уласнай палітыкай перанакіравання.

Палітыка фаеруола павінна дазваляць унутраны паток, а не толькі знешні слухач. Адкрыццё толькі порта VPN апісвае шыфраваны транспарт і нічога не кажа пра абмен праграмы ўнутры яго.

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

На шлюзе Linux перанакіраванне ядра — частка канфігурацыі гасця. Прылада pfSense мае свой эквівалент, і капіраванне ў яе каманды sysctl з Linux — не той крок.

Праверце з боку кліента, якому патрэбны доступ

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

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

Парадак працы: прачытайце ўласцівасць, экспартуйце і адрэдагуйце адзін радок, праверце з NO_EFFECT, прымяніце з REFRESH, пацвердзіце, што госць перанакіроўвае, а потым тэстуйце з кліента.