Программд суурилсан ба очих цэгт суурилсан split tunneling: алийг нь сонгох вэ

Программд суурилсан болон очих цэгт суурилсан split tunneling нь нэг ажлын хоёр тохиргоо биш. Нэг нь аль процесс пакет илгээж байгааг асуудаг; нөгөө нь тэр пакет хаашаа явж байгааг асуудаг. Эхний асуултад зориулж бүтээсэн дүрэм трафик туслах процессоос ирэхэд чимээгүйхэн бүтэлгүйтдэг, хоёр дахьд зориулсан дүрэм хост нэр таны хэзээ ч жагсаалтад оруулаагүй хаяг руу шийдэгдэхэд бүтэлгүйтдэг. Шаардлагад тохирох объектыг сонгоод, хоёр туршилтын пакетаар нотлоорой: нэг нь туннелийг ашиглах ёстой, нөгөө нь ашиглах ёсгүй.

Хоёр дүрэм өөр өөр түвшинд үйлчилдэг

Аппын дүрэм сүлжээний түвшнээс дээгүүр, үйлдлийн систем илгээгчид өгдөг таних тэмдгийн эсрэг хэрэгждэг. Android дээр энэ нь пакетийн ардах UID бөгөөд VPN үйлчилгээ UID бүрт трафик туннельд орж байгаа эсэхийг шийддэг. Очих цэгийн талаар юу ч асуудаггүй тул сонгосон апп юунд ч хүрч чадна, өөр ямар ч апп дотоод сүлжээнд хүрч чадахгүй.

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

Аппын дүрэм гар утасны клиент болон удирдлагатай агентуудад тохирно

Android сонголтыг шууд санал болгодог: VpnService.Builder.addAllowedApplication() болон addDisallowedApplication() пакетийн нэрийг авч UID бүрт шийдвэрийг хэрэгжүүлдэг, үүнийг Android-ын VPN хөгжүүлэгчийн гарын авлагад тайлбарласан. iOS-д багц танигчд дээр суурилсан апп тус бүрийн VPN дүрмээр ижил боломж бий бөгөөд ихэвчлэн гараар бичихгүйгээр MDM профайлаар хүргэдэг.

Ширээний клиентүүд сул тал юм. Windows болон macOS VPN клиентүүдийн ихэнх нь очих цэгээр чиглүүлдэг бөгөөд процессоор сонгох боломжийг огт өгдөггүй, учир нь туннелийн драйвер процесс биш пакетыг хардаг. Хэрэв таны төлөвлөгөө зөөврийн компьютер дээр нэг аппыг туннельдүүлэхээс хамаардаг бол эргэн тойронд нь зохион бүтээхээс өмнө клиентийн бодит боломжийг шалгаарай; магадгүй та очих цэгийн жагсаалт болон хоёр дахь машины хооронд сонгож байгаа байх.

Хүмүүсийн алддаг үр дагавар: тэдгээр платформ дээр чиглүүлэлтээр аппын дүрмийг дуурайх боломжгүй. Аппын серверт хост чиглүүлэлт нэмэхэд хүн бүрийн трафик, түүний дотор хөтөч болон шинэчлэгч тэр сервер рүү туннельдэгдэнэ.

Очих цэгийн дүрэм подсетийн жагсаалт болон сайтын хүртээмжид тохирно

WireGuard загварыг тодорхой болгодог. AllowedIPs нь крипто түлхүүрийн чиглүүлэлт: очих цэг нь түншийн жагсаалтад багтах дотоод пакет тэр түнш рүү шифрлэгддэг, бусад бүхэн ердийн замаар шифрлэлтгүй гардаг. Нэрлэх процесс ч, юу багтсаны талаар ямар ч тодорхойгүй байдал ч байхгүй.

OpenVPN түлхэгдсэн чиглүүлэлтийн хүснэгтээр ижил газарт хүрдэг. route-nopull серверийг чиглүүлэлт тушаахаас зогсоодог, дараа нь клиентийн талын route 10.20.0.0 255.255.0.0 vpn_gateway яг оффисын префиксийг хамардаг. IPv6 эдгээр клиент бүрд тусдаа мэдэгдэл бөгөөд үүнийг мартах нь зөв харагдах IPv4 хуваалтыг тойрч гоожих хамгийн түгээмэл арга.

