Зошто вашата 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, бидејќи облачната порта нема да прифати произволен извор на тунел како свој.

Ако на клиентите им треба и интернет излез, планирајте поддржан дизајн на адресирање и рутирање за тоа, држете го независен од приватниот базен и тестирајте ги двата пата одделно. Еден работен пат не кажува ништо за другиот, а дизајнот што ги спојува пропаѓа на начин што изгледа како скршен тунел.