fwmark менен бир Linux хосттогу эки OpenVPN кардарын тизмектештирүү

Бир Linux хостко экинчи OpenVPN кардарын кошуу эки жердин биринде ийгиликсиз болот. Же ички кардар өз серверине жете албайт, анткени сырткы туннель ал ташыуну ээлеп алган, же экинчи кардар маршрут таблицасын кайра жазат да, биринчи туннель иштебей калат. Эки маселе тең маршруттоодо, шифрлөөдө эмес, жана экөө тең жаңы туннель кандайдыр бир колдонмо трафигин ташыганга чейин чечилет. Бул жердеги даректер мисал үчүн: tun0 — сырткы туннель, 203.0.113.9 — ички сервер, ал эми TCP 9999 — ички жолду колдонушу керек болгон агым.

Эки иштебей калуу режими, бир маршрут таблицасы

Ички кардар өз серверине UDP сокет ачат, жана ал сокет каалаган башка сыяктуу учурдагы маршрут таблицасын ээрчийт. Эгер сырткы туннель демейки маршрутту мурун ээлеп алса, кол алышуу пакеттери сырткы туннелге кирет. Бул сырткы сервер ички серверге жете алганда жана каршы тарап агымды ташууга макул болгондо гана иштейт; болбосо кол алышуу токтойт жана кардар кайра аракет кылат.

Экинчи ийгиликсиздик сервердин push-унан келет. Адаттагы push — redirect-gateway def1, ал демейки маршрутту алмаштыруунун ордуна 0.0.0.0/1 жана 128.0.0.0/1 орнотот. Ошондуктан өз /1 жупун орноткон эки кардар кагылышат, жана жаңы жуп дээрлик бардык бара турган жер үчүн жеңет. Экинчиси туташкандан кийин туннель өлсө, таблицадан ушул эки префиксти издеңиз, анткени демейки маршруттун өзү эч качан өзгөрбөгөн болушу мүмкүн.

Агымды белгилеп, ага таблица бериңиз

Тандалган трафикти mangle таблицасында белгилеп, белгини саясат эрежесинде дал келтирүү аркылуу багыттаңыз. Эреже демейки маршруту ички түзмөк болгон атайын таблицага шилтейт, ошондуктан белгиленген пакеттер гана ички жол менен жүрөт.

iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 9999 -j MARK --set-mark 0x9999
ip rule add fwmark 0x9999 table 200 pref 1000
ip route add default dev tun1 table 200

Бул эрежелер жыйындысындагы ийгиликсиздиктердин көбү эки катадан келет. Firewall орноткон белги мааниси жана эреже дал келтирген маани бирдей болушу керек, анткени айырма ката да, таасир да бербейт. Ал эми PREROUTING тыштан келген пакеттерди гана көрөт, ошондуктан бул хостто башталган туташуу белгиленгенге чейин эле ошондой дал келүүчү OUTPUT эрежесин талап кылат.

Маршрут ээлигин экинчи кардардан алыңыз

Эки вариант экинчи кардардын таблицаны оңдошуна жол бербейт жана алар ар башка чекиттерде иштейт. route-nopull push кылынган маршрут параметрлерин этибарга албайт, ошондуктан эч нерсе орнотулбайт. route-noexec push кылынган параметрлерди кардардын чөйрөсүнө кабыл алат, бирок таблица өзгөртүүсүн hookко калтырат, ал эми сервер эмнени сунуштаганын көрүү керек болгондо дал ушул керек.

Hook push кылынган маанилер менен өз чөйрөсүндө иштейт жана сиз жактырган жазууларды гана кошуусу керек. Аны idempotent кылыңыз: кайра куруудан мурун өзү ээлеген таблицаны тазалаңыз жана мурунку иштөө таза абал калтырды деп ойлобоңуз. Кайра туташуу hookту кайра чакырат, ал эми тазалабай кошкон hook кайталанган маршруттарды жыйнайт.

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

Эки сервер дарегин бекитиңиз

Ички кардар туташканга чейин ички серверге сырткы түзмөк аркылуу хост-маршрут керек. Ошол эле жазуу ички ташыуну демейки маршрутту ээрчүүгө жол бербей, сырткы туннелдин ичинде кармап турат.

ip route add 203.0.113.9/32 dev tun0
ip route get 203.0.113.9

Негизги таблицага сырткы сервер үчүн да дал келүүчү хост-маршрут кошуңуз, болбосо кайра туташуу сырткы кардардын өз ташыусун өз туннелине багытташы мүмкүн. Тартип милдеттүү: бул жазууларды тиешелүү интерфейс пайда болгондон кийин кошуңуз, башкача айтканда туташуудан кийин иштеген hook же скрипт. Өчүк түзмөккө шилтеген маршрут жок кылынат же этибарга алынбайт, ошондуктан жүктөө учурунда жазылган жазуу сиз ойлогон ырааттуулуктан өтпөйт.

Бүт таблицаны окуунун ордуна издөөнү текшериңиз. Маршрут издөөнүн чыгарылышы kernel колдоно турган түзмөктү жана баштапкы даректи атайт, жана кардар сокетин ачканда дал ошону алат.

Тизмени сынап, ийгиликсиздикти көрүнүктүү кылыңыз

Ички кардар туташып жатканда сырткы интерфейстен кармаңыз. Ички кол алышуу сырткы туннелдин ичинде шифрленген жүк катары көрүнүшү керек; эгер ал 203.0.113.9 тарапка жөнөкөй UDP болуп көрүнсө, хост-маршрут жок жана тизме эч качан курулган эмес.

Физикалык uplinkке үнсүз кайткан тизме эң жаман натыйжа, анткени интерфейстин абалы эч нерсе жарыялабайт жана ички трафик туура эмес баштапкы даректен чыгат. Эгер сырткы туннель кулаганда экинчи кардар түз кайра туташа алса, ал жолду өчүрүңүз же ийгиликсиздик көрүнүштүү болушу үчүн аны сырткы интерфейске байлаңыз.

Эки агым жана бир эреже dump-ы менен бүтүрүңүз: белгиленген жана белгиленбеген туташуулар ар башка жолдор менен жүрүшү керек, ал эми ip rule show сиз ниет кылган артыкчылыкты тизмелеши керек. Эгер эки агым тең бир жол менен жүрсө, белги сиз ойлогон жерде колдонулбайт.