PPP peer адреса или VPN крајња тачка: која иде у via

Упоредите читање PPP интерфејса као подмреже са читањем његових inet и peer као два краја везе, и видите који следећи скок табела политике може прихватити.

Једна линија на PPP интерфејсу решава највећи део расправе о рутирању на VPN кутији: унутрашња адреса и peer исписан поред ње. Прочитајте тај пар као сићушну подмрежу и тражићете gateway који не постоји. Прочитајте га као два краја једне везе и следећи скок постаје очигледан. Поређење овде је између та два читања, јер свака табела коју после изградите наслеђује оно које сте одабрали. Ништа о спољној VPN крајњој тачки не одлучује ниједно од њих.

Два читања једне линије интерфејса

Узмите сесију у којој интерфејс пријављује inet 10.64.3.9 peer 10.64.3.1/32. Читање као подмрежа третира 10.64.3.9 као усамљеног хоста на /32 острву и затим тражи рутер да би досегло било шта изван њега. Пошто је једина друга адреса на вези peer, то читање на крају предлаже 10.64.3.9 сам као gateway, што је циркуларно.

Читање као крајња тачка је оно документовано. На point-to-point интерфејсу 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 не носи gateway јер је сам интерфејс пут. Рута која именује peer са via је други објекат с другим животним веком, и нестаје кад сесија падне. Копирање било ког од та два облика у трајну табелу без провере како се поново инсталира уобичајен је разлог зашто радни тунел изгуби руту након поновног повезивања.

Упоредите два списка уместо да верујете памћењу. Ако рута peer-а постоји у main али ваша додатна табела је празна, научили сте нешто што вам линија адресе никада није рекла.

Правило и табела су одвојене одлуке

Избор табеле и њено пуњење су независни кораци, а поређење је овде важно јер се то двоје често побрка при отклањању грешака. Правило које шаље означен саобраћај у табелу 100 не чини ништа ако табела 100 нема одговарајућу руту, а добро попуњена табела је недоступна ако ниједно правило не показује на њу.

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

Повезани чланци