Одвојен излаз: VPN базен на usb0, саобраћај пролаза на eth0
Прослеђени VPN клијенти могу да излазе преко usb0 док пролаз задржава своју подразумевану путању на eth0. Изградите потпуну изабрану табелу, а затим учините да отказ затвара уместо да пропушта.
Клијенти се повезују и проверавају идентитет, а затим њихов саобраћај излази кроз погрешан узводни линк, јер једина подразумевана путања на уређају припада самом пролазу. Замена те подразумеване путање покварила би сопствена ажурирања уређаја и приступ за управљање, па избор мора бити ужи од „саобраћаја у целини“. Радни облик је правило политике везано за унутрашњу изворну адресу базена клијената, које показује на другу табелу рутирања која поседује алтернативни WAN. Одатле па надаље контролна листа говори о потпуности и понашању при отказу, не о самом правилу.
Потврдите да изворна адреса преживљава до одлуке о рутирању
Правило политике које одговара опсегу извора активира се само када пакет у тренутку претраге још носи тај извор. Прослеђени саобраћај клијената то чини, све док га нешто изнад није преписало пре рутирања. Саобраћај који сам пролаз ствара то не чини, и управо зато његова сопствена подразумевана путања може остати на месту.
Овде локални тестови обмањују. curl покренут на пролазу је локално створен ток са адресом пролаза, па узима главну табелу и ништа не доказује о путањи клијента. Тестирајте са повезаног клијента или створите саобраћај са извором који заиста припада базену.
Почните тако што ћете записати стварне вредности: префикс базена, интерфејс тунела који га носи, адресу и следећи скок другог WAN-а, и број табеле који намеравате да користите. Очистите стара правила из сваког претходног покушаја пре него што додате нова, јер дуплирана правила на различитим приоритетима дају отказе који изгледају случајно.
Изградите изабрану табелу која је потпуна
Табела није подразумевана путања са пријатељем. Потребно јој је довољно путања да се свака претрага реши унутар ње, укључујући повезану путању за WAN подмрежу да би следећи скок био достижан. За базен 10.77.0.0/24 на tun1, адресу WAN 203.0.113.20/24 са следећим скоком 203.0.113.1 и табелу 600:
ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600
Правило стоји на приоритету испод сваког постојећег правила које хвата све, па одговарајући клијенти прво погађају табелу 600, а све остало пада у главну табелу. Референца за ip-rule у потпуности описује модел уређене претраге и синтаксу селектора.
Затим размислите шта табела не садржи. Одредиште које има путању само у главној табели, као што је подмрежа за управљање доступна кроз eth0, неће бити нађено у табели 600 и неће се вратити у главну када тамо постоји подразумевана путања. Ако су ти путеви важни, додајте их изричито у изабрану табелу, што је обично тачан одговор за табелу излаза VPN-а.
Држите сопствени саобраћај слушаоца изван политике
Слушалац OpenVPN има своју спољну везу, ношену оним узводним линком којим га је клијент достигао. Тај саобраћај мора да задржи повратни пут са којим је стигао, а широко правило које покрива јавну адресу сервера или цео интерфејс тунела може га увући у алтернативну табелу. Ограничите правило на унутрашњи базен и ништа друго.
Филтрирање повратног пута заслужује поглед из истог разлога. Када одговори клијентима излазе кроз usb0 док је захтев стигао другим линком, строго подешавање rp_filter може одбацити пакете које политика рутирања сматра важећим. Проверите важеће sysctl вредности на оба интерфејса пре него што закључите да је правило подбацило.
Редослед је важан и у односу на све остало на уређају. Docker мостови, други VPN и сва постојећа правила из имиџа добављача додају приоритете, па прочитајте цео списак правила уместо да претпоставите да је приоритет 100 сам.
Ускладите прослеђивање и превођење са путањом
Рутирање бира узводни линк; оно не даје дозволу за прослеђивање. Језгро мора да има омогућено прослеђивање IPv4, а заштитни зид мора да прихвати смер од клијента ка WAN-у и повратни саобраћај. Исправна табела са FORWARD ланцем који одбацује ток даје исти симптом као путања која недостаје, зато се обоје проверава у истом пролазу.
Ако други WAN не буде рутирао приватни базен назад ка вама, преведите извор на том излазу. За интерфејс са динамичком адресом уобичајен избор је уско masquerade правило ограничено на базен и интерфејс:
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE
Овде је обухват важнији од циља. Masquerade правило које одговара било ком излазном интерфејсу преписаће и саобраћај који исправно излази кроз eth0, а то скрива грешке рутирања уместо да их исправи. Превођење се извршава после одлуке о рутирању, па никада не може поправити пакет послат на погрешан узводни линк.
И трошак тунела тражи пажњу када се путање разликују. Ако клијенти уговоре велики TCP MSS, а алтернативни WAN има нижи MTU или тунел у себи, велики сегменти застају док мали раде. Ограничавање MSS-а на путу прослеђивања претвара то у предвидиво понашање уместо повременог заглављивања.
Одлучите шта се дешава када usb0 нестане
Празна табела није стање затварања при отказу. Ако одговарајућа путања нестане, претрага се наставља на следеће правило, стиже до главне табеле и узима подразумевану путању eth0. Саобраћај који је требало да изађе кроз други WAN тихо излази кроз први, што је при распоређивању са рутирањем по политици обично резултат који најмање желите.
Тамо где такав повратак није прихватљив, додајте изричиту терминалну путању у табелу 600, на пример подразумевану путању blackhole, или одбаците базен у заштитном зиду док је интерфејс искључен. Свака од две опције је одлука коју можете записати; ћутање није.
Трајност је последња ставка. Ко год поседује оба линка, било да је менаџер мреже, скрипта пошиљаоца или животни циклус везе, мора при сваком поновном повезивању изнова да створи путање и правило без додавања дупликата. Проверите захтевом од стварног клијента и одвојеним захтевом са пролаза, потврдите примећени излаз у оба случаја, затим извуците други WAN и погледајте који се од два пројектована резултата заиста дешава. IPv6 захтева сопствену табелу, правило и превођење; горе наведено IPv4 правило ништа не говори о томе.