Нэг програмыг бүх машиныг оролгүйгээр 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 дүрэм хангалттай, холболт хаагдаж бүтэлгүйтэх ёстой бол галт ханын профайл хангалттай, гаднах бүх зүйлээс туннелийг нуух цорын ганц сонголт бол нэрийн орон зай юм.