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

Претрага се дешава пре него што се извор препише

За пакет који се прослеђује од VPN клијента, језгро извршава фиксни след. Долази на интерфејс тунела, пролази кроз prerouting где живе conntrack и DNAT, затим се доноси одлука о рутирању, затим прослеђивање, затим postrouting где се SNAT примењује последњи. Правило облика from разматра се током те одлуке о рутирању, што значи да види изворну адресу клијента, а не преведену.

Додавање masquerade правила дакле не мења то која политика одговара одлазном току. Мења се оно што види удаљени крај, и тиме која повратна путања постоји. То су две различите последице и прегледи промена их стално мешају. Раздвојите их и дизајн обично постане јасан у року од минута.

У смеру одговора преведена адреса се појављује у правилима. Пакет који се враћа на гејтвеј адресиран је на преведену адресу, и ако имате правила политике заснована на одредишту или на интерфејсу преко ког је ушао, то је вредност коју ћете упарити. Иста веза, различит извор истине у сваком смеру.

StageSource the kernel seesWhat it means for your rule
PreroutingClient address, 172.31.7.42Where marks and DNAT are applied
Routing decisionStill 172.31.7.42This is where from rules match
PostroutingBecomes 198.51.100.9What the far end and its return route see

Два пула са различитим изворима заиста захтевају различите табеле и дизајн је исправан. Оно што табела горе искључује јесте пречица да се грешка тражи гледањем шта је примило удаљено одредиште и извлачењем правила из тога.

Тест са гејтвеја није тест пула

Саобраћај који гејтвеј сам ствара никада не пролази кроз prerouting јер није стигао на интерфејс. Рутира се у излазној путањи, са адресом самог гејтвеја као извором, а правило from везано за опсег клијената неће се поклопити. Сваки тикет у овој области који каже да ради са кутије али не са клијента само је препричавање те чињенице.

Симулирајте клијента уместо да га апроксимирате. Одлука о рутирању може се питати директно, уз задат извор и улазни интерфејс:

ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201

Покрените то једном по пулу. Ако две команде врате исти интерфејс, правила не раздвајају пулове, а разлог је или правило које недостаје или правило вишег приоритета које одговара обема. Ако врате различите интерфејсе али клијент и даље не ради, квар је низводно од претраге и можете престати да гледате правила.

Приоритет, а не позиција у датотеци

Правила се оцењују у растућем редоследу приоритета, а број је оно што је важно, не редослед којим сте их уписали. Табела local стоји на приоритету 0, табела main на 32766, а подразумевано правило на 32767, зато правило додато са подразумеваним приоритетом пада близу краја списка и губи од готово свега.

ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201

Експлицитни приоритет чини намеравани редослед видљивим у датотеци и при прегледу. Такође спречава да каснији додатак тихо прескочи постојеће правило, што је најчешћи узрок тога да политика која ради престане да ради после неповезане промене.

Подударно правило које показује на непотпуну табелу друга је замка. Ако табела 201 садржи подразумевану руту али не и руту до одредишта, пакет се одбацује или шаље на погрешно место, а правило изоловано изгледа потпуно исправно. Читајте табелу, не само правило. Правило је показивач, а празна табела је показивач у ништа.

Повратна путања ипак мора да постоји

Политика извора бира излаз. Она не ствара повратну путању. Ако други пул излази кроз партнерски тунел, партнер мора да зна како да дође до 172.31.8.0/24, било рутом назад ка гејтвеју, било примањем преведених адреса које већ познаје.

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

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

Не хватајте сопствени тунел гејтвеја у политици

Правила која пишете за клијенте важе и за саобраћај који гејтвеј ствара, осим ако га изузмете. Широко правило везано за ознаку или за излазни интерфејс може да ухвати сопствену везу гејтвеја са партнером, и тада тунел који носи политику бива рутиран политиком. То ствара петљу или прекид који изгледа као квар добављача.

Ограничите свако правило што је могуће уже: префикс извора, улазни интерфејс и, где је подржано, ознака коју носе само клијентски пакети. Затим тестирајте сопствену повезаност гејтвеја после сваке промене правила, јер је квар самореферентан и не појављује се у тесту са клијента.

Страница приручника за ip-rule документује семантику селектора и приоритета. Комбинујте је са тестом претраге по пулу и дизајн постаје проверљив, што је разлика између политичког рутирања које преживи годину и оног које се сви боје да дотакну.

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