Permintaan aplikasi gagal di sebalik VPN korporat tetapi pelayar berfungsi

Anda membuka portal dalaman dalam pelayar dan ia dimuatkan. Anda menjalankan aplikasi yang memanggil hos yang sama dan ia gagal, dengan mesej yang tidak menamakan mana-mana lapisan. Terowong membawa pelayar, jadi terowong bukan suspek pertama. Empat perkara berada antara permintaan anda dan perkhidmatan, dan setiap satu meninggalkan kesan berbeza. Inilah susunan yang saya ikuti, bermula daripada permintaan yang benar-benar dihantar oleh aplikasi, bukan dari halaman tetapan klien VPN.

Lihat permintaan yang benar-benar dihantar oleh aplikasi

Sebelum menyentuh konfigurasi, biarkan aplikasi memberitahu anda apa yang dilakukannya. Tangkapan satu permintaan dengan proksi dimatikan secara jelas dan ujian port mudah memberikan anda dua garis dasar yang menjadi pembanding langkah seterusnya. Jika permintaan berjaya dengan proksi dimatikan, anda sudah selesai tiga daripada 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 yang terakhir ke destinasi yang sama dan perhatikan di mana ia berbeza. Pelayar yang berfungsi serta curl yang berfungsi serta aplikasi yang tidak berfungsi menyempitkan masalah kepada sesuatu yang ditambah oleh aplikasi: proksi, pengangkutan atau saiz mesej.

Aplikasi mewarisi proksi yang tiada siapa konfigurasikan

Kebanyakan tindanan HTTP membaca konfigurasi proksi daripada sistem pengendalian secara lalai. Klien VPN korporat sering memasang satu sebagai sebahagian daripada profil aksesnya, jadi permintaan keluar melalui proksi yang tidak pernah disebut oleh pembangun dalam kod. Dalam .NET, pengendali lalai mengambil tetapan IE/WinHTTP; Java membaca -Dhttp.proxyHost; Node tiada sokongan proksi terbina dalam sehingga pustaka menambahnya. Kegagalan jarang berupa penolakan bersih, itulah sebabnya orang mula melihat pelayan.

Ujian ini berharga satu permintaan: matikan proksi secara jelas pada satu pengendali dan bandingkan.

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

Jika itu berjaya, pembaikan terletak pada konfigurasi aplikasi, bukan pada terowong. Ulangi audit untuk setiap runtime dalam projek, kerana setiap satu membaca sumber berbeza dan mungkin hanya satu yang rosak.

Port yang anda pilih bukan port yang dibenarkan oleh dasar

Hos yang dihalakan bukan perkhidmatan yang dibenarkan. Dasar korporat biasanya membenarkan port web keluar dan membuang yang lain, jadi perkhidmatan pada 8080 atau 1883 tidak dapat dicapai manakala 443 berfungsi dengan baik. Pelayar tidak membuktikan apa-apa di sini: ia menggunakan 443 mengikut takrifan.

Terbitkan perkhidmatan yang sama di sebalik 443 dan capai ia dengan nama sebelum meminta pengecualian. Jika pengecualian benar-benar perlu, hadkan ia kepada satu julat sumber dan satu destinasi dan anggap ia sebagai sebahagian daripada takrifan perkhidmatan, bukan sebagai jalan pintas peribadi seseorang.

TCP mentah yang diset semula oleh laluan

Sambungan TCP mentah yang panjang hayatnya ialah lapisan yang gagal dengan cara paling mengelirukan. Laluan yang membenarkan trafik web masih boleh menyet semula atau menulis semula TCP keluar yang luar biasa, dan klien melaporkan ralat soket yang dibaca seperti gangguan. Perkhidmatan pemesejan dan peristiwa biasanya menyediakan pengangkutan WebSocket khusus untuk rangkaian seperti ini, dan bertukar ialah pilihan klien, bukan perubahan terowong.

Tukar pengangkutan, uji semula dan jangan ubah apa-apa lagi dalam larian yang sama. Ujian satu pemboleh ubah itu memberitahu anda sama ada set semula datang daripada laluan atau daripada perkhidmatan.

Sambungan yang tertutup hanya pada muatan besar

Permintaan yang berjaya dan kemudian mati kira-kira satu saat kemudian, tetapi hanya apabila badan besar, menunjuk kepada had saiz di suatu tempat di tengah. Perantara yang mengira bait mesej boleh menjatuhkan sambungan di tengah pemindahan, dan klien melaporkan penutupan tidak normal dan bukan tamat masa.

Pecahkan muatan pada lapisan aplikasi. Asingkan ini daripada kerja MTU: menurunkan saiz paket terowong membantu apabila sesi TCP biasa tersekat pada kiraan bait yang tetap, dan ia tidak melakukan apa-apa untuk mesej yang dianggap terlalu besar oleh perantara.

Cara membezakan keempat-empatnya dalam satu pusingan

Tiga pemerhatian menyelesaikan kebanyakan kes. Adakah kegagalan berlaku serta-merta atau hanya dengan badan besar? Adakah permintaan yang sama berjaya dengan proksi dimatikan? Adakah hasilnya berubah apabila anda menukar port atau pengangkutan? Tulis jawapannya sebelum perubahan seterusnya, kerana VPN korporat serta proksi warisan serta nilai lalai aplikasi memberikan tiga punca munasabah sekali gus.

Kekalkan satu pemboleh ubah setiap ujian dan catat hos destinasi yang anda gunakan. Tanpa garis dasar itu, orang seterusnya mengulangi keempat-empat langkah dari awal.