Нэгэн зэрэг хоёр VPN апп: аль kill switch үнэхээр хэрэгжих вэ?
Хоёр дахь VPN клиент эхнийхийн kill switch-ийг хэзээ ч өвлөдөггүй. Аль бодлого хэрэгжихийг гурван нөхцөл шийддэг бөгөөд өөрийнхийгөө хэрхэн шалгахыг тайлбарлав.
Хоёр VPN клиент зэрэгцэн ажиллаж болох ч тэдний kill switch нэг бодлого болж нэгдэхгүй. Клиент бүр өөрийн туннелийн дүрмийг суулгадаг бөгөөд аль нь ч нөгөөгийнхөө байгааг мэддэггүй. Би үүнтэй ажлын клиент эхэлж холбогдсон үед таарсан: хоёр дахь апп гарын барилтааг гүйцээж чадсангүй, арван минутын турш „Connecting“ дээр гацсан бөгөөд эхний туннель бүхнийг чимээгүй зөөсөн. Хоёр дахь апп хамгаалагдах эсэх нь гурван нөхцөлөөс хамаарна, хоёр дүрс хоёулаа Холбогдсон гэж харуулахаас биш.
Kill switch үнэхээр юунд хязгаарлагддаг вэ
Үйлдлийн системд ганц kill switch туг байхгүй. Ийм зүйлийг зарладаг клиент дүрмийн багц суулгадаг: миний туннелээр гарахгүй бүхнийг хая, туннель алга болоход ихэвчлэн fail closed ажилла. Linux дээр энэ ихэвчлэн nftables эсвэл iptables гинжин хэлхээ, Windows дээр Windows Filtering Platform шүүлтүүрийн багц, Android болон iOS дээр туннель үйлчилгээний өөрийн чиглүүлэлт дээр VPNгүй холболтыг хаадаг системийн тохиргоо нэмэгдэнэ. Android VPN гарын авлага платформын үзэл бодлыг хүсвэл тэр үйлчилгээний загварыг тайлбарладаг.
Хамрах хүрээ бол чухал хэсэг. „Зөвхөн wg0 гарах интерфэйс дээрх пакетыг зөвшөөр“ гэх мэт дүрэм хоёр дахь туннель байгаа эсэхэд анхаардаггүй. Өөр клиент wg1-ийг өргөвөл эхний клиентийн дүрмүүд эдгээр пакетыг энгийн трафик гэж үзнэ: ихэвчлэн хаягдана, заримдаа зөвшөөрөгдөнө. Ямар ч байсан шийдвэрийг эхний клиент гаргадаг бөгөөд хоёр дахь апп хүлээж байгааг мэддэггүй.
Хэнийг хамруулахыг шийдэх гурван нөхцөл
Бүх хослолыг жагсаах шаардлагагүй. Гурван асуулт үүнийг хэдхэн минутад шийднэ.
- Платформ хоёр дахь туннелийг огт зөвшөөрдөг үү? Ихэнх Android утас болон iPhone хэрэглэгчийн профайл тутамд зөвхөн нэг идэвхтэй VPN үйлчилгээг хүлээн авдаг тул хоёр дахь апп хэзээ ч туннель барьдаггүй, юу ч хэрэгжүүлдэггүй. Та нэг бодлого авна: байрлалыг хожсон аппаас.
- Өгөгдмөл маршрутыг аль процесс эзэмшдэг вэ? Windows, macOS болон Linux хоёр туннелийг хялбар зөөдөг. Өгөгдмөл маршрут түүнийг хамгийн сүүлд эсвэл илүү сайн метриктэй тохируулсан клиентэд хамаарна, нөгөө клиент холбогдсон боловч сул байна. Linux дээр wg-quick-ийн өгөгдмөл маршрутын горим хувийн хүснэгт болон fwmark дүрэмтэй бодлогод суурилсан чиглүүлэлт ашигладаг тул хоёр дахь wg-quick туннель эхнийхийг солихын оронд өрсөлдөх дүрэм нэмдэг.
- Хоёр дахь клиент өөрийн серверт хүрч чадах уу? Хэрэв эхний kill switch өгөгдмөлөөр татгалздаг бол хоёр дахь аппын гадаад төгсгөлийн цэг нь зүгээр л өөр нэг хаягдсан зорилт. Тэр чимээгүй дахин оролддог бөгөөд хэзээ ч алдаа мэдээлдэггүй.
Богино хувилбар, дэмжлэгийн сэдвүүдэд:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
Тэдгээр мөрүүдийн хоёр нь системийн тавиур дээрх дүрснээс ижил харагддаг тул дүрс энд байгаа хамгийн муу нотолгоо юм.
Юу эхлээд эвдэрдэг, яаж харагддаг вэ
Нөгөө нь эрүүл байхад „Connecting“ дээр гацсан клиент бараг үргэлж төгсгөлийн цэгийн өлсгөлөн: ажиллаж буй kill switch хоёр дахь клиентийн өөрийн сервер рүү хийх гарын барилтааг хаядаг. Үүнийг хямд замаар батлахын тулд эхний клиентийн хаах дүрмийг нэг оролдлогоор түр зогсооно уу. Хоёр дахь нь даруй холбогдвол асуулт хариулагдсан.
DNS бол хоёр дахь гэмтэл. Клиентүүд шийдвэрлэгчийн тохиргоог өөрийн интерфэйст зориулж тавьдаг, зарим нь дэлхийн жагсаалтыг шууд дарж бичдэг. Хоёр туннель нээлттэй үед асуулга нэг талаас гарч, шийдвэрлэгч нөгөө талд хамаарах боломжтой. Аль нэг аппыг салгавал үлдсэн нь хүрэх боломжгүй нэрийн серверийг хадгална: хуудсууд нэг минут гацаад дахин шийдэгдэнэ, VPN нь холбогдсон хэвээр харагдана.
Гурав дахь нь маршрутын савлалт. Дахин холболтууд өгөгдмөл маршрутыг дахин эрэмбэлдэг бөгөөд интерфэйстэй холбогдсон kill switch түүнийг дагадаггүй. Салхинд өмнө туннель дотор байсан трафик одоо хаях дүрэмд тохирч, хэрэглэгчийн талд санамсаргүйгээр ажиллахаа болих VPN гэж уншигдана.
Аль бодлого үнэхээр хэрэгжиж байгааг шалгана уу
Үүнийг хор хөнөөлгүй трафик ашиглан хий, санаанд оромгүй зүйлээр биш.
Linux дээр цөмөөс хэн ялах, галт хана юунд холбогдохыг асуу. ip -4 route show default гаралтыг эзэмшиж буй туннелийг нэрлэнэ. ip rule show бодлогод суурилсан чиглүүлэлт тоглоомд байгаа эсэхийг харуулна. sudo nft list ruleset | grep -n oifname хаалтууд интерфэйсийн нэр, тэмдэг эсвэл бүх гаралтын гинжид холбогдсон эсэхийг харуулна.
Windows дээр ижил түүх маршрутын метрик болон шүүлтүүрийн жагсаалтад амьдардаг: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric болон Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". macOS дээр netstat -rn -f inet | head -5 болон scutil --dns | head -20.
Дараа нь хүмүүсийн алгасдаг алхмыг хий: туннелийг санаатайгаар зогсоож, бүтэлгүйтнэ гэж хүлээж буй трафик үнэхээр бүтэлгүйтэж байгааг батал. Холбогдсон дүрс бол интерфэйсийн төлөв, хэрэгжилт биш.
Хоёр клиент хэзээ буруу загвар болдог вэ
Хэрэв хоёр дахь аппын ард байгаа цорын ганц шаардлага нь илүү их хамгаалалт бол түүнийг авч хая. Харилцан үйлчилдэг хоёр хаах бодлого нэгээс бага урьдчилан таамаглагдана, дахин холболт бүр нэг ч нийлүүлэгчийн шалгадаггүй төлөвт орох боломж юм.
Хэрэв үнэхээр гинжилт хэрэгтэй бол, жишээ нь арилжааны үсрэлтээр хүрдэг корпорацийн гарц бол нэг хэрэгжилтийн цэгтэй загвар сонго. Энэ нь ихэвчлэн ижил өгөгдмөл маршрутын төлөө өрсөлдөж буй хоёр ширээний апп биш, гинжийг дэмждэг маршрутизатор эсвэл нэг клиент гэсэн үг. Удирддаг төхөөрөмж дээр зөвшөөрөгдсөн клиентийг барьж, бусад бүхнийг хамрах хүрээнээс гадуур гэж үз, тавиур дээр юу харуулсан ч.
Хоёуланг нь барихаас өмнөх шалгах хуудас
Жагсаалтыг дарааллаар нь хий; бүтэлгүйтсэн эхний зүйл бол засах зүйл.
- Өгөгдмөл маршрут болон шийдвэрлэгчийг яг нэг клиент эзэмшдэг гэдгийг батал.
- Хоёр дахь клиент нээлттэй байлгахыг хүсвэл түүний серверийн төгсгөлийн цэгийг тодорхой зөвшөөрч, клиентийн шинэчлэл бүрийн дараа дахин шалга.
- Аль нэг туннель унах үед хүлээгдэж буй үр дүнг бичиж, яг тэр тохиолдлыг туршиж үз.
- Дахин ачаалсны дараа, эхлэх дараалал өөр үед эвдрэлийн замыг шалга.
- Удирддаг профайл дээр зогсоод, ямар нэг зүйл нэмэхийн өмнө эзэмшигчээс асуу.
Хэрэв гурав дахь алхам бүтэлгүйтвэл шударга хариулт нь танд зөвхөн нэг клиент бодлого өгч байна гэсэн үг. Аль нэгэнд нь итгэхээ шийдээд нөгөөг нь явуул.