mitmproxy, DevTools, Gradle: VPN-ийн ард байх гурван давхарга
Loopback хэзээ ч туннельд ордоггүй. Шинж тэмдгийг сонсогч, итгэлцлийн сан эсвэл пакет шүүлтүүрт ангилаад, үнэхээр бүтэлгүйтсэн давхаргыг засаарай.
VPN холбогдож, хамааралгүй гурван хэрэгсэл гурван өөр аргаар бүтэлгүйтдэг тэр үдээс хойш. mitmproxy хүсэлтүүдийг харахаа болино, Chrome дибаглагчийг татгалзаж, Gradle BindException локал сокетыг холбох үед шиддэг. Нийтлэг сэжиг нь туннель localhost-ыг блоклодог гэсэн юм. Тэр чадахгүй: 127.0.0.1 цөмийн дотор боловсруулагдаж, хэзээ ч адаптерт хүрдэггүй, гарцын тухай ярих ч хэрэггүй.
Гурван давхарга, гурван өөр эвдрэл
Клиенттэй хамт өөрчлөгдсөн зүйл бол loopback руу хүрэх зам биш. Энэ нь локал прокси, машины итгэлцлийн сан, пакет шүүлтүүр бөгөөд тус бүр хөгжүүлэгчийн ажлын урсгалын өөр хэсгийг эвддэг. Шинж тэмдгийг зөв мөрөнд оруулах нь оношилгооны ихэнх хэсэг юм:
| Symptom | Layer | First check |
|---|---|---|
| Proxy sees no traffic | Local proxy or listener | ss -lntp, or netstat -ano on Windows |
| TLS error in one tool only | Trust store | Which CA bundle does that runtime read? |
| Local bind or connect refused | Packet filter or port owner | Who holds the port, and what rule drops it? |
Энэ төрлийн бараг бүх тайлан сүүлийн мөрнөөс эхэлж, дээшээ явдаг нь эсрэгээрээ. Туннель нь loopback трафикийг харж чадахгүй гэдгээ нотолсон цорын ганц давхарга тул хамгийн бага сэжиг хүлээх ёстой. Процесс юу холбосноос эхэлж, дараа нь ямар гэрчилгээнд итгэдэг талаар асууж, зөвхөн дараа нь машины бодлогыг хараарай.
Туннель биш, сонсогчоос эхэл
Хэзээ 127.0.0.1:8080 дээрх прокси трафик хүлээж авахаа болиход гурвын нэг нь болсон: хэзээ ч эхлээгүй, өөр порт холбосон, эсвэл шүүлтүүр loopback холболтыг унагасан. Сонсож буй сокетуудыг жагсаах нь үүнд нэг командаар хариулж, хоёр хэрэгсэл хэн нэгдүгээрт орсон талаар санал нийлэхгүй үед аль процесс портыг эзэмшиж байгааг ч харуулна.
Маршрут хайлт дахь локал хаяг нь нөгөө талаас мөн адил зүйлийг батална. ip route get loopback очих газар руу loopback төхөөрөмжийг мэдээлдэг, туннелийг хэзээ ч биш, энэ нь хэн нэгэн маршрутын өөрчлөлтийг шийдэл гэж санал болгоход бэлэн байлгахад хэрэгтэй өгүүлбэр юм.
Прокси давхарга: орчин бол конфигурац биш
Олон корпорацийн клиент HTTP прокси ажиллуулж, програмууд түүнийг ашиглана гэж хүлээдэг. Тохируулах нь HTTPS_PROXY шел дотор түүнийг хүндэтгэдэг командын мөрийн хэрэгслүүдийг засдаг бөгөөд өөрийн тохиргооны файлыг уншдаг хэрэгсэлд юу ч хийдэггүй. Gradle, Selenium, gRPC тус бүр өөрийн конфигурацтай зөвлөлддөг бөгөөд нэг терминалд экспортолсон прокси нь IDE-ийн эхлүүлсэн демонд үл үзэгдэх юм.
Контейнер хэрэгсэл нь энэ илэрдэг ердийн газар юм. Контейнерын loopback нь өөрийнх нь тул 127.0.0.1 контейнер дотор хэзээ ч хостны проксийг илэрхийлэхгүй; хостны хаяг эсвэл хостны сүлжээний тохиргоо шаардлагатай. Шел дээр ажиллаж, бүтээлт дээр бүтэлгүйтдэг засвар нь ихэвчлэн энэ мөр, туннель биш.
Итгэлцлийн давхарга: хэрэгсэл өөр санг уншдаг
Захлах нь хоёр дахь өөрчлөлт бөгөөд хамгийн төөрөгдүүлэх алдааг үүсгэдэг. Клиент шалгагдсан холболтуудад өөрийн гэрчилгээг танилцуулдаг тул корпорацийн үндэст итгэдэг хөтөч амжилттай болдог бол суулгасан CA сантай хэрэгсэл бүтэлгүйтдэг. certifi-ээр дамжуулсан Python requests бол сонгодог тохиолдол: үйлдлийн системийн сан зөв байж болох ч хүсэлт бүтэлгүйтсэн хэвээр байна, учир нь тэр гүйцэтгэх орчин түүнийг хэзээ ч уншдаггүй. Алдааны текст захлалыг ховор дурддаг тул энэ мөрийг эвдэрсэн төгсгөлийн цэг гэж буруу оношилдог.
Төгсгөлийн цэг үнэхээр юу танилцуулж байгааг хэрэгсэл баталгаажуулсан зүйлтэй харьцуулаарай. openssl s_client серверийн илгээсэн гинжийг харуулна; хэрэгслийн өөрийн баталгаажуулалтын гаралт юу шийдсэнийг харуулна. Тэд нийцэхгүй үед, REQUESTS_CA_BUNDLE эсвэл SSL_CERT_FILE нь тэр гүйцэтгэх орчны хөшүүрэг бөгөөд корпорацийн үндэс нь тэр орчин уншдаг санд байх ёстой, зөвхөн зарим хэрэгсэл хүндэтгэдэг дэлхийн газарт биш.
SSL алдааг засдаг хувилбарын өөрчлөлт нь VPN-ийн тухай биш, итгэлцэл ба шифрлэлтийн бодлогын тухай нотолгоо юм. SOAP клиентийг ажиллуулсан Python-ийн хувилбар бууралт нь суулгасан CA санг болон анхдагч TLS тохиргоог өөрчилсөн; сүлжээний зам хөдлөөгүй.
Шүүлтүүрийн давхарга: тэр loopback-ыг ч унагаж чадна
Гурав дахь өөрчлөлт нь пакет шүүлтүүр бөгөөд зарим бүтээгдэхүүн туннельд орохгүй трафикийг унагадаг дүрмийг суулгадаг. Локал сонсогчид ч хамрагдаж болно. Энэ нь ажиллаж байсан сокетыг татгалзсан эсвэл хугацаа хэтэрсэн холболт болгож, үүссэн алдаа нь машины бодлого биш, програмын алдаа мэт харагддаг.
Портын эзэмшил нь энэ давхаргын нөгөө хагас юм. BindException сокетыг нээж чадаагүй гэсэн үг бөгөөд энэ нь холболт татгалзахаас өөр бүтэлгүйтэл юм. Шүүлтүүрийг буруутгахаасаа өмнө портыг өөр процесс аль хэдийн эзэмшиж байгаа эсэхийг шалгаад, дараа нь локал трафикийг унагадаг дүрмийг хайж, бүтээгдэхүүний дэмждэг хамгийн нарийн зөвшөөрлийг нэмээрэй. Нэг дибаг портын төлөө өрсөлдөж буй хоёр хэрэгсэл бодлогын блоктой яг ижил мессеж гаргадаг бөгөөд тэдгээрийн зөвхөн нэгийг нь галт хананы өөрчлөлтөөр засдаг.
Chrome-ийн дибаг порт нь мөн адил гэр бүлд бүтэлгүйтдэг. Хөтөч эхэлдэг, драйвер DevTools-ийн төгсгөлийн цэгт хүрч чадахгүй, мессеж нь сүлжээг биш DevTools-ыг нэрлэдэг. Нэмэлт эхлүүлэх тугууд болон илүүдэл драйвер менежер нь аль процесс портыг эзэмшихийг өөрчилдөг тул тэдгээрийг арилгах нь заримдаа VPN-ийг зассан мэт харагддаг.
Бүтэлгүйтсэн давхаргыг зас
Туннель биш, бүтэлгүйтсэн давхаргыг зас. Хүрэх боломжгүй loopback сонсогчид өөрийн сонсогч эсвэл портыг засах шаардлагатай. Итгэмжлэхгүй гэрчилгээнд корпорацийн үндсийг яг тэр гүйцэтгэх орчин хардаг газарт суулгах шаардлагатай, үл хамаарах зүйлийг нарийн байлгаж. Локал трафикийг унагадаг шүүлтүүрт идэвхгүй шүүлтүүр биш, тодорхой зөвшөөрлийн дүрэм хэрэгтэй, учир нь идэвхгүй болгох нь түүний хамгаалж байсан бусад бүхнийг дахин нээдэг.
VPN-ийг дахин холбох нь эдгээр давхаргын аль нэгийг ч шалгахгүй. Энэ нь тэднийг эвдсэн өөрчлөлтийг дахин ажиллуулдаг тул ижил гурван бүтэлгүйтэл дахин холбогдох бүрт буцаж ирж, клиентийг идэвхгүй орхидог дахин ачаалах бүрт алга болдог.