Permintaan aplikasi gagal di balik VPN perusahaan, tetapi peramban berfungsi

Anda membuka portal internal di peramban dan portal itu termuat. Anda menjalankan aplikasi yang memanggil host yang sama dan aplikasi itu gagal, dengan pesan yang tidak menyebut satu lapisan pun. Terowongan membawa peramban, jadi terowongan bukan tersangka pertama. Empat hal berada di antara permintaan Anda dan layanan, dan masing-masing meninggalkan jejak berbeda. Inilah urutan yang saya tempuh, dimulai dari permintaan yang benar-benar dikirim aplikasi, bukan dari halaman pengaturan klien VPN.

Lihat permintaan yang benar-benar dikirim aplikasi

Sebelum menyentuh konfigurasi, biarkan aplikasi memberi tahu apa yang dilakukannya. Tangkapan satu permintaan dengan proxy dimatikan secara eksplisit dan uji porta sederhana memberi Anda dua garis dasar yang menjadi pembanding langkah berikutnya. Jika permintaan berhasil dengan proxy mati, Anda sudah menyelesaikan tiga dari empat lapisan.

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

Jalankan dua perintah terakhir ke tujuan yang sama dan perhatikan di mana keduanya berbeda. Peramban yang berfungsi plus curl yang berfungsi plus aplikasi yang tidak berfungsi mempersempit masalah ke sesuatu yang ditambahkan aplikasi: proxy, transport, atau ukuran pesan.

Aplikasi mewarisi proxy yang tidak dikonfigurasi siapa pun

Sebagian besar tumpukan HTTP membaca konfigurasi proxy dari sistem operasi secara bawaan. Klien VPN perusahaan sering memasang satu sebagai bagian dari profil aksesnya, sehingga permintaan keluar melalui proxy yang tidak pernah disebut pengembang di dalam kode. Di .NET, penangan bawaan mengambil dari pengaturan IE/WinHTTP; Java membaca -Dhttp.proxyHost; Node tidak punya dukungan proxy bawaan sampai sebuah pustaka menambahkannya. Kegagalan jarang berupa penolakan bersih, itulah sebabnya orang mulai melihat ke server.

Ujinya hanya butuh satu permintaan: matikan proxy secara eksplisit pada satu penangan lalu bandingkan.

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

Jika itu berhasil, perbaikannya ada di konfigurasi aplikasi, bukan di terowongan. Ulangi audit untuk setiap runtime di proyek, karena masing-masing membaca sumber berbeda dan mungkin hanya satu yang rusak.

Porta yang Anda pilih bukan porta yang diizinkan kebijakan

Host yang dirutekan bukan berarti layanan yang diizinkan. Kebijakan perusahaan biasanya mengizinkan porta web keluar dan membuang sisanya, sehingga layanan pada 8080 atau 1883 tidak terjangkau sementara 443 berjalan baik. Peramban tidak membuktikan apa pun di sini: ia memakai 443 menurut definisi.

Terbitkan layanan yang sama di balik 443 dan capai dengan namanya sebelum meminta pengecualian. Jika pengecualian benar-benar diperlukan, batasi pada satu rentang sumber dan satu tujuan dan perlakukan sebagai bagian dari definisi layanan, bukan sebagai akal-akalan pribadi seseorang.

TCP mentah yang direset jalur

Koneksi TCP mentah yang berumur panjang adalah lapisan yang gagal paling membingungkan. Jalur yang mengizinkan lalu lintas web masih dapat mereset atau menulis ulang TCP keluar yang tidak biasa, dan klien melaporkan galat soket yang terbaca seperti gangguan. Layanan pesan dan peristiwa biasanya menyediakan transport WebSocket justru untuk jaringan seperti ini, dan beralih adalah opsi klien, bukan perubahan terowongan.

Ganti transport, uji ulang, dan jangan ubah hal lain dalam jalankan yang sama. Uji satu variabel itu memberi tahu Anda apakah reset datang dari jalur atau dari layanan.

Koneksi yang menutup hanya pada muatan besar

Permintaan yang berhasil lalu mati sekitar satu detik kemudian, tetapi hanya ketika badan besar, menunjuk ke batas ukuran di suatu tempat di tengah. Perantara yang menghitung bita pesan dapat menjatuhkan koneksi di tengah transfer, dan klien melaporkan penutupan tak normal alih-alih batas waktu.

Pecah muatan di lapisan aplikasi. Pisahkan itu dari pekerjaan MTU: menurunkan ukuran paket terowongan membantu ketika sesi TCP biasa macet pada jumlah bita yang tetap, dan tidak melakukan apa pun untuk pesan yang dianggap terlalu besar oleh perantara.

Cara membedakan keempatnya dalam satu lintasan

Tiga pengamatan menyelesaikan sebagian besar kasus. Apakah kegagalan terjadi segera atau hanya dengan badan besar? Apakah permintaan yang sama berhasil saat proxy dimatikan? Apakah hasilnya berubah ketika Anda mengganti porta atau transport? Tuliskan jawabannya sebelum perubahan berikutnya, karena VPN perusahaan plus proxy warisan plus nilai bawaan aplikasi memberi Anda tiga penyebab masuk akal sekaligus.

Pertahankan satu variabel per uji dan catat host tujuan yang Anda pakai. Tanpa garis dasar itu, orang berikutnya mengulang keempat langkah dari awal.