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

Тааруулагч нь ховор буруутан

Эхлээд ялгах ёстой зүйл бол блоклогдсон ба эвдэрсэн. Блоклогдсон нэр хурдан бөгөөд харагдахуйц бүтэлгүйтэх ёстой, учир нь хөтөч нэр байхгүй гэсэн хариу авч зогсдог. Эвдэрсэн нэр зогсолт хийнэ, IPv6-аар дахин оролдоно, өөр тээвэрт шилжинэ, таныг эргэлдэх заагчтай үлдээнэ. Хэрэв эргэлдэх заагч харж байвал таны зөвшөөрөгдсөн жагсаалт клиент юу ч хийж чадахгүй зүйлээр хариулж байна.

Хоосон A бичлэг бол сонгодог алдаа. Тэг хариутай NOERROR буцаах нь хүчинтэй хариу мэт харагддаг тул stub шийдэгч үүнийг хүлээж авна, хөтөч дахин оролдоно, AAAA туршина, өөр шийдэгч туршина, нэлээд хожуу бууж өгнө. Асуултын хэсгийг давтан, гүйлгээний ID-г хуулж өгсөн 3-р хариу код, өөрөөр хэлбэл NXDOMAIN, яриаг шууд дуусгана. Үүнийг санаатайгаар татгалзсан нэр бүрт хэрэглээрэй.

IPv6 ч мөн өгөгдмөл утгын оронд ижил шийдвэр авах ёстой. Хэрэв A-д NXDOMAIN хариулж, AAAA-г нэвтрүүлбэл клиент блоклогдсон нэрэнд IPv6-аар хүрч, шүүлтүүр алдагдана. Зарим хэрэгжүүлэлт блоклогдсон AAAA асуулгад loopback хаягаар хариулж, холболт өөр хувилбарт шилжихийн оронд шууд бүтэлгүйтдэг. Нэг бодлого сонгож, хоёр бичлэгийн төрөлд хэрэглэж, хоёуланг нь бүртгээрэй.

Бүгдийг барих маршрут бүгдийг эзэмшинэ

Зөвхөн DNS-д суурилсан загвар хэзээ ч addRoute("0.0.0.0", 0) нэмдэггүй тул TUN интерфэйсэд зөвхөн асуулга орж, бусад бүхэн доод сүлжээг үргэлжлүүлэн ашиглана. Энэ бол аюулгүй хэлбэр бөгөөд зарим зөвшөөрөгдсөн жагсаалт Wi-Fi дээр ажиллаж, үүрэн сүлжээнд яагаад бүтэлгүйтдэг тайлбар болно.

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

Шийдэгчийн сокет туннельээс гарах ёстой

Дамжуулалт бол дараагийн урхины газар. Операторын шийдэгчид ихэвчлэн туннель хүрч чадахгүй хувийн хаяг дээр амьдардаг тул дамжуулсан асуулга хаана ч хүрэхгүй, апп унших хугацаа дууссан гэж мэдээлнэ. Зөвшөөрөгдсөн асуулгыг хүрч чадна гэдгээ мэдэх шийдэгчид илгээж, тэр сокетыг эхлээд VpnService.protect()-д өгөөрэй. Хамгаалагдаагүй сокет асуулгыг өөрийн туннель руу буцааж, тэнд дахин апп-д хүрч, хугацаа дуустал эргэлдэнэ.

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

Хэмжээ ба шалгах нийлбэр мессежгүйгээр бүтэлгүйтдэг

Чимээгүй хасалт нь хэмжээнээс ч үүсдэг. Том хариуны багцтай DNS хариу эсвэл өргөн сонголттой TCP гар барилт нь та хэзээ ч тодорхой тохируулаагүй замын MTU-г хэтэрч болно; хэсэг нь дээш алга болж, клиент нь жижигээр дахин оролдох эсвэл оролдохоо болино. Интерфэйсийн MTU-г 1280-д тавих нь ихэнх үүрэн замыг даван туулах консерватив сонголт бөгөөд хэн ч хэмжээгүй өгөгдмөл утгыг өвлөхөөс тодорхой байх нь дээр.

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

VpnService таны өмнөөс юу хийхгүй вэ

Эргэн тойронд нь зохион бүтээхээс өмнө хоёр хязгаарыг мэдэх нь зүйтэй. Ямар ч энгийн апп Wi-Fi-аас гадна системийн прокси эсвэл PAC файл суулгаж чадахгүй бөгөөд энэ хэсэг өөрчлөгдөөгүй. Апп тус бүрийн зам өөрчлөгдсөн: API 29-өөс өмнө VpnService.Builder прокси огт авч чаддаггүй байсан бол API 29-өөс эхлэн setHttpProxy(ProxyInfo.buildPacProxy(uri)) платформд VPN сүлжээнд үнэлэх PAC скриптийг өгдөг. Хуучин API-г зорих эсвэл PAC загвар дүрмийг илэрхийлж чадахгүй үед дүрмийг өөрийн кодоо үнэлээрэй. UDP ч үнэгүй биш: хөтчүүд SOCKS проксигоор зөвхөн TCP илгээдэг, ихэнх SOCKS5 клиент UDP ASSOCIATE-г хэзээ ч хэрэгжүүлдэггүй тул проксид суурилсан загвар нь TCP эрүүл харагдах үед UDP-г хаядаг эсвэл алдагдана.

Энэ хоёр дахь хязгаар нь UDP-д суурилсан протокол энгийн сүлжээнд ажиллаж, VPN холбогдсон мөчид яагаад бүтэлгүйтдэг шалтгаан юм. Хэрэв туннель UDP зөөх ёстой бол дамжуулагч нь зөвхөн өөр сокетын төрөлтэй TCP зам биш, харин түүнд зориулсан дамжуулалтын замыг хэрэгжүүлэх ёстой.

Энэ дарааллаар шалгана уу

Жагсаалтыг дарааллаар нь ажиллуулж, бүтэлгүйтсэн эхний шатанд зогсоорой, учир нь өмнөх нь тэсэхгүй бол дараагийн шалгалт бүр чимээ шуугиан юм.

  1. Суулгасан маршрутуудыг жагсааж, DNS бус пакетууд TUN интерфэйсэд огт орж байгаа эсэхийг батал.
  2. Нэг блоклогдсон, нэг зөвшөөрөгдсөн нэрэнд асуулгын нэр, шийдвэр, хариу кодыг бүртгэ.
  3. Шийдэгчийн сокет хамгаалагдсан, сонгосон шийдэгч туннелийн дотроос хариулж байгааг батал.
  4. Интерфэйсийн MTU болон гараар бүтээсэн нэг хариуны шалгах нийлбэрийг батал.
  5. Мөн хуудсыг Wi-Fi болон үүрэн сүлжээнд давтаж үзээрэй, учир нь операторын шийдэгч, замын MTU ялгаатай.

Тав нь тэсэж, хуудас дандаа зогсолт хийвэл дараагийн сэжигтэн бол дамжуулагч өөрөө: баригдсан хүсэлтийг баригдсан хариутай харьцуулж, дутуу байтын тоо эсвэл хагас хаагдсан сокетыг хай. VpnService.Builder-ийн лавлагаа маршрут, DNS, MTU-ийн гэрээг хамардаг бөгөөд protect() нь builder-ийн сонголт биш, тусдаа VpnService дуудлага юм; холбогдсон интерфэйс нь зөвхөн эхний гэрээ биелсэнийг илэрхийлнэ.

Холбоотой нийтлэлүүд