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

Хоёр дахь алдаа нь аюултай: туннель ажиллаж, хуудсууд ачаалагдаж, зөвхөн гарах хаяг буруу байна.

Туннелээс биш, сонсогчоос эхэл

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

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

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

Ямар нэг зүйлийг засахаас өмнөх дөрвөн шалгалт

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

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

Төхөөрөмжийн хаяг хялбар: ip -4 addr show dev tun0 одоогийн хаягийг хэвлэж, ip -4 route get 1.1.1.1 тухайн очих газарт цөм аль интерфэйсийг сонгохыг харуулна. Яг хаягт уягдсан дамжуулагч хаяг алга болоход чангаар бүтэлгүйтнэ. Төхөөрөмжид уягдсан эсвэл өгөгдмөл эх рүү буцсан дамжуулагч ажилласаар гоожиж, энэ нь чимээгүй үр дүн юм.

Баримт бичгийг хайлтын дээд үр дүнтэй биш, таны ажиллуулж буй хувилбартай тааруул. Squid-ийн гарч буй хаягийн заавар нь v7 болон өмнөх хувилбаруудад баримтлагдсан бөгөөд v8 баримт бичиг тухайн заавар тэнд байхгүй гэдгийг тодорхой хэлдэг тул түүнд тулгуурласан скрипт энэ хил хязгаарыг давахгүй (Squid tcp_outgoing_address лавлагаа-г үз). Ямар нэг зүйлийг дахин ачаалахаас өмнө бүтээгдэхүүний өөрийн задлагчаар шалга: squid -k parse алдааг мэдээлж, ажиллаж буй процессд хүрэлгүй гарна.

Туннель бүрийг дугаарлаж, хуучирсан солилцоог хая

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

Ажлыг дөрвөн алхамд зохион байгуул: хуучин гарцын төлөвийг хүчингүй болго, холболтын эзэн дууссаныг мэдэгдэх хүртэл хүлээ, зөвхөн удирдлагатай хэсгийг барь, дараа нь үйлчилгээний менежерээр шалгуулж идэвхжүүл. Бүх файлыг хоёр хаягийн утгаас дахин үүсгэх нь сонсогчийн хязгаарлалт, баталгаажуулалт, очих газрын бодлого чимээгүй алга болох зам юм. Зориуд зогсоохыг хүндэтгэ. Хэрэглэгчийн унтраасан туннель руу залгасаар байх туслах нь алдаа, тэсвэрлэх чадвар биш.

Нээлттэй сокетууд шинэ хаягийг дагахгүй

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

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

Шинэ гарцыг шинэ хүсэлтээр батал

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

Задлан шинжилгээ, дахин ачаалолт, хүсэлтийг тусдаа командаар барь, бүтэлгүйтэл нэг алхам руу заана. Эхний хоёр нь бүтэлгүйтэхэд юу ч өөрчлөхгүй, яг ийм учраас дахин эхлүүлэхийн өмнө ажилладаг.

squid -k parse
sudo squid -k reconfigure
curl -x http://127.0.0.1:3128 -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://example.com

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

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