Адрас peer у PPP ці канцавы пункт VPN: што пісаць у via

Адзін радок на PPP-інтэрфейсе вырашае большую частку спрэчкі пра маршрутызацыю на машыне VPN: унутраны адрас і peer, надрукаваны побач. Прачытайце гэтую пару як крохкую падсетку, і вы будзеце шукаць шлюз, якога не існуе. Прачытайце яе як два канцы аднаго канала, і наступны пераход стане відавочным. Параўнанне тут паміж гэтымі двума чытаннямі, бо кожная табліца, пабудаваная потым, наследуе абранае. Нішто пра знешні канцавы пункт VPN не вырашае ніводнае з іх.

Два чытанні аднаго радка інтэрфейса

Вазьміце сеанс, у якім інтэрфейс паведамляе inet 10.64.3.9 peer 10.64.3.1/32. Чытанне як падсеткі абыходзіцца з 10.64.3.9 як з адзінотным хостам на востраве /32, а потым шукае маршрутызатар, каб дасягнуць чагосьці за яго межамі. Паколькі адзіны іншы адрас на канале — гэта peer, такое чытанне ўрэшце прапануе сам 10.64.3.9 як шлюз, што з'яўляецца замкнёным колам.

Чытанне як канцавой кропкі — дакументаванае. На інтэрфейсе «кропка-кропка» peer называе аддалены канец гэтага адзінага канала, таму 10.64.3.1 з'яўляецца прыдатным наступным пераходам, а 10.64.3.9 заўсёды толькі адрас крыніцы.

Гэтая розніца вызначае, што можа стаяць у via. Запіс туды лакальнага адраса дае маршрут, які ядро не можа супаставіць з суседам, таму запіс або не праходзіць праверку, або праглынае трафік, выглядаючы пры гэтым у спісе цалкам здаровым. Peer працуе таму, што гэта сапраўдны пункт прызначэння на канале. Абодва чытанні згодныя наконт знешняга канцавога пункта VPN, які з'яўляецца цалкам асобнай сутнасцю: да яго дабіраюцца праз underlay, а не праз тунель, які ён завяршае.

Што сеанс ужо ўсталяваў

Перш чым пісаць уласную табліцу, вывядзіце тое, што прыйшло разам з каналам. Падтрымліваная інтэграцыя PPP звычайна ўсталёўвае маршрут прылады і маршрут да peer падчас наладкі сеансу, і гэтыя два запісы ўжо ўтрымліваюць правільнае чытанне.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

Маршрут прылады выгляду 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 не нясе шлюза, бо сам інтэрфейс з'яўляецца шляхам. Маршрут, які называе peer праз via, — гэта іншы аб'ект з іншым часам жыцця, і ён знікае, калі сеанс падае. Капіяванне любой з дзвюх форм у пастаянную табліцу без праверкі таго, як яна пераўсталёўваецца, — звычайная прычына, чаму працоўны тунель губляе маршрут пасля перападключэння.

Параўнайце два спісы, а не спадзявайцеся на памяць. Калі маршрут да peer ёсць у main, а ваша дадатковая табліца пустая, вы даведаліся тое, чаго радок адраса вам ніколі не казаў.

Правіла і табліца — асобныя рашэнні

Выбар табліцы і яе запаўненне — незалежныя крокі, і параўнанне тут важнае, бо падчас адладкі гэтыя двое часта блытаюць. Правіла, якое адпраўляе пазначаны трафік у табліцу 100, нічога не робіць, калі ў табліцы 100 няма адпаведнага маршруту, а добра запоўненая табліца недасягальная, калі на яе не паказвае ніводнае правіла.

Палова маршруту па змаўчанні — не маршрут па змаўчанні. Адзін 0.0.0.0/1 пакрывае ніжнюю палову прасторы IPv4, таму палітыцы, якая мае намер захапіць усё, патрэбны і адпаведны 128.0.0.0/1, або сапраўдны default. Прачытаць працоўную канфігурацыю і скапіяваць адну з дзвюх палов — так людзі і атрымліваюць пятлю маршрутызацыі, якая ламаецца толькі на пэўных адрасах.

Пакіньце наўмысныя выключэнні для адрасоў, якія мусяць застацца ў LAN, і вырашыце, што адбываецца, калі пошук нічога не знаходзіць у абранай табліцы. Яўны рэзервовы маршрут лягчэй асэнсаваць, чым пустая табліца, якая вяртае недасяжны вынік і прымушае праграму выглядаць зламанай, а не накіраванай не туды.

Задайце пошуку тое пытанне, якое задае ваша праграма

ip route get развязвае шлях; ip route show выводзіць захаваныя запісы, і гэтыя двое могуць разыходзіцца, хоць ніводзін не памылковы. Укажыце кантэкст крыніцы, бо правілы на аснове крыніцы супадаюць толькі тады, калі пошук нясе крыніцу.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

Першая каманда ставіць пытанне з боку хоста. Другая дадае ўваходны інтэрфейс, што бліжэй да таго, што перажывае перанакіраваны трафік, і адказ часта паказвае на іншую табліцу. Ніводзін з адрасоў не з'яўляецца жывым тэставым сэрвісам; 198.51.100.23 — гэта адрас для дакументацыі, таму заменіце яго на хост, які вам дазволена правяраць.

Нават правільны пошук даказвае толькі тое, што шлях быў абраны. Ён нічога не кажа пра тое, ці прымае процілеглы бок трафік або ці можа адказ вярнуцца тымі ж разважаннямі.

Дзе параўнанне перагортваецца

Трафік хоста і перанакіраваны трафік выбіраюць не толькі розныя пошукі; на зваротным шляху яны сустракаюць розныя фільтры. Linux прымяняе праверку зваротнага шляху па больш строгім з значэнняў для ўсіх інтэрфейсаў і для прымальнага інтэрфейсу, таму змена значэння аднаго інтэрфейсу можа не даць бачнага эфекту. Маршрутызацыя па метцы дадае адносіну src_valid_mark, у якой метка мусіць супадаць, каб крыніца лічылася дапушчальнай.

Калі адказы знікаюць, а выходная маршрутызацыя выглядае правільна, прачытайце дзеючыя значэнні, перш чым іх чапаць, і змяняйце іх толькі з заяўленай прычыны палітыкі.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

Выбірайце паміж двума схемамі на падставе доказаў: калі праграма прывязаная да адраса PPP, дастаткова правіла крыніцы і табліцы з маршрутам да peer. Калі машына перанакіроўвае трафік для LAN ззаду сябе, патрэбна яшчэ, каб уваходны кантэкст і зваротны шлях супадалі. Калі яны не супадаюць, выпраўце належнасць маршруту, а не паслабляйце праверку для ўсёй машыны.