OpenVPN уште турка стари рути? Проверете што вчитал

Додавате рута, го рестартирате сервисот, се поврзувате повторно, а табелата на клиентот изгледа точно како порано. Можат да бидат точни две различни нешта: серверот не ја вчитал вашата измена или клиентот не го инсталирал тоа што го добил. Заедничко им е само симптомот, па првиот чекор е да откриете кој од двата случаи го имате.

Споредбата подолу оди од процесот кон надвор, бидејќи процесот е единствениот авторитет за тоа која датотека важи.

Датотеката што ја уредивте и датотеката што ја чита процесот

Започнете со unit и командната линија што ја создал. На systemd домаќин systemctl cat openvpn@server ја печати линијата ExecStart, а instance unit обично ја изведува својата конфигурациска патека од името на инстанцата, па демонот стартуван како openvpn@office чита друга датотека од оној стартуван како openvpn@server. Споредете го тоа со argv на процесот што работи. Алатката за управување со конфигурација додава уште еден начин да се изгуби измената: може да напише точна датотека на место што unit никогаш не го споменува, и тогаш успешното распоредување изгледа како ништо.

Временските ознаки тоа брзо го решаваат: ако датотеката е понова од времето на стартување на процесот, процесот не можел да ја прочита. Фирмверот на рутерот додава трет случај, бидејќи многу модели ги чуваат поставките во flash и ја преизградуваат конфигурацијата при подигнување, што уредувањето датотека на дискот го прави сосема погрешен слој.

Што турка серверот и што инсталира клиентот

Турканата рута мора да помине два филтри. На серверот таа мора да стои во вчитаната конфигурација, а не во коментиран блок или во датотека специфична за клиент чие име не се совпаѓа. На клиентот pull мора да биде вклучен и ниту еден pull-filter не смее да ја отфрли опцијата. Поврзете се со verbosity 4 и прочитајте ги турканите опции што ги пријавува клиентот: ако рутата се појавува во таа листа, серверот ја завршил својата работа, а клиентот избира да не ја инсталира.

Датотеките специфични за клиент се чест извор на забуна. Датотека именувана по common name на сертификатот турка опции само до тој клиент, а разлика од еден знак тивко го запира туркањето, без грешка на ниту една страна. Серверот го запишува common name што го видел при поврзувањето, затоа споредете ја таа вредност со името на датотеката, а не со она што мислите дека е името на клиентот.

Турканиот префикс и повратната рута се различни проблеми

Клиент што намерно го игнорира redirect-gateway за да ја задржи својата локална интернет патека создава втора, неповрзана празнина. Сондите на серверот стигнуваат до адресата на тунелот, а одговорите никогаш не пристигнуваат, бидејќи одговор упатен до IP на тунелот на серверот се рутира низ обичниот стандарден портал на клиентот. Турканата рута за подмрежата не е виновна овде; она што недостасува е рута што сообраќајот за тунелската мрежа на серверот го враќа назад низ тунелскиот уред.

Додавањето на таа рута на клиентот ги поправа одговорите на сондите што ги започнува серверот. Таа не ја заменува турканата рута за подмрежата, а обратното исто така важи, бидејќи двете опишуваат спротивни насоки на движење.

Споредете ги табелите на двата краја

По секоја измена поврзете се повторно и прочитајте ја табелата на клиентот за турканиот префикс и за тунелскиот уред. Потоа тестирајте во двете насоки: од клиентот до домаќин во турканата подмрежа и од тој домаќин назад до клиентот. Рута што постои, но не пренесува сообраќај, значи едно од три: далечната страна не препраќа, огнен ѕид го фрла текот или одговорот нема пат назад.

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

Овие три го претвораат следниот случај во петминутна проверка наместо уште една истрага, и токму тие му се потребни на колега кога тунелот станува туѓ проблем.

Проблем со рута што го преживува рестартирањето често воопшто не е проблем со рутирање; дефектот е повисоко од табелата што постојано ја читате.