Корпорацийн VPN-ийн ард аппын хүсэлтүүд бүтэлгүйтэж, хөтөч нь ажиллаж байна

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

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

Апп үнэхээр илгээдэг хүсэлтийг харна уу

Тохиргоог хүрэхээс өмнө аппад юу хийж байгаагаа хэлүүлээрэй. Проксийг тодорхой унтраасан нэг хүсэлтийн бичлэг ба энгийн портын шалгалт танд дараагийн алхмуудтай харьцуулах хоёр суурь шугам өгнө. Прокси унтраалттай үед хүсэлт амжилттай болбол дөрвөн давхаргын гурав нь аль хэдийн дууссан.

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

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

Апп хэн ч тохируулаагүй проксийг өвлөж авсан

Ихэнх HTTP стек прокси тохиргоог үйлдлийн системээс анхдагчаар уншдаг. Корпорацийн VPN клиент үүнийг өөрийн нэвтрэх профайлын хэсэг болгон суулгадаг нь элбэг, тиймээс хүсэлтүүд хөгжүүлэгчийн кодонд хэзээ ч дурдагдаагүй проксигоор гардаг. .NET-д анхдагч боловсруулагч IE/WinHTTP тохиргооноос авдаг; Java -Dhttp.proxyHost уншдаг; Node-д номын сан нэмэх хүртэл прокси дэмжлэг байхгүй. Бүтэлгүйтэл цэвэр татгалзал байх нь ховор, иймээс хүмүүс сервер рүү харж эхэлдэг.

Шалгалт нэг хүсэлтийн зардалтай: нэг боловсруулагч дээр проксийг тодорхой унтраагаад харьцуулна уу.

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

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

Таны сонгосон порт бодлогын зөвшөөрдөг порт биш

Замчлагдсан хост нь зөвшөөрөгдсөн үйлчилгээ биш. Корпорацийн бодлого ихэвчлэн гадагш веб портуудыг зөвшөөрч, бусад нь хаядаг тул 8080 эсвэл 1883 дээрх үйлчилгээ хүрэхгүй байхад 443 сайн ажилладаг. Хөтөч энд юу ч батлахгүй: тэр тодорхойлолтоор 443 ашигладаг.

Мөн адил үйлчилгээг 443-ийн ард нийтэлж, үл хамаарах зүйл гуйхаас өмнө нэрээр нь хүрнэ үү. Хэрэв үл хамаарах зүйл үнэхээр шаардлагатай бол нэг эх сурвалжийн муж, нэг зорьсон газарт хязгаарлаж, хэн нэгний хувийн тойрч гарах зам биш, үйлчилгээний тодорхойлолтын хэсэг гэж үзнэ үү.

Зам дахин тохируулдаг түүхий TCP

Удаан амьдрах түүхий TCP холболтууд хамгийн ойлгомжгүйгээр бүтэлгүйтдэг давхарга. Веб урсгалыг зөвшөөрдөг зам ч гэсэн ер бусын гадагш TCP-г дахин тохируулах эсвэл дахин бичих боломжтой бөгөөд клиент тасалдал мэт уншигдах socket алдаа мэдээлдэг. Мессеж болон үйл явдлын үйлчилгээнүүд ийм төрлийн сүлжээнд зориулж WebSocket тээврийг санал болгодог бөгөөд сэлгэх нь туннелийн өөрчлөлт биш, клиентийн сонголт юм.

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

Зөвхөн том ачаалалд хаагддаг холболтууд

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

Ачааллыг аппын түвшинд хэсэглэнэ үү. Үүнийг MTU-ийн ажлаас тусдаа байлга: туннелийн пакетын хэмжээг багасгах нь энгийн TCP сессууд тогтмол байт тоонд гацах үед тусалдаг бөгөөд зуучлагч хэт том гэж үзсэн мессежид юу ч хийхгүй.

Дөрвийг нэг гүйлтэд хэрхэн ялгах вэ

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

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

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