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