OpenVPN'дин толук туннели SSH сессияңызды үзөт: кайтуу жолун оңдоңуз

SSH аркылуу туташкан машинеде толук туннелдүү OpenVPN кардарын күйгүзүү сессияны бир секунддун ичинде үзүшү мүмкүн, ал эми машина эч кандай ката кетирбейт. Туннель пакеттердин серверге жетүү жолун өзгөртпөйт; жооптордун чыгуу жолун өзгөртөт. Демейки маршрут tun0-ге көрсөткөн заматта SSH кардарыңызга жооп провайдердин тармагына кетет, анын сиздин дарегиңизге кайтуучу жолу жок. Байланыш илинип калат, кийинки аракет убакыт боюнча бүтөт, ал эми демон бүт убакыт бою 22 портунда угат.

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

Жооп эмне үчүн туура эмес эшиктен чыгат

Кирүүчү пакеттер дагы эле физикалык интерфейске келет, анткени VPN кардары интернеттин сервериңиздин жарыя дарегине кантип жетээрин өзгөртө албайт. Жооптор өзүнчө чечим: ар бир пакет үчүн өзөк барар жерди издейт, ал эми --redirect-gateway кийин демейки жазуу туннель дейт. Провайдердин чыгымы өзү тейлебеген барар жерди көрүп, пакетти таштайт.

OpenVPN-дин өз коргоосу так бир барар жерди камтыйт. 2.6 колдонмосу --redirect-gateway-ни ырааттуулук катары сүрөттөйт: туннелге чейин колдонулган шлюз аркылуу VPN пири үчүн хост маршрутун кошот, ошондо шифрленген трафик өзүнө кайра айланбайт, анан демейки маршрутту алмаштырат. Ал хост маршруту пир үчүн гана. Сиздин SSH кардарыңыз жөн гана дагы бир интернет дареги жана эч кандай өзгөчөлүк албайт.

Бир префикс катасын эрте жокко чыгарган жөн. Узундугу жок ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 жалгыз 0.0.0.0 дарегине туура келет, интернетке эмес; ал 0.0.0.0/0 болушу керек. Ал эми демейкини алуу туннелдин өз ташуусун бузса, акыркы чекитти физикалык интерфейс аркылуу хост маршруту катары кошуңуз, провайдердин чыныгы дарегин колдонуп.

Дароо оңдоо үчүн кардар дарегиңизди бекитиңиз

Эң тез оңдоо — туннель пайда болгонго чейин сервер колдонгон шлюз аркылуу кардар дарегиңизге хост маршруту. Өз тарабыңыздан сервер көрө турган даректи табыңыз, анан эски шлюзди билүү үчүн сервердин таблицасын окуңуз:

curl -s https://ifconfig.co
ip route

Серверде кардар башталганга чейин өзгөчөлүктү кошуңуз. Бул жердеги даректер орун толтургучтар; формасы маанилүү:

sudo ip route add 80.128.240.55 via 192.168.178.1

Бул билдирилген учурда колдонулган оңдоо жана ал дароо иштейт. Ал ошондой эле эки болжолдуу жактан алсыз: кайра жүктөөдө маршрут жоголот, жана ISP сизге башка дарек берген учурда туура эмес болуп калат. Аны өзгөчө кырдаал чарасы катары кабыл алыңыз жана атайын туруктуу кылыңыз, тармактык бирдик же dispatcher илгичи аркылуу, же убактылуу экенин моюнга алып, калыбына келтирүү жолун жазып коюңуз.

Кардардын демейки маршрутту алышына жол бербеңиз

Тазараак вариант — туннелдин демейки маршрутту таптакыр алмаштыруусуна жол бербөө. route-nopull, --client же --pull менен колдонулганда, маршруттар, block-outside-dns жана DNS серверлери сыяктуу DHCP стилиндеги опциялардан башка түртүлгөн опцияларды кабыл алат, ошондуктан керектүү префикстерди гана кошосуз. Андан тар курал — тартуу чыпкасы, ал бир көйгөйлүү директиваны таштап, калганын сактайт:

route-nopull
pull-filter ignore "redirect-gateway"

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

Кайтуу жолун булак же байланыш боюнча бөлүңүз

Кирүүчү дарек туруктуу болсо, булак эрежеси туннелдин өз маршруттарына тийбестен жоопторду жергиликтүү кармайт. Физикалык интерфейс дарегине LAN префикси жана физикалык демейкиси бар өзүнчө таблица бериңиз, анан андан келген трафик үчүн ошол таблицаны тандаңыз:

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

Бул иштейт, анткени кирүүчү SSH байланышына жооптор кардар туташкан даректен чыгат. Ар бир кирүүчү кызмат ишин улантышы керек болгон билдирилген учур так ушул форманы колдонгон. Кирүүчү дарек калкыса же жол динамикалуу болсо, анын ордуна байланышты белгилеңиз: физикалык интерфейстен келген биринчи пакетке conntrack белгисин коюңуз, аны OUTPUT ичиндеги жооп пакеттерине көчүрүңүз жана белгиленген пакеттерди физикалык шлюзге багыттаган таблица аркылуу маршруттаңыз.

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

Сыноо учурунда байланыш белгисин, firewall белгисин жана таблица номерин өзүнчө кармаңыз. Бир номерди эки ролго кайра колдонуу туура көрүнгөн жана туура эмес пакеттерге туура келген эреже жаратат. Таблицанын демейки жазуусуна кадимки Ethernet байланышында LAN шлюзу менен via да керек; жылаңач dev eth0 интерфейс пункт-пункт болгондо же кийинки секирик башка жол менен чечилгенде гана иштейт. Билдирилген Jessie хосту жылаңач форма иштеген байланышта болгон, бул көчүрүүгө боло турган бөлүштүрүү эрежеси эмес.

Өзүңүздү кулпулабай текшериңиз

Ажыратуу менен сынабаңыз. Биринчи сессияны ачык кармаңыз, туннелди көтөрүңүз жана өзөктөн өз дарегиңиз кайсы жолду тандаарын сураңыз:

ip route get 80.128.240.55

Жооп туннелди эмес, физикалык интерфейсти жана эски шлюзди аташы керек. Анан экинчи SSH байланышын ачыңыз; бул чыныгы сыноо, анткени эски сессия жаңы байланыш кайра жарата албаган абалда жашап калышы мүмкүн. Эгер экинчиси илинип, биринчиси дагы эле жооп берип турса, эреже маанилүү трафикке эч качан туура келген эмес, ал эми кароочу жер — белгилер же булак дареги.

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