Одделен излез: 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 погоре не кажува ништо за тоа.