Cloud VPN до ВМ у GCP: використовуйте внутрішній IP, а не NAT-IP

Коли локальна мережа досягає VPC через Cloud VPN, пунктом призначення для служби Compute Engine зазвичай є внутрішня адреса ВМ. Зовнішня IPv4-адреса — це не друга адреса, яку можна підставити в той самий приватний маршрут. Більшість плутанини тут виникає через те, що три адреси з трьома завданнями вважаються взаємозамінними, тому почніть із того, щоб назвати, яку з них використовує конкретний пакет.

Три адреси, три завдання

Назвіть усі три, перш ніж налагоджувати будь-яку з них, бо відповідь змінює об'єкт, який ви перевірятимете далі.

Перша належить тунелю. Друга належить схемі маршруту та міжмережевого екрана. Третя належить вхідному доступу з інтернету і відображається, а не приєднується. Схема, яка працює для однієї з них, нічого не каже про дві інші.

Чому зовнішня адреса — не другий інтерфейс

Посібник з адресації є джерелом істини про те, чим відрізняється внутрішня і зовнішня доступність у Compute Engine. Зовнішня IPv4-адреса в Compute Engine — це відображення «один до одного» на єдиний внутрішній NIC екземпляра, тож гостьова система ніколи не бачить другого інтерфейсу чи другої адреси на цьому NIC. Те, що ВМ повідомляє зсередини, і далі одна основна внутрішня адреса.

Саме тому приватний клієнт, який спрямовує трафік через тунель до 10.24.1.7, і клієнт, націлений на зовнішню адресу ВМ, перебувають на різних шляхах. Відкриття правила міжмережевого екрана для публічної адреси нічого не змінює в маршруті VPC, який має нести трафік тунелю, а редагування маршруту в гостьовій системі не зсуває відображення платформи. Виберіть адресу, яку називає ваш маршрут, і потім перевіряйте лише ті об'єкти, що нею керують. Ця дисципліна прибирає більшу частину здогадів із цього шляху пошуку несправностей.

Пройдіть шлях із gcloud

Почніть з екземпляра і прочитайте обидві адреси з одного й того самого об'єкта, щоб знати, про яку з них говорить ваша документація:

gcloud compute instances describe app-1 --zone=europe-west1-b \
  --format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"

Потім підтвердьте маршрутизацію та дозвіл, від яких шлях насправді залежить:

gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1

Прочитайте оголошені та вивчені діапазони тунелю, маршрут VPC для підмережі робочого навантаження і правило міжмережевого екрана, яке дозволяє локальне джерело. Ці три мають збігатися, перш ніж слухач у гостьовій системі взагалі стане актуальним.

Потім перевірте гостьову систему: чи слухає служба внутрішню адресу і чи проходить її зворотний шлях знову через VPC? Слухач, прив'язаний лише до публічної адреси, не пройде цю перевірку навіть тоді, коли кожен об'єкт на боці хмари правильний.

Публічний префікс — це інше питання

Ніщо з переліченого не означає, що кожна адреса всередині VPN мусить бути RFC1918. Віддалену мережу можна законно нумерувати з публічного простору, якщо платформа підтримує маршрутизацію, а оператор має право на адресу. Це звичайний проєктний вибір.

Це не те саме, що ставитися до звичайної зовнішньої NAT-адреси як до ще однієї внутрішньої адреси підмережі. Одна — це префікс, який ви маршрутизуєте; інша — відображення, яке платформа застосовує до вхідного доступу.

Зовнішній IPv6 і спеціально спроєктовані схеми адресації мають власну семантику. Якщо ваш план залежить від однієї з них, читайте документацію платформи щодо цієї функції, а не узагальнюйте випадок IPv4. Відображення IPv4 — це звичайний випадок, але не єдиний, і кожен виняток має власні правила.

Перекривані діапазони — це інша проблема

Перекривані приватні діапазони — реальна причина, чому люди хапаються за публічну адресу, і це неправильний важіль. Зміна призначення на NAT-адресу ВМ не вирішує перекриття; вона змінює, для якої адреси пакет заявляє себе, не визначаючи, як працює зворотний шлях.

Вирішіть перекриття свідомо: перенумеруйте, використайте підтримувану схему трансляції або маршрутизуйте через мережу, де префікси не конфліктують. Кожен із цих варіантів — схема з відповідальним. NAT-адреса — не схема.

Документуйте два поля окремо

Запишіть партнера тунелю та призначення робочого навантаження як два окремі поля runbook, кожне з маршрутом і правилом міжмережевого екрана, що його підтримують. Тунель IPsec, що піднявся, лише повідомляє, що сторони згодні; він нічого не каже про те, за якою адресою доступне робоче навантаження, і нічого про те, чи повний його приватний маршрут.

Перевірте реальним клієнтом з іншого боку: розв'яжіть ім'я, переконайтеся, що воно повертає внутрішню адресу, підключіться і перевірте зворотний трафік. документація Compute Engine щодо IP-адрес — це довідка щодо розрізнення внутрішнього і зовнішнього, використаного вище.