Хост нэр нь чиглүүлэлт биш. Хэрэв профайл домэйн талбар санал болговол түүнийг клиент нэг удаа шийддэг нэр гэж үзээрэй, байнгын хаягийн хүрээ гэж биш; контент хүргэх сүлжээ болон ачааллын тэнцвэржүүлэгчид маргааш өөр хаяг өгнө.

Хоёр загвар хаана эвдэрдэг: туслахууд, хуваалцсан үйлчилгээ, шийдэгчид

Туслах процессууд аппын дүрмийг эвддэг бөгөөд энэ нь серверийн доголдол мэт харагдана. Хөтчийн шинэчлэгч, ослын мэдээлэгч, SYSTEM-ээр ажилладаг синхрончлолын үйлчилгээ болон өөр пакетэд суулгасан WebView нь бүгд тусдаа таних тэмдэг тул хөтчийг туннельдүүлэх нь бодит хүсэлтийг туннелиас гадуур үлдээж болно. Эсрэг тохиолдол ч мөн адил будлиантай: туннельдсэн процессын дотор хуваалцсан санг дууддаг хасагдсан аппын трафик бас туннелээр явдаг.

Очих цэгийн дүрэм хуваалцсан үйлчилгээ болон нэр дээр эвдэрдэг. Файл хуваалцалт, принтер, дотоод DNS болон лицензийн сервер бүгд хаяг дээр амьдардаг тул нэг аппын туннель хөтөчд хандалт өгдөг ч холбосон диск үхсэн хэвээр үлддэг. Энэ хамрах хүрээний ялгаа нь аль ч загварын алдаа биш, гэхдээ нэг аппын туннель яагаад ийм олон удаа VPN асаалттай, харин хуваалцалт алга болсон гэсэн байдал үүсгэдэг шалтгаан нь энэ юм.

Шийдэгчид хоёуланг нь огтолдог. Хэрэв клиент дотоод DNS серверүүдийг тохируулсан боловч үйлдлийн систем нийтийн шийдэгч рүү HTTPS-ээр DNS ашигладаг бол хариулт туннелиас гаднаас ирдэг бөгөөд очих цэгийн дүрэм хэзээ ч тохирохгүй байж болно. Дүрэм буруу гэж дүгнэхээс өмнө аль шийдэгч бодитоор хариулсныг шалгаад, клиентийн талд туннелийн шийдэгчийг огт суулгасан эсэхийг баталгаажуулаарай. DNS-ийг туннелиас гадна үлдээсэн хуваалт чиглүүлэлтийн хүснэгтэд төгс харагдах боловч дотоод нэр бүр дээр бүтэлгүйтдэг.

Ажлын журам: сонгох, хэрэглэх, шалгах

Цэснээс биш шаардлагаас эхэл. Хэрэв зорилго нь зөвхөн энэ апп туннелийг ашиглах боломжтой байх бол аппын дүрэм болон түүнийг дэмждэг платформ хэрэгтэй. Хэрэв зорилго нь эдгээр сүлжээнд туннелээр хүрэх боломжтой байх бол префикс хэрэгтэй. Хариулт нь хоёулаа бол тэдгээрийг хоёр тусдаа удирдлага болгон хэрэгжүүлж, аль нь аль доголдолд хариуцлага хүлээхийг бичээрэй.

Илэрхийлж чадах хамгийн нарийн хэлбэрийг хэрэглээд, дараа нь клиентийн төлөвийн дүрс биш чиглүүлэлтийн хүснэгтээс асууж шалгаарай:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

Эхний хоёр мөр бодит очих цэгийн ашиглах интерфейсийг нэрлэнэ; wg show тохируулсан префиксийн жагсаалтыг хэвлэнэ; Windows дээр Find-NetRoute пакет илгээгдэх үед стек хариулах ижил асуултад хариулна. Хэрэв интерфейс нь туннель бол дүрэм тохирсон.

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