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