Чаму маршрут VPN не паказвае шлюз у вывадзе ip route
Радок з прыладай і без шлюза — гэта прамы маршрут, а не зламаны. Прачытайце прызначэнне, dev і scope, затым пацвердзіце праз ip route get.
Табліцы маршрутызацыі часта чытаюць як зламаныя, калі слупок шлюза аказваецца пустым, хаця радок звычайна самадастатковы. Поле via з'яўляецца толькі тады, калі ядро перадае пакет адрасу наступнага пераходу; маршрут, прывязаны да інтэрфейса, дасягае сваіх прызначэнняў праз развязанне канальнага ўзроўню або праз аднарангавы вузел пункт-пункт. Чытанне слупкоў злева направа паказвае, у якім выпадку вы знаходзіцеся, і гэтае чытанне павінна адбывацца раней, чым хто-небудзь зменіць маршрут па змаўчанні. Большасць заявак пра адсутны шлюз заканчваецца менавіта на гэтым адрозненні.
Чытайце радок маршруту слупок за слупком
Кожны запіс пачынаецца з прызначэння і даўжыні яго прэфікса, затым дадае мадыфікатары ў фіксаваным слоўніку: via, dev, proto, scope, src і metric. Радок накшталт 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 шчыльны, але цалкам вызначаны. У ім нічога не бракуе, і ніякі адрас маршрутызатара не маецца на ўвазе.
Адсутнасць via — гэта цікавая частка. Без наступнага пераходу ядро развязвае прызначэнне непасрэдна на названым інтэрфейсе, што для тунэля азначае перадачу кадра тунэльнай прыладзе і дазвол інкапсуляцыі ўзяць справу на сябе. proto kernel фіксуе, што запіс быў усталяваны аўтаматычна пры прызначэнні адраса, а не набраны адміністратарам. scope link кажа, што прызначэнне дасягальна на гэтым канале без праходжання праз маршрутызатар, а src называе адрас, які ядро аддасць перавагу як крыніцу для адпаведнага трафіку.
Цяпер прачытайце маршрут па змаўчанні гэтак жа: default via 192.0.2.254 dev eth0 proto static metric 100. Тут via прысутнічае, бо пакет сапраўды патрабуе наступнага пераходу, і гэты пераход сам мусіць быць дасягальным на eth0. Гэтыя два радкі не з'яўляюцца варыянтамі аднаго і таго ж; яны адказваюць на розныя пытанні пра тое, куды ідзе трафік.
Дзве формы маршрутаў, якія блытаюць паміж сабой
Маршрут да падсеткі тунэля і маршрут па змаўчанні выглядаюць падобна на здымку экрана і паводзяць сябе зусім па-рознаму. Выкарыстоўвайце табліцу ніжэй як дапамогу для чытання палёў, а затым пацвердзіце фактычныя лікі на машыне, якую адладжваеце, замест таго каб давяраць узору з кіраўніцтва.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
Што табліца не можа сказаць, дык гэта намер. Прамы маршрут да прыватнага дыяпазону праз тунэль — гэта наўмысны дызайн раздзеленага тунэлявання; тая ж форма на хосте, які павінен адпраўляць усё праз VPN, з'яўляецца сімптомам. Намер жыве ў канфігурацыі, якая стварыла запіс, таму паглядзіце на інструмент, што яго ўсталяваў, перш чым рабіць выснову, што ядро нешта зрабіла няправільна.
Гэтак жа адсутны шлюз не дае дазволу выдумаць яго. Калі маршрут сапраўды патрабуе наступнага пераходу, гэты пераход мусіць быць дасягальным на інтэрфейсе, які яго нясе, а для тунэля пункт-пункт адрас аднарангавага вузла — не той самы аб'ект, што лакальны адрас. Стаўленне да лакальнага адраса тунэля як да Ethernet-маршрутызатара — распаўсюджаны спосаб атрымаць маршрут, які выглядае правільным і нічога не перасылае.
Спытайце ядро, які радок яно сапраўды выкарыстае
Чытанне табліцы — не тое самае, што выкананне пошуку, бо ядро звяртаецца да правілаў палітыкі, некалькіх табліц і кэшаваных запісаў, перш чым адказаць. Дзеяслоў, які выконвае сапраўдны пошук, — ip route get, і ён друкуе маршрут, які возьме пакет з такімі ўласцівасцямі.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0Падстаўце прызначэнне, якое вас сапраўды цікавіць, затым дадайце from або iif, калі трафік выбраны па крыніцы ці перасылаецца, бо звычайны лакальны пошук можа выбраць іншы шлях, чым перанакіраваны кліент. Адказ называе інтэрфейс, абраны адрас крыніцы і любы наступны пераход, што ёсць той жа інфармацыяй, з якой пакет быў бы маршрутызаваны ў той момант.
Калі адказ вас здзіўляе, надрукуйце правілы перад любымі зменамі: ip -4 rule show пералічвае іх у парадку прыярытэту, а кліент VPN, які ўсталёўвае ўласную табліцу або правіла для памечаных пакетаў, зусім не з'явіцца ў асноўнай табліцы. Пералік усіх табліц закрывае гэтую прагаліну.
ip -4 route show table all | grep -E 'tun|default'Праверце ніжні ўзровень, перш чым замяніць маршрут па змаўчанні
Уласныя пакеты тунэля мусяць дасягнуць аддаленага канчатковага пункта, і яны робяць гэта праз фізічны інтэрфейс, выкарыстоўваючы маршрут, які існаваў да ўздыму VPN. Замена ўсяго маршруту па змаўчанні без замацавання гэтага пункта адпраўляе інкапсуляваныя пакеты ў тунэль, які яны павінны пабудаваць, і злучэнне развальваецца. Спачатку пацвердзіце шлях да пункта пошукам толькі па адрасе пункта.
Трымайце тры рэчы асобна, калі ўносіце змену: маршрут да пункта, які мусіць застацца на фізічным інтэрфейсе, прыватныя дыяпазоны, што павінны ўвайсці ў тунэль, і маршрут па змаўчанні, які вырашае ўсё астатняе. Раздзяліце іх у гэтым парадку, ужывайце па адным за раз і паўтарайце пошук пасля кожнага кроку. Няўдалы ping пасля гэтага сам па сабе даказвае вельмі мала, бо дазволы, маршрутызацыя адказаў, DNS і сам сэрвіс — усё знаходзіцца ніжэй за правільны маршрут.
Запішыце чатыры значэнні, якія радок даў вам да змены: прызначэнне, наступны пераход або яго адсутнасць, прылада і абраная крыніца. Калі пазнейшая змена зрушыць любое з іх, вы ведаеце, якое рашэнне было сапраўды зменена, і можаце аднавіць адзін запіс замест здагадак пра ўсю табліцу.