Бүткүл машинасыз бир колдонмону VPN аркылуу өткөрүү

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

Эмне үчүн маршрут таблицасы программаңызды көрө албайт

Процесс пакет жибергенде, стек маршрут таблицасынан багыт дарегин издейт. Аткарылуучу файлдын аты да, порт да бул издөөгө кирбейт. Домен аттары да ошол эле себептен ишке ашпайт: туннель трафикти дарекке жеткирет, ал эми ат дарекке айланган учурда маршруттоо ядрого калган жалгыз рычаг болуп калат. Ошондуктан «VPN ушул сайт үчүн гана» акырында проксини билдирет, ал эми «VPN ушул программа үчүн гана» кичинекей механизмдер топтомунун бирин билдирет.

Булардын эч бири процесс боюнча маршрут эмес. Ар бири чечимди программаны, колдонуучуну же колдонмонун өз конфигурациясын көрө алган катмарга жылдырат.

Бир гана багыт дагы эле маршрут, программа эрежеси эмес. macOS-то адаттагы ыкма «Бүт трафикти VPN аркылуу жөнөтүү» белгисин алып салып, хост маршрутун кошуу: sudo route add -host internal-tuner.example -interface ppp0, ал кайра sudo route delete -host internal-tuner.example -interface ppp0 аркылуу жоюлат. Адегенде ifconfig ичинен интерфейстин атын окуңуз, анткени ppp0 жөн гана мисал. Хост маршрутунда алмаштыргыч белгилер иштебейт, ошондуктан бир нече ат менен сүйлөшкөн кызматка ар бир ат үчүн бир жазуу керек, жана эреже машинадагы ар бир процессти камтыйт, сиз ойлогон процессти эмес.

Сокетти туннелдин дарегине байлаңыз

Кардарды өзүңүз көзөмөлдөсөңүз, байлоо эң арзан тандоочу. Туннелдин жергиликтүү дарегине байланган сокет ошол интерфейс аркылуу чыгат, эгер ал жерде багытка маршрут болсо, ал эми машинадагы калган нерселердин баары өзүнүн кадимки жолун сактайт. Назиктик — байлоо булак дарегин тандайт, ал эми маршрут таблицасы дагы эле чыгууну тандайт. Байлоо жалгыз өзү туннелге маршруту жок трафикти жылдырбайт, жана «байладым, бирок дагы эле туура эмес жактан чыгат» деген кайрылуулардын көбүнүн артында ошол эле ката турат.

import socket
s = socket.socket()
s.bind(("10.8.0.2", 0))
s.connect(("build.internal.example", 443))

Жогорку деңгээлдеги куралдар ошол эле идеяны сунуштайт: curl --interface 10.8.0.2, PHP-де CURLOPT_INTERFACE жана Python-дун HTTP кардарларындагы source_address аргументи. Дарек туннелге таандык болушу керек, жана бул жердеги ката маршруттоо кайрылуусу катары эмес, кадимки байланыш катасы катары ишке ашпайт. Даректин ордуна түзмөктүн атына байлоо — Linux артыкчылыгы жана Windows же macOS-ко өтпөйт, ошондуктан көчмө скрипттер даректи берет.

Linux: ээсин дал келтириңиз, программанын атын эмес

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

ip rule add uidrange 1001-1001 lookup 100
ip route add default dev tun0 table 100

Бул туннель буга чейин демейки маршрут болбосо гана иштейт. Кардарды --route-nopull аркылуу баштаңыз, же --pull-filter ignore "redirect-gateway" аркылуу OpenVPN 2.4 жана андан жаңыраакта түртүлгөн кайра багыттоону чыпкалаңыз, анан таблица жазуусун өзүңүз кошуңуз. Болбосо эки демейки тең бар жана приоритети төмөнү жеңет. Анын атайын жасалган версиясы — демейки маршрутту туннелдин шлюзуна багыттоо, же муну ажыратуу скриптинен жасоо: туннель кулаганда трафикти интернеттен обочолоп кармайт, бирок бул өчүргүч, тандоочу эмес, жана бирөө аны алып салганга чейин калат.

Күчтүүрөөк версия — тармактык аттар мейкиндиги. Аны түзүңүз, кардарды ичинде иштетиңиз жана колдонмону ip netns exec аркылуу баштаңыз. Аттар мейкиндигинен тышкары эч нерсе туннелдин интерфейсин көрбөйт, ошондуктан колдонмо кокусунан хосттун маршрутуна кайта албайт. Баасы реалдуу: мейкиндикке физикалык тармакка жетүү үчүн veth түгү жана өзүнүн чечүүчү файлы керек, анткени орнотуу аттар мейкиндиги хосттун чечүү жөндөөлөрүн бөлүшпөйт.

Эки бузулуу режими агып кетүүлөрдүн көбүн түшүндүрөт. Аттарды чечүү дагы эле хосттун чечүүчүсүндө болот, ошондуктан TCP байланышы ичке кирсе да суроо туннелден тышкары чыгат. Ал эми IPv6 өзүнүн ip -6 rule эрежесин талап кылат, анткени v4 эрежеси аны камтыбайт.

Windows жана macOS: файрволду чектеңиз же проксини өткөрүңүз

Windows да колдонмо боюнча маршрут тандоочусу жок, бирок анын файрвол эрежелерин профилге чейин чектөөгө болот, жана VPN адаптерин «коомдук» деп классификациялоого болот, үй LAN-ы «жеке» бойдон калат. Колдонмо үчүн «жеке» жана «домен» профилдеринде чыгуучу бөгөттөө эрежелерин түзүңүз, «коомдукту» ачык калтырыңыз, ошондо колдонмо тармакка туннель аркылуу гана жетет. Адегенде байланыштын тармактык категориясын коюңуз, анан эреженин файрволдун монитор панелинде дал келгенин ырастаңыз. Бул бөгөттөө, маршрут эмес: туннель кулаганда жабык абалда ишке ашпайт, жана файрволду этибарга албаган колдонмону токтото албайт.

macOS башка куралдар менен ошол эле логиканы уланат. SSH аркылуу жетүүчү SOCKS угуучусу эң аз кийлигишүүчү вариант, анткени ssh -D 1080 user@host бир жергиликтүү порт түзөт жана аны колдонууга конфигурацияланган колдонмолор гана ошол жол менен жүрөт. pf эрежеси программаны колдонуучу же топ боюнча бөгөттөй алат, бирок дагы эле ошол программа үчүн гана туннелди тандай албайт. Tunnelblick домен боюнча чыпкалоону такыр жасай албайт, анткени маршруттар даректер менен иштейт; OpenConnect колдонуучулары сервер өтө кенен префикстер тизмесин түрткөндө vpn-slice кайрылат.

Эки айланып өтүү платформа куралдары өткөрүп жиберген нерселерди жабат. Проксини домен боюнча алмаштырган браузер кеңейтүүлөрү «ушул сайт үчүн гана» дегенге практикалык жооп, анткени алар аттар дагы бар колдонмо катмарында иштейт; алар бир браузерди жабат, башка эч нерсени эмес. Орой ыкма — жеткирүүчүнүн кардарын виртуалдык машинада иштетүү, ошондо конок маршруттун өзгөрүшүнө ээ болот, ал эми хост өз жолун сактайт, эки тармактык стекти тейлөө баасы менен.

Байлоо мүмкүнчүлүгү жок куралдар үчүн SOCKS секирик

Көпчүлүк колдонмолорду интерфейстер жөнүндө эч нерсе билбесе да HTTP же SOCKS проксине багыттоого болот. SSH кардары сервер тарапта эч кандай өзгөртүүсүз бирөөнү берет:

ssh -N -D 127.0.0.1:9999 [email protected]

Ошол портту колдонууга конфигурациялангандын баары бастиондо чыгат, ал эми үстөлдүн калганы өзүнүн кадимки байланышын сактайт. Туннелдин дарегине байланган жергиликтүү 3proxy нускасы SSH жок бир порт үчүн ушундай эле кылат, жана stunnel TLS менен оролгон бир портту жабат. Чектөөлөр практикалык: прокси аны кантип колдонууну билген протоколдорду гана алып жүрөт, UDP үчүн SOCKS5 UDP бирикмеси керек, аны көпчүлүк кардарлардын «SOCKS5» жөндөөсү күйгүзбөйт, жана DNS прокси аркылуу чечилиши керек (curl-де socks5h), болбосо ат жергиликтүү чечүүчүгө агып кетет.

Угуучуну жергиликтүү илмекте кармаңыз, эгер башка машинага керек болбосо.

Жолду статус билдирүүсү менен эмес, кармоо менен текшериңиз

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

tcpdump -i any -n port 443
ss -tnp | grep 443

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

Анан талапка туура келген чекти тандаңыз: бир сайтка прокси жетет, бир эсепке UID эрежеси жетет, байланыш жабык абалда ишке ашпашы керек болсо файрвол профили жетет, ал эми аттар мейкиндиги туннелди сырттагынын баарынан жашырган жалгыз вариант.