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

Споља изгледају исто и траже различите поправке. Прочитајте дневник клијента на месту где се доноси одлука о рути.

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

Почните доказом да рута недостаје, а не да је покварена. На 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. Ако рута недостаје, прво поправите инсталацију. Ако постоји а саобраћај не успева, пређите на политику прослеђивања и заштитног зида.

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

Повезани чланци