Увімкнення переадресації IP на наявному шлюзі GCE VPN
canIpForward — це оновлювана властивість, а не причина перебудовувати VM. Експортуйте ресурс, змініть один рядок, перевірте, а потім застосуйте з refresh.
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, підтвердьте, що гостьова система пересилає, потім тестуйте з клієнта.