Включване на 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 има свой еквивалент и копирането на Linux sysctl команда в него не е съответстващата стъпка.

Проверете от клиента, който се нуждае от достъп

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

Запишете свойството в това, което управлява устройството. Ръчно коригирана VM работи до следващата ѝ подмяна, която тихо връща първоначалната настройка, и този отказ ще изглежда като регресия във VPN софтуера.

Ред на работа: прочетете свойството, експортирайте и редактирайте един ред, валидирайте с NO_EFFECT, приложете с REFRESH, потвърдете, че гостът препраща, след което тествайте от клиент.