Зашто је подмрежа иза OpenVPN клијента недоступна?

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

tun интерфејс нема следећи скок по клијенту. Језгро види један интерфејс са много партнера, па се одлука о томе који клијент треба да прими пакет за удаљени LAN мора донети унутар OpenVPN процеса. Та одлука се конфигурише помоћу iroute, а без ње пакет нема куда да оде.

Сервер рутира по клијенту, а не по интерфејсу

Када сервер треба да пошаље пакет на тунелску адресу клијента, одговор је недвосмислен: адреса припада сесији тог клијента. Када је одредиште цела подмрежа иза тог клијента, адреса не припада никоме кога сервер зна, а рута језгра ка тунелу само каже "кроз овај интерфејс", не наводећи који партнер.

OpenVPN то решава интерном табелом рутирања која префикс одредишта повезује са одређеним клијентом. Та табела се гради од iroute записа, зато обична рута на хосту сервера није довољна. Рута језгра доводи пакет до тунелског интерфејса; интерно повезивање одлучује која сесија га прима. Зато се поправка никада не појављује у излазу рута језгра.

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

Писање iroute записа који именује клијента

iroute живи у конфигурационој датотеци специфичној за клијента, не у главној конфигурацији сервера. Усмерите сервер на директоријум опцијом client-config-dir, затим направите датотеку чије је име уобичајено име сертификата клијента и ставите префикс унутра.

За огранак чији је LAN 10.20.0.0/24 и чије је уобичајено име сертификата branch-router, датотека на тој путањи садржи ред као iroute 10.20.0.0 255.255.255.0. Главној конфигурацији је потребна само опција директоријума; префикс живи код клијента.

Уобичајено име је крхки део. Сертификат издат са другим subject, или поставка која аутентификује кориснике по корисничком имену док је датотека названа по сертификату, производи датотеку која се никада не чита. Проверите име које сервер стварно пријављује за сесију и размотрите опцију која неусклађеног клијента пушта да не успе уместо да се тихо повеже без својих рута. Преименовање датотеке да одговара сертификату је петоминутна поправка која спречава веома дугу вече.

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

Изградња повратног пута у оба смера

Довођење пакета до удаљеног LAN-а је половина посла. Клијент такође мора да шаље саобраћај тог LAN-а у тунел, што се обично ради гуркањем руте клијенту: ред као push "route 10.8.0.0 255.255.255.0" говори сваком клијенту како да дође до мреже на страни сервера. За огранак, еквивалентна рута показује на тунел за све што треба да достигне на страни сервера.

Повратни смер захтева власника на далекој страни. Тамо неко мора да зна пут назад: статична рута на LAN рутеру која усмерава VPN базен ка серверу, или превод адреса на серверу пре него што саобраћај уђе у LAN. Статична рута држи оригиналне адресе видљивим у дневницима и правилима приступа, али захтева сарадњу власника LAN-а; превод је самосталан, али крије ко се заиста повезао.

Прослеђивање мора бити омогућено на хосту сервера. Без тога језгро прихвата пакет из тунела и одбија да га пренесе на LAN интерфејс, што из перспективе клијента изгледа исто као iroute који недостаје.

Провера доступности правим сондама

Тестирајте по слојевима уместо да пингујете далеки крај и нагађате. Са сервера проверите да интерно повезивање за префикс постоји и да рута језгра показује на тунел. Са клијента потврдите да је гурнута рута инсталирана и да је његов подразумевани пут до LAN адресе тунел.

Затим посматрајте пакете. Снимак на тунелском интерфејсу показује да ли сервер преноси ка клијенту, а снимак на LAN интерфејсу показује да ли прослеђује. Ако први показује пакете, а други ништа, проблем је у прослеђивању или филтеру; ако ни један ни други не показују ништа, претрага није успела раније.

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