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 болуы керек. Ал егер әдепкіні алу туннельдің өз тасымалын бұзса, соңғы нүктені физикалық интерфейс арқылы хост маршруты ретінде қосыңыз, провайдердің нақты мекенжайын пайдаланып.

Бірден түзету үшін SSH клиентіңіздің мекенжайын бекітіңіз

Ең жылдам түзету — туннель пайда болғанға дейін сервер қолданған шлюз арқылы клиент мекенжайыңызға хост маршруты. Өз жағыңыздан сервер көретін мекенжайды табыңыз, содан кейін ескі шлюзді білу үшін сервердің кестесін оқыңыз:

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 қосылымын ашыңыз; бұл нақты сынақ, өйткені ескі сессия жаңа қосылым қайта шығара алмайтын күйде өмір сүруі мүмкін. Егер екіншісі ілініп, біріншісі әлі жауап беріп тұрса, ереже маңызды трафикке ешқашан сәйкес келмеген, ал қарайтын жер — белгілер немесе көз мекенжайы.

Бүкіл жаттығу кезінде жолақтан тыс консольді қол астында ұстаңыз. Жалғыз кіру жолы жаңа ғана сындырған туннеліңіз болып табылатын серверді сол туннель арқылы түзету мүмкін емес, ал қосқан кесте нөмірлері мен префикстерді жазып қойсаңыз, кері қайтару да жеңіл.