OpenVPN продължава да налага стари маршрути? Проверете какво е заредил

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

Сравнението по-долу върви от процеса навън, защото само процесът знае кой файл е в сила.

Файлът, който редактирахте, и файлът, който процесът чете

Започнете с unit и командния ред, който той е създал. На хост със systemd systemctl cat openvpn@server отпечатва реда ExecStart, а unit на инстанция обикновено извежда пътя до конфигурацията от името на инстанцията, така че демон, стартиран като openvpn@office, чете различен файл от стартирания като openvpn@server. Сравнете това с argv на работещия процес. Инструментът за управление на конфигурация добавя още един начин да загубите промяната: може да запише правилния файл на място, което unit никога не споменава, и тогава успешен деплой изглежда като бездействие.

Времевите маркери решават бързо: ако файлът е по-нов от началния час на процеса, процесът не е могъл да го прочете. Фърмуерът на рутера добавя трети случай, защото много модели пазят настройките си във flash и преизграждат конфигурацията при зареждане, което прави редактирането на файл на диска напълно грешен слой.

Какво налага сървърът и какво инсталира клиентът

Наложеният маршрут трябва да премине през два филтъра. На сървъра той трябва да е в заредената конфигурация, а не в коментиран блок или във файл за конкретен клиент, чието име не съвпада. На клиента pull трябва да е включен и нито един pull-filter да не изхвърля опцията. Свържете се с verbosity 4 и прочетете наложените опции, които клиентът отчита: ако маршрутът е в този списък, сървърът си е свършил работата и клиентът избира да не го инсталира.

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

Наложеният префикс и обратният маршрут са различни проблеми

Клиент, който умишлено игнорира redirect-gateway, за да запази локалния си път към интернет, създава втора, несвързана празнина. Сондите на сървъра стигат до адреса на тунела, а отговорите така и не пристигат, защото отговор, адресиран до IP на тунела на сървъра, се маршрутизира през обикновения шлюз по подразбиране на клиента. Наложеният маршрут за подмрежата не е виновен тук; липсва маршрут, който връща трафика към мрежата на тунела на сървъра обратно през тунелното устройство.

Добавянето на този маршрут на клиента оправя отговорите на сондите, инициирани от сървъра. Той не замества наложения маршрут за подмрежата и обратното също е вярно, защото двете описват противоположни посоки на движение.

Сравнете таблиците в двата края

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

Дръжте три идентификатора заедно: път до конфигурацията, име на unit или инстанция и идентичността на клиента, с който сте тествали.

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

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