Защо вашата GCP VM не може да отговори на IPv6 пула на OpenVPN

Вашият IPv6 VPN клиент достига до натоварването, натоварването отговаря в тунела, а отговорът така и не пристига. Първият инстинкт е да обвиним защитната стена или тунела и обикновено нито едно от двете не е виновно. Адресът, който се раздава от OpenVPN, е вътрешна мрежа, която съществува само в тунела; Google Cloud няма представа, че fd42:90::/64 трябва да стои зад конкретна VM, докато не му кажете.

Две отделни системи трябва да научат този факт и само една от тях е OpenVPN. VPC се нуждае от маршрут, преди да може да изпрати нещо обратно, а на VM трябва да е разрешено да препраща това, което пристига. Сгрешете която и да е половина и симптомът изглежда идентичен.

Пулът е вътрешна мрежа, а не подмрежа

OpenVPN може да раздава IPv6 адреси от диапазон по ваш избор и този диапазон е фикция, за която се договарят двата края на тунела. Той не е подмрежа на Google Cloud, не се показва в списъка с подмрежи на VPC и мрежовият интерфейс на VM не получава тези адреси. Затова натоварване, което отговаря на клиент, изпраща пакет до адрес, който мрежата смята за немаршрутизируем.

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

Уникалното локално адресиране като fd42:90::/64 е разумен избор за тази вътрешна мрежа. Префиксът служи и като напомняне, че дизайнът е частен по своята същност. Нищо в един ULA пул не го прави законен източник в публичния интернет.

Дайте на VPC дестинация и следващ хоп

Отговорът се нуждае от VPC маршрут, чиято дестинация е пулът и чийто следващ хоп е VPN VM. Актуалната документация за статични маршрути покрива IPv6 диапазони за дестинация и изброява кои типове следващ хоп са допустими, затова проверете поддържаната форма за вашата топология, вместо да копирате по-стар IPv4 пример.

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

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

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

Препращането трябва да се включи два пъти

Маршрутът доставя пакета до инстанцията. Той не прави инстанцията готова да препраща нещо, което не е адресирано до нея, и това разрешение съществува на две нива.

Облачната страна се нуждае от включена способност за препращане на инстанцията; това е настройката, която позволява на VM да приема трафик за адреси, които не притежава, и да го предава. Гостевата страна се нуждае от собствено IPv6 препращане, защото ядрото взема отделно решение след пристигането на пакета. И двете трябва да са включени, преди един-единствен отговор да пресече тунела.

sysctl -w net.ipv6.conf.all.forwarding=1

След това правилата на защитната стена трябва да допускат вътрешния диапазон на източника в двете посоки. Google Cloud оценява декапсулирания пакет, така че правило, което покрива само подмрежата на VPC, изхвърля трафика на пула, след като тунелът вече е успял. Добавете пула като диапазон на източника във входящото правило и проверете дали никаква персонализирана изходяща политика не блокира отговора. Подразбиращото се правило за разрешаване покрива случая по подразбиране, а ръчно написаното изходящо правило — не.

Кажете на OpenVPN кой какво притежава

OpenVPN препраща към клиент, когато знае, че този клиент притежава дестинацията. Клиентските адреси от пула се управляват от директивата за сървъра, която дефинира пула, но подмрежа зад клиент е друга подредба и се нуждае от явен запис за собственост за този клиент.

Объркването на двете създава тунел, в който пинговете към сървъра работят, а нищо зад него — не. Решете кой случай изграждате, след което напишете съответния запис, вместо да добавяте втори ред push и да се надявате.

Дръжте интернет изхода извън този дизайн

Частният достъп и интернет достъпът са отделни планове. ULA пул може да достига натоварвания в VPC през тунела, след като маршрутизацията и препращането се съгласуват, и същият този пул няма път към публичния интернет през VPC, защото облачният шлюз няма да приеме произволен тунелен източник като свой.

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