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

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

Един клиент може да притежава няколко префикса. Добавете по един ред iroute за всяка мрежа и дръжте списъка до останалите настройки на този клиент, за да остане свързването проверимо.

Изграждане на обратния път в двете посоки

Доставянето на пакети до отдалечената LAN е половината работа. Клиентът също трябва да изпраща трафика на тази LAN в тунела, което обикновено се прави чрез избутване на маршрут към клиента: ред като push "route 10.8.0.0 255.255.255.0" казва на всеки клиент как да достигне мрежата от страна на сървъра. За клона еквивалентният маршрут сочи към тунела за всичко, което трябва да достигне от страна на сървъра.

Обратната посока се нуждае от собственик на далечната страна. Там някой трябва да знае пътя обратно: статичен маршрут на LAN рутера, който насочва VPN пула към сървъра, или транслация на адреси на сървъра, преди трафикът да влезе в LAN. Статичният маршрут запазва оригиналните адреси видими в логовете и правилата за достъп, но изисква съдействието на собственика на LAN; транслацията е самостоятелна, но скрива кой всъщност се е свързал.

Препращането трябва да е включено на хост сървъра. Без него ядрото приема пакета от тунела и отказва да го предаде към LAN интерфейса, което от гледна точка на клиента изглежда точно като липсващ iroute.

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

Тествайте на слоеве, вместо да пингвате далечния край и да гадаете. От сървъра проверете, че вътрешното свързване за префикса съществува и че маршрутът на ядрото сочи към тунела. От клиента потвърдете, че избутаният маршрут е инсталиран и че пътят му по подразбиране за LAN адреса е тунелът.

След това наблюдавайте пакетите. Прихващане на тунелния интерфейс показва дали сървърът предава към клиента, а прихващане на LAN интерфейса показва дали препраща. Ако първото показва пакети, а второто не, проблемът е в препращането или във филтър; ако нито едно не показва нищо, търсенето се е провалило по-рано.

Два сървъра, свързани с тунел, повтарят същото правило от двете страни: всеки се нуждае от iroute за пула на другия и от маршрута и препращането, които правят пътя симетричен. Маршрутизирането и политиката са отделни въпроси тук. Маршрутизирането решава накъде може да отиде пакетът, а правило FORWARD решава дали може, затова клиент с два реда iroute може да достигне и двата префикса, освен ако филтър не каже друго.