Зошто вториот VPN тунел го крши првиот?

Инсталирањето втор VPN клиент за да се стигне до една клиентска мрежа е вообичаениот начин како ова започнува, и првиот тунел се затемнува додека двата клиенти пријавуваат успех. Секој клиент инсталираше стандардна рута, втората беше поспецифична, и јадрото сега ја следи за сѐ освен сопствената надворешна врска на првиот тунел. Ништо не падна и ниту еден профил не е погрешен. Една рута замени друга, а решението е да се одлучи кој тунел треба да го поседува стандардот.

Симптомот: вториот клиент тивко победува

OpenVPN: опцијата redirect-gateway def1 не го препишува 0.0.0.0/0. Таа додава 0.0.0.0/1 и 128.0.0.0/1: заедно ги покриваат сите IPv4 адреси, и секој префикс по должина победува едноставен стандард. Оригиналниот стандард останува во табелата и престанува да се користи за обичен сообраќај, а хост-рута до VPN серверот го спречува тунелот да ги фати сопствените надворешни пакети. Двата клиенти го прават ова, а вториот едноставно го инсталира својот пар подоцна.

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

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

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

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

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

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

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

Windows: спречете еден профил да го поседува стандардот

Windows чува зачувани профили, а вградениот клиент дозволува еден да зависи од друг, така што првиот се подига автоматски кога вториот ѕвони. Профилот што се поврзал последен има тенденција да го задржи стандардот, па практичниот сопственик е последното поврзување, а не првото. Дајте му на секој профил свои push рути и вклучете split tunneling за оној што не треба да го поседува стандардот.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

Split tunneling го менува ова: во табелата влегуваат само префиксите што ги турка серверот, што го остава стандардот кај првиот тунел. Дизајнот сѐ уште пропаѓа ако двата сервери туркаат стандардна рута, бидејќи тогаш победува последната врска и ниту едно поставување на клиентската страна тоа не го менува. Поправете го push-от на серверската страна или прифатете еден сопственик.

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

Linux: држете го вториот тунел надвор од главната табела

Извршувањето две примероци на openvpn --config на една машина ги става двата клиенти во иста табела, и три опции ги раздвојуваат со растечка изолација. Најлесната е целосно да го спречите вториот клиент да ја уредува табелата: route-nopull со експлицитни рути, или route-up скрипта што инсталира само она што го намеравате. Тогаш вториот тунел ги носи точно префиксите што ги именувате и ништо друго. Тогаш вие одлучувате кои префикси каде одат наместо да го откривате подоцна.

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

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Мрежните именски простори се најтешката и најчистата опција. Стартувајте го вториот клиент внатре во ip netns, дајте му пар veth и влезете во тој именски простор за да го користите. Пречките исчезнуваат бидејќи секој именски простор има свои табели наместо да дели една, што вреди за дополнителното поставување кога двата тунели мора да останат подигнати со недели.

По апликација, и верижењето како одделен проблем

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

Верижењето е друга операција од извршување два тунели еден покрај друг. Да се верижи A над B значи дека адресата на внатрешниот сервер мора да биде достапна од внатрешноста на надворешниот тунел. Надворешниот клиент исто така не смее да ги смета шифрираните пакети на внатрешниот клиент за истекување. Еден клиент во виртуелна машина е грубата, но сигурна верзија; двете на еден домаќин бараат работата со рути погоре плус надворешна патека кон внатрешниот сервер што никогаш не влегува во внатрешниот тунел.

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