Защо само route-nopull оставя файловия сървър недостъпен
Игнорирането на изпратените маршрути е само половината от разделен тунел. Изберете собственика на маршрутите, добавете офис префикса на ръка и проверете три потока, преди да го смятате за поправено.
Файловият сървър се отваря нормално, а видеозвънокът в съседния прозорец започва да накъсва. Нищо не е бавно и MTU не е грешен: клиентът ви прие списъка с маршрути, който сървърът му подаде, така че всеки пакет вече излиза през офисната защитна стена. Поправката не е поредното флагче за настройка, а решение кой притежава таблицата с маршрути на клиента. Това решение принадлежи на едно място и режимите на отказ по-долу ви казват кое място всъщност сте избрали.
Решете кой притежава таблицата с маршрути
Възможни са три собственика. Сървърът може да изпраща маршрути и шлюз по подразбиране, при което клиентът инсталира каквото му кажат и става пълен тунел. Профилът на клиента може да поеме собственост, като отхвърля изпращанията и носи свои собствени редове за маршрути. Мениджърът на връзки на работния плот също може да притежава решението чрез своите свойства за маршрут и маршрут по подразбиране.
Всеки избор се проваля по различен начин, затова таблицата си заслужава да се прочете, преди да редактирате профил. Редът, който съвпада със симптома ви, е собственикът, който всъщност имате.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Изберете един и го запишете. Смесването на два оставя хост, чийто път по подразбиране противоречи на собствената му документация, и следващият инженер не може да каже кой слой е победил. Изтрийте губещия изрично.
route-nopull филтрира изпращанията, не добавя маршрути
route-nopull принадлежи в профила на клиента и редът му в този файл е без значение, защото той само отхвърля стойности, идващи от сървъра. Той отхвърля изпратени маршрути, включително изпратен маршрут по подразбиране, докато тунелът все пак се вдига нормално.
Последствието, което хората пропускат, е че изпратените DHCP опции вървят с тях. DNS настройките, изпратени от сървъра, също се отхвърлят, така че вътрешните имена спират да се разрешават, въпреки че тунелът е здрав и сървърът е достъпен по адрес.
Това оставя тунел без път до офис префикса, освен ако не добавите такъв сами: route-nopull последван от route 10.30.0.0 255.255.0.0 в същия профил. Този ред носи адрес и маска; той не назовава следващ хоп.
Алтернативна форма добавя токен за шлюз, route 10.30.0.0 255.255.0.0 vpn_gateway, който насочва записа към тунела по име. Импортерите се различават по това дали превеждат този вариант, затова прегледайте запазената връзка, ако записът липсва от таблицата на ядрото.
Проверявайте с търсения на маршрути, не с ping
Ping ви казва, че нещо е отговорило. Търсенето на маршрут ви казва кой интерфейс би избрало ядрото и това е въпросът, който всъщност зададохте. Четири кратки команди разделят липсващ маршрут от маршрут, който сочи към грешното устройство.
Прочетете какво е инсталирал тунелът с ip route show dev tun0. Пълната липса на изход означава нула маршрути, което не е работещ разделен тунел, и това е обичайният резултат от добавянето на филтъра без явния ред.
След това проверете един офис адрес с ip route get 10.30.5.7 и един обикновен интернет адрес с ip route get 1.1.1.1. Вторият трябва да назове физическия интерфейс; ако назове тунела, изпращането изобщо не е било филтрирано.
Накрая прочетете ip rule, защото правило за политика, оставено от предишен опит, може да отмени таблицата, която току-що коригирахте. Правилен профил със старо правило отгоре изглежда точно като счупен профил. Изтрийте правилото, което добавихте последния път, преди да добавите друго.
Припокриващите се подмрежи изглеждат като счупен тунел
Два частни диапазона могат да бъдат идентични от гледна точка на клиента и точно там разделен тунел бива обвиняван за нещо, което не е причинил. Ако офисът раздава същия префикс, който използва домашният ви рутер, маршрутът на тунела покрива рутера и домашната мрежа изглежда че изчезва.
Сравнете адреса на собствения си интерфейс с маршрута, който профилът инсталира, като използвате обикновен списък с адреси, преди да промените нещо. Припокриването е реално и никоя опция на профила не го решава. Това, което можете да поправите, е именуването, така че следващият човек да види два диапазона, а не един.
Честните поправки са да преномерирате една страна или да превеждате адреси в офиса. Закачането на един маршрут за хост към рутера работи, докато адресът на рутера не се промени, а после става втора загадка върху първата.
Направете така, че решението да преживее повторно свързване
Записите, въведени на ръка, не преживяват повторно свързване, а мениджърът на връзки преизгражда таблицата всеки път, когато профилът стартира. Поставете решението там, където се създава връзката, било то профилът или запазените настройки на мениджъра. След това рестартирайте връзката веднъж нарочно, вместо да откривате поведението по време на разговор. Профил, който работи само до следващото повторно свързване, не е завършен.
Изпробвайте три пътя наведнъж: офис хост по буквален адрес, същият хост по име и обикновен публичен сайт. Средният зависи от услугата за имена, която сте настроили, след като сте изхвърлили изпратените DNS опции, и именно той тихо се проваля.