Cloud VPN към VM в GCP: използвайте вътрешния IP, а не NAT IP

След като локална мрежа достигне VPC през Cloud VPN, дестинацията за услуга в Compute Engine обикновено е вътрешният адрес на VM. Външният IPv4 адрес не е втори адрес, който можете да поставите в същия частен маршрут. Повечето объркване в тази област идва от това, че три адреса с три задачи се третират като взаимозаменяеми, затова започнете с това да назовете кой от тях използва даден пакет.

Три адреса, три задачи

Назовете и трите, преди да отстранявате проблеми с който и да е от тях, защото отговорът променя обекта, който ще прегледате след това.

Първият принадлежи на тунела. Вторият принадлежи на вашия дизайн за маршрут и защитна стена. Третият принадлежи на входящия интернет достъп и се съпоставя, а не се прикача. Дизайн, който работи за един от тях, не казва нищо за другите два.

Защо външният адрес не е втори интерфейс

Ръководството за адресиране е авторитетът за това как се различават вътрешната и външната достъпност в Compute Engine. Външният IPv4 адрес в Compute Engine е съпоставяне едно към едно върху единствения вътрешен NIC на инстанцията, така че гостната система никога не вижда втори интерфейс или втори адрес на този NIC. Това, което VM съобщава отвътре, все още е един основен вътрешен адрес.

Ето защо частен клиент, който насочва трафик през тунела към 10.24.1.7, и клиент, който е насочен към външния адрес на VM, са на различни пътища. Отварянето на правило за защитна стена за публичния адрес не променя нищо в маршрута във 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 адреса на VM не решава припокриването; тя променя за кой адрес пакетът твърди, че е, без да дефинира как работи обратният път.

Решете припокриването умишлено: преномерирайте, използвайте поддържан дизайн за транслация или маршрутизирайте през мрежа, където префиксите не се сблъскват. Всяко от тези е дизайн с отговорник. NAT адресът не е дизайн.

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

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

Проверете с реален клиент от другата страна: разрешете името, потвърдете, че връща вътрешния адрес, свържете се и проверете обратния трафик. Документацията за IP адреси на Compute Engine е справката за разграничението вътрешно срещу външно, използвано по-горе.