IPv6 префикс огранка: iroute-ipv6 или route-ipv6 на серверу?

Две директиве скоро истог назива појављују се у сваком радном примеру, а копирање једне без друге ствара тунел који изгледа исправно и тихо одбацује префикс огранка. Раде различит посао на различитим странама исте границе: једна учи језгро сервера где префикс живи, а друга учи OpenVPN који аутентификовани клијент га носи. Ако су обе тачне, префикс тече; ако је једна тачна, пакети имају руту али немају власника.

Две директиве, два различита посла

route-ipv6 је обична инсталација руте: сервер додаје руту језгра која показује префикс на његово тунелско сучеље. iroute-ipv6 припада контексту специфичном за клијента и декларише унутрашње власништво, тако да демон зна да промет за тај префикс треба ићи одређеном клијенту, а не оном peer-у који рута језгра случајно именује.

Једна се тиче табеле прослеђивања језгра, друга унутрашњег модела усмеравања демона. Њихово раздвајање објашњава зашто конфигурација која изгледа потпуна ипак може одбацити префикс. Објашњава и зашто се иста мрежа појављује двапут у сваком радном примеру. Ниједан од тих редова није сувишан.

У традиционалном userspace поступку потребне су обе и међусобно се допуњују. Сама рута језгра оставља демон без могућности избора peer-а. Сам iroute оставља језгро без пута до тунела. Одатле долази и већина забуне око датотека по клијенту: датотека није унос у табелу усмеравања, а унос руте није изјава о власништву.

ip -6 route show | grep fd00:7a
ip -6 route get fd00:7a::1

Камо која припада

Рута иде у управљану конфигурацију сервера, где важи за тај процес сервера. iroute иде у датотеку специфичну за клијента, названу према аутентификованом идентитету уређаја огранка.

Назив датотеке који не одговара стварном идентитету никада се не чита, а симптом је идентичан недостајућем iroute-у. Провери идентитет који је сервер аутентификовао, а затим провери назив датотеке знак по знак.

# /etc/openvpn/server/server.conf
route-ipv6 fd00:7a::/64
client-config-dir /etc/openvpn/server/ccd

# /etc/openvpn/server/ccd/branch-b
iroute-ipv6 fd00:7a::/64

Држи pool и префикс огранка одвојено, јер њихово преклапање ствара загонетку коју ниједна директива не може решити.

Шта треба други клијент

Други клијент који треба да достигне тај огранак треба објаву, не власништво. Пошаљи префикс клијентима које желиш, у контексту клијента или групе који одговара твојој конфигурацији.

Не шаљи га самом огранку, јер тај уређај већ има префикс као повезану мрежу.

Слање свима је избор с последицама: сваки клијент тада верује да је огранак доступан кроз тунел, укључујући клијенте којима никада ниси хтео дати тај приступ. Објава је у пракси одлука о приступу, иако директива изгледа као водоинсталатерски посао. референца за опције сервера документује iroute-ipv6 као власништво специфично за клијента, и то је разлика коју вреди задржати.

Повратни пут на уређају огранка

Власништво помаже само ако огранак прослеђује пакете и његов LAN зна како да одговори. Укључи прослеђивање IPv6 на уређају огранка и потврди да домаћини на његовом LAN-у шаљу промет за pool VPN назад према огранку, а не према подразумеваној рути која pool не познаје.

Тај повратни пут је IPv6 еквивалент проблема руте која недостаје, на који људи наилазе са IPv4.

Провери га са хоста на LAN-у упитом за адресу pool-а VPN, не са самог огранка. Упит на рутеру одговара на друго питање од оног твојих корисника, а њих двоје се довољно често разилазе да се додатна наредба исплати.

Кад пар још увек није довољан

Неке имплементације уопште не користе тај пут. Податковни пут језгра и сервери којима управља производ имају сопствено подржано руковање рутама, а пример за userspace можда се не преноси изравно.

Потврди који податковни пут користи твоја градња пре него што копираш директиве из приручника писаног за онај други.

На крају, запамти распон адреса: јединствени локални префикс попут fd00:7a::/64 приватан је по дизајну и не говори ништа о јавној доступности IPv6. Третирај га као интерни приступ, а излаз на интернет држи као засебно питање с властитом политиком.