Kill switch ямар ч урсгал хөдлөхөөс өмнө VPN серверийг блоклодог
Kill switch аль үе шатыг блоклодог: төгсгөлийн цэгийн хайлт, гадаад маршрут, буцах зам, хуучирсан хамтрагчийн үл хамаарах зүйлс — таамаглалын оронд тоолуураар.
Kill switch хүмүүсийн хүлээгээгүй чиглэлд бүтэлгүйтдэг: тэдгээр нь туннель унасан үед урсгалыг блоклохоор бүтээгдсэн бөгөөд туннелийг барьж буй пакетууд өөрсдөө урсгал юм. Энэ бол бүх алдаа. Туннелээр гарахгүй бүгдийг хаядаг дүрмийн багц түүнийг өргөх ёстой гар барилтыг ч хаядаг тул клиент давталтад дахин оролдож, алдаа нь хамгийн түрүүнд шалгагдсан үе шатанд хамаарна. Галт ханыг өргөтгөхийн өмнө гурван үе шатын алийг нь татгалзаж байгааг олж мэдээрэй: нэрийн хайлт, хамтрагч руу явж буй гадаад пакет эсвэл буцаж ирж буй хариу.
Туннель ба түүний өөрийн тээвэр хэрхэн бие биенээсээ хамааралтай вэ
VPN клиентийг нэг сокетын замыг хуваалцдаг хоёр сүлжээний төлөв гэж уншина уу. Туннель үүсэхээс өмнө клиент физик адаптер дээр сокет нээж, шифрлэгдсэн фреймүүдийг хамтрагчийн хаяг, порт руу илгээдэг. Тэр солилцоо амжилттай болсны дараа л туннелийн төхөөрөмжийг үүсгэж, маршрутуудыг суулгадаг. Kill switch бол хоёр дахь төлөвийн тухай бодлого бөгөөд хоёуланд нь хамаарахаар өргөн бичигдсэн.
Интерфейсэд суурилсан дүрмүүд бол ердийн хэлбэр: дараахаас гарч буйг хүлээж аваарай: tun0 эсвэл wg0, үлдсэн гарах замыг хая. Энэ томъёолол нь клиентийн сервертэй өөрийн холболтыг үл хамаарах боломжгүй тул зөв хэрэгжүүлэлт тэр үл хамаарах зүйлийг тодорхой нэмдэг, та ч гараар дүрэм бичихдээ мөн адил хийдэг. Windows болон macOS дээр аппликейшн тус бүрийн дүрмүүд интерфейсийн оронд процесс тааруулж үүний нэг хэсгийг тойрч гардаг, гэхдээ процесс туннель үүсэхээс өмнө гарцаагүй гарч байх ёстой.
Гурван үе шат, тохиолдох дарааллаар нь
Эхний үе шат бол шийдвэрлэлт. Профайл шууд хаягийн оронд хост нэрийг хадгалж байвал клиент ямар нэгэн зүйл илгээхээс өмнө DNS хариу хэрэгтэй. DNS-ийг туннелийн шийдвэрлэгч рүү чиглүүлдэг профайл мухардал үүсгэдэг: шийдвэрлэгч нь хайлтыг идэвхжүүлэх ёстой туннелээр л хүрэх боломжтой. Туннелийн гадна шийдвэрлэх эсвэл төгсгөлийн цэгийг хаягт бэхлэх нь энэ тодорхойгүй байдлыг арилгана.
Хоёр дахь үе шат бол гадаад пакет бөгөөд энэ дарааллаар эхлээд маршрутлалт, дараа нь галт ханыг давах ёстой. wireguard-tools WireGuard-ийн хувьд үүний маршрутлалтын хагасыг өөрөө гүйцэтгэдэг: өөрийн пакетуудыг тэмдэглэж, дөнгөж суулгасан анхдагч маршрутыг алгасахын тулд бодлогын дүрэм нэмдэг; wg-quick гарын авлагын хуудас тэр дүрэм болон түүний ашигладаг хүснэгтийг тайлбарладаг. Тэр маршрутлалтыг гараар дахин бүтээх эсвэл хоёр дахь хэрэгсэлд дүрмүүдийг дахин бичүүлэх юм бол тэмдэглэсэн пакетууд нь тэдний үүсгэх ёстой туннель руу буцаж илгээгдэж болно.
Гурав дахь үе шат бол буцах зам. Хариугүй гар барилт нь гадагш хаясны баталгаа биш; энэ нь серверийн орох дүрэм эсвэл зураглалыг мартсан NAT төхөөрөмжтэй адилхан нийцдэг. Клиентэд хүрэхээс өмнө эдгээрийг ялгаарай.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Клиентүүд илрүүлсэн шинж тэмдгийг бүртгэдэг, бүтэлгүйтсэн үе шатыг биш, тиймээс хүснэгт ихэвчлэн логоос хурдан байдаг.
Тоолуурууд логоос хурдан шийддэг
Linux дээр, nft list ruleset эсвэл iptables -vnL OUTPUT дүрэм бүрд пакетын тоолуур хэвлэдэг. Нэг удаа холбогдоод, бүтэлгүйтэх боломж өгөөд, дараа нь тоолууруудыг дахин уншина уу. Тоолуур нь хөдөлсөн дүрэм бол гар барилт мөргөсөн дүрэм юм; хаана ч юу ч хөдлөөгүй бол пакет галт хананд хэзээ ч хүрээгүй. Дүрмийн багц өөрийн гар барилтыг хаясныг би харсан бөгөөд үүнийг зөвхөн тоолуурууд хэлсэн.
Галт хананд хэзээ ч хүрээгүйг хостноос хэзээ ч гарсангүйгээс ялгахын тулд интерфейсийг өөрөө ажиглаарай. ip -s link show dev wlan0 илгээсэн пакетуудыг мэдээлдэг, tcpdump -ni wlan0 udp port 51820 фреймүүдийг харуулдаг. Клиент дахин оролдож байх хооронд энэ нь хавтгай хэвээр байвал гэмтэл netfilter-ээс дээгүүр байна: дутуу хамтрагчийн маршрут, хараахан байхгүй төхөөрөмж рүү заасан бодлогын дүрэм, эсвэл клиентийн залгидаг сокетын алдаа.
Үл хамаарах зүйлсийг баримт бичгийн хаягуудад туршиж үзээрэй, жишээ нь 203.0.113.10, алдаа гаргаж өөр хүний хост шалгахгүйн тулд.
Хуучирсан төгсгөлийн цэгийн үл хамаарах зүйл серверийн доголдол мэт уншигддаг
Хамгийн төөрөгдүүлдэг хувилбар нь хамтрагчийн хаяг өөрчлөгдсөний дараа гарч ирдэг: динамик хаягийн үйлчилгээ үүнийг зөөсөн, хост дахин бүтээгдсэн, эсвэл таны сүлжээний гарах хаяг өөр байна. Үл хамаарах зүйл хуучин хаягийг дурдсан хэвээр байна, тиймээс шинэ хаяг руу явж буй пакетууд хаях дүрэмд өртдөг. Ижил тохиргоо өчигдөр ажиллаж байсан тул хүмүүс серверийн оношилгоогоор эхэлдэг.
Галт ханын дүрэм доторх хост нэр таныг аварч чадахгүй. nftables-д нэр нь дүрмийн багцыг ачаалах үед шийдвэрлэгддэг тул тэр мөчид байсан хаягийг бэхэлж, шууд хаяг шиг хуучирдаг. Тогтвортой шийдэл бол төгсгөлийн цэг өөрчлөгдөх үед үл хамаарах зүйлийг шинэчлэх, түүнийг нарийн байлгах явдал юм: нэг хамтрагчийн хаяг, нэг тээврийн порт. Хаягийн өөрчлөлтийг даван туулах хэмжээний өргөн хүрээ нь хамааралгүй урсгалыг гаргахад ч хангалттай өргөн юм.
Kill switch серверийн хост дээр ажиллах үед
Мөн адил хамаарал нөгөө талд ч байдаг бөгөөд тэнд үүнийг анзаарахгүй өнгөрөөхөд хялбар. Хэрэв таны VPN серверийн үүрэг гүйцэтгэдэг машин kill switch-тэй ширээний клиент эсвэл зөөврийн компьютерээс хуулбарласан галт ханын профайлыг ч ажиллуулдаг бол түүний хаях дүрмүүд туннелүүдийг дуусгадаг үйлчилгээнд хамаарна. Клиентийн гар барилтад өгөх хариунууд хаягдаж, сервер эрүүл харагдаж, туннелийн интерфейс ашиглагдалгүй байхад клиент бүр холбогдож чаддаггүй.
Тэр хостод хаяхаас өмнө гурван нарийн зөвшөөрөл хэрэгтэй: физик интерфейс дээрх сонсох порт, тайлагдсан урсгалын туннелийн интерфейс, туннелээс клиентүүдийн хүрэх ёстой зүйл рүү дамжуулалт. Суулгасан багцыг дараахаар уншина уу: nft list ruleset, iptables -S, эсвэл pfctl -sr , ямар нэгэн зүйл өөрчлөхөөс өмнө, хадгалсан дүрмийн багц дахин ачаалалтыг даван туулдаг тул тэндхийн алдаа түүнийг үүсгэсэн процессоос урт насалдаг.
Машиныг хаалттай байлгах сэргээх дараалал
Профайлаас гадагш ажиллаарай. Клиентийн ашигладаг хамтрагчийн хаяг, портыг унших, туннельгүйгээр хост нэр шийдвэрлэгдэж байгааг баталгаажуулах, дараа нь физик адаптер дээр л тэр хаяг, портын хувьд нэг үл хамаарах зүйл нэмэх. Дахин холбогдож, илгээлтийн тоолуурыг ажиглаарай; дууссан гар барилт бол хоёр дахь үе шат зассан гэсэн дохио юм.
Туршилтын үеэр хаях бодлогын үлдсэнийг байранд нь үлдээгээрэй. Хор хөнөөлгүй шалгалт бол хамааралгүй баримт бичгийн хаяг руу холболт оролдож, энэ нь хугацаа хэтрэлтээр дуусч байгааг батлах бөгөөд энэ нь kill switch унтраалттай биш, ажиллаж байгааг харуулна. Туннель тогтворжсоны дараа үл хамаарах зүйлийг чангаруулж, тав тухтай гэж клиент програмын бүх зүйлийг бүрмөсөн зөвшөөрөхгүй байгаарай.
Туннель босч, апп амжилтгүй хэвээр байвал үлдсэн үе шатууд энэ биш: задарсан DNS, MTU, апп тус бүрийн маршрутлалт тус бүр холбогдсон туннель болон эвдэрсэн урсгалыг үүсгэдэг бөгөөд тус бүр өөр эхний шалгалттай.