Зашто други 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 пут. Те три чињенице претварају следећи инцидент у претрагу уместо истраге.