Маршрути турнати од OpenVPN не се инсталираат: време, права или политика

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

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

Докажете дека маршрутот недостасува, а не дека е само расипан

Започнете со докажување дека маршрутот недостасува, а не дека е расипан. На Linux, ip route show dev tun0 наведува што клиентот инсталирал на тунелскиот уред. На Windows, route print или Get-NetRoute го покажува истото во табеларна форма.

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

Време: додавањето се извршило пред уредот да постои

Клиентот го анализира PUSH_REPLY на серверот откако контролен канал е подигнат и откако ја конфигурирал интерфејсот. Само тогаш ја допира табелата за рутирање, со механизмот што платформата го нуди. Linux поминува низ netlink; Windows користи API што бара подигнат токен. Скрипта или клиент што додава маршрути штом ја прочита конфигурацијата може да се изврши пред да постои уредот TUN/TAP, и јадрото го одбива додавањето.

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

route-delay постои токму за овој случај, а route-up именува скрипта што се извршува откако интерфејсот и маршрутите се конфигурирани. Маршрутите што зависат од адресата на тунелот ставете ги во таа кука, а не во рана фаза.

Права: кој може да ја смени табелата

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

Стартувањето на GUI како администратор или користењето на клиентот заснован на услуга го менува тој исход. Закажана задача што го стартува клиентот без потребниот токен не го менува.

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

Политика: турнатите маршрути можат намерно да се отфрлат

route-nopull го тера клиентот да ги игнорира маршрутите што ги турка серверот, вклучително турнат стандарден маршрут, додека адресата на тунелот сѐ уште се прифаќа. Турнатите DNS и DHCP опции се отфрлаат со истата директива. Таков клиент не е дефектен; тој очекува јасни линии за маршрути во сопствената конфигурација.

route-noexec е друга контрола: целосно го спречува клиентот да извршува промени на маршрути. Топологија што клиентот не може да ја мапира може да даде сличен резултат, а маршрутот се запишува како одбиен, а не како додаден. Прочитајте ја линијата од дневникот што ја известува одлуката наместо да погодувате која од трите причини важи. Потоа проверете го ефективниот профил, бидејќи увозник или алатка за управување може да додаде опции што корисникот никогаш не ги уредил.

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

Споредете ја листата за туркање со табелата

По поврзувањето, ставете ја листата за туркање на серверот покрај табелата на клиентот. На Linux тоа е ip route show dev tun0; на Windows route print или Get-NetRoute. Ако маршрутот недостасува, прво поправете ја инсталацијата. Ако постои, а сообраќајот не успее, преминете на политиката за проследување и ѕид.

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