Рутирање по извор за два VPN базена: што пропушта вашето правило

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

Пребарувањето се случува пред изворот да се препише

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

Затоа додавањето masquerade правило не менува која политика одговара на излезниот тек. Она што се менува е што гледа далечниот крај, а со тоа и кој повратен пат постои. Тоа се две различни последици, и прегледите на промени постојано ги мешаат. Одделете ги и дизајнот обично станува јасен во рок од една минута.

Токму во насоката на одговорот преведената адреса се појавува во правилата. Пакетот што се враќа на gateway е адресиран на преведената адреса, и ако имате правила за политика врз основа на дестинацијата или на интерфејсот преку кој влегол, таа е вредноста што ќе ја совпаѓате. Истата врска, различен извор на вистина во секоја насока.

Значи два базена со различни извори навистина бараат различни табели, и дизајнот е исправен. Она што табелата погоре го исклучува е брзиот пат да се дебагира гледајќи што примила далечната локација и од тоа да се изведе правилото.

Тестот од gateway не е тест на базенот

Сообраќајот што самиот gateway го создава никогаш не поминува низ prerouting, бидејќи не пристигнал на интерфејс. Се рутира во излезната патека, со адресата на самиот gateway како извор, а правилото 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, или со повратна рута до gateway, или примајќи преведени адреси што веќе ги знае.

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

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

Не го фаќајте сопствениот тунел на gateway во политиката

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

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

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