Чаму адзін 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, які накіроўвае запіс на тунель па імені. Імпарцёры розняцца ў тым, ці перакладаюць яны гэты варыянт, таму агледзіце захаванае злучэнне, калі запіс адсутнічае ў табліцы ядра.
Правярайце пошукам маршрутаў, а не пінгам
Пінг кажа вам, што нешта адказала. Пошук маршруту кажа, які інтэрфейс выбера ядро, і гэта тое пытанне, якое вы насамрэч задалі. Чатыры кароткія каманды аддзяляюць адсутны маршрут ад маршруту, які паказвае на няправільную прыладу.
Прачытайце, што ўсталяваў тунель, з дапамогай ip route show dev tun0. Поўная адсутнасць вываду азначае нуль маршрутаў, а гэта не працоўны раздзелены тунель, і гэта звычайны вынік дадання фільтра без яўнага радка.
Затым праверце адзін офісны адрас з ip route get 10.30.5.7 і адзін звычайны інтэрнэт-адрас з ip route get 1.1.1.1. Другі павінен называць фізічны інтэрфейс; калі ён называе тунель, штуршок зусім не быў адфільтраваны.
Нарэшце прачытайце ip rule, бо правіла палітыкі, пакінутае папярэдняй спробай, можа перакрыць табліцу, якую вы толькі што выправілі. Правільны профіль са састарэлым правілам зверху выглядае гэтак жа, як зламаны профіль. Выдаліце правіла, якое вы дадалі ў мінулы раз, перш чым дадаць яшчэ адно.
Перакрыжаваныя падсеткі выглядаюць як зламаны тунель
Два прыватныя дыяпазоны могуць быць аднолькавымі з пункту гледжання кліента, і менавіта тут раздзелены тунель вінавацяць у тым, чаго ён не выклікаў. Калі офіс выдае той жа прэфікс, што і ваш хатні маршрутызатар, маршрут тунеля пакрывае маршрутызатар, і хатняя сетка выглядае як зніклая.
Параўнайце адрас на сваім інтэрфейсе з маршрутам, які ўсталёўвае профіль, выкарыстоўваючы звычайны спіс адрасоў, перш чым нешта змяняць. Перакрыццё рэальнае, і ніводная опцыя профілю яго не вырашае. Што вы можаце выправіць — гэта назвы, каб наступны чалавек бачыў два дыяпазоны, а не адзін.
Сумленныя выпраўленні — гэта перанумараваць адзін бок або перакласці адрасы ў офісе. Прышпільванне аднаго маршруту хоста да маршрутызатара працуе, пакуль адрас маршрутызатара не зменіцца, а потым гэта робіцца другой загадкай зверху першай.
Зрабіце так, каб рашэнне перажыло перападлучэнне
Запісы, набраныя ўручную, не перажываюць перападлучэння, а менеджар злучэнняў перабудоўвае табліцу кожны раз, калі профіль запускаецца. Змясціце рашэнне туды, дзе ствараецца злучэнне, ці то профіль, ці захаваныя налады менеджара. Затым перазапусціце злучэнне адзін раз наўмысна, а не выяўляйце паводзіны падчас выкліку. Профіль, які працуе толькі да наступнага перападлучэння, не скончаны.
Праверце тры шляхі адначасова: офісны хост па літаральным адрасе, той жа хост па імені і звычайны публічны сайт. Сярэдні залежыць ад службы імёнаў, якую вы наладзілі пасля адмовы ад прасунутых параметраў DNS, і менавіта ён ціха правальваецца.