Эмне үчүн экинчи 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 маршруттарын бериңиз жана демейкиге ээ болбошу керек профиль үчүн бөлүнгөн туннелди күйгүзүңүз.

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

Бөлүнгөн туннель муну өзгөртөт: таблицага сервер түрткөн префикстер гана түшөт, бул демейкини биринчи туннелде калтырат. Эгер эки сервер тең демейки маршрутту түртсө, долбоор баары бир ишке ашпайт, анткени анда акыркы байланыш жеңет жана кардар тараптагы эч бир жөндөө муну өзгөртпөйт. Сервер тараптагы pushту оңдожуңуз же бир ээни кабыл алыңыз.

Колдонмо аркылуу иштетилген профилдер — башка функция жана билүүгө татыктуу: Windows профили аталган аткарылуучу файл иштетилгенде башталышы мүмкүн, ал эми трафик чыпкалары эмнени ташырын чечет. Бул firewall эрежеси эмес, профиль жөндөөсү, жана демейки маршрут кагылышуусунан башка маселени чечет.

Linux: экинчи туннелди негизги таблицадан тышкары кармаңыз

Бир машинада openvpn --config эки нускасын иштетүү эки кардарды бир таблицага салат, ал эми үч вариант аларды өсүп жаткан обочолонуу менен бөлөт. Эң жеңили — экинчи кардарга таблицаны такыр оңдоого тыюу салуу: ачык маршруттар менен route-nopull, же ниет кылганыңызды гана орнотуучу route-up скрипти. Анда экинчи туннель так сиз атаган префикстерди ташып, башка эч нерсени ташыбайт. Анда кайсы префикстин кайда барарын кийин ачуунун ордуна өзүңүз чечесиз.

Саясаттык маршруттоо — ортолук вариант. Эреже бир булак дареги же firewall белгиси үчүн өзүнчө таблица тандайт, жана ошол таблица экинчи туннелдин маршруттарын ташыйт. Тескери жол чыпкалоо бул жерде тузак, анткени таблица тандаган интерфейстен башка интерфейске келген жооп ыргытылат, ошондуктан туннель бузулду деп жыйынтык чыгарбоодон мурун 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 жолун жазып алыңыз. Ошол үч факт кийинки окуяны иликтөөнүн ордуна издөөгө айландырат.