કોર્પોરેટ VPN પાછળ એપની વિનંતીઓ નિષ્ફળ જાય છે, પણ બ્રાઉઝર કામ કરે છે

તમે બ્રાઉઝરમાં આંતરિક પોર્ટલ ખોલો છો અને તે લોડ થાય છે. તમે એ જ હોસ્ટને કૉલ કરતી એપ્લિકેશન ચલાવો છો અને તે નિષ્ફળ જાય છે, એવા સંદેશ સાથે જે કોઈ સ્તરનું નામ લેતો નથી. ટનલ બ્રાઉઝરને વહન કરે છે, તેથી ટનલ પ્રથમ શંકાસ્પદ નથી. તમારી વિનંતી અને સેવા વચ્ચે ચાર વસ્તુઓ છે, અને દરેક અલગ નિશાન છોડે છે. આ તે ક્રમ છે જે હું અનુસરું છું, એપ ખરેખર મોકલે છે તે વિનંતીથી શરૂ કરીને, 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 ને રીસેટ કે ફરી લખી શકે છે, અને ક્લાયન્ટ સોકેટ ભૂલ જણાવે છે જે વિક્ષેપ જેવી લાગે છે. સંદેશા અને ઇવેન્ટ સેવાઓ સામાન્ય રીતે આવા નેટવર્ક માટે જ WebSocket ટ્રાન્સપોર્ટ આપે છે, અને બદલવું એ ક્લાયન્ટનો વિકલ્પ છે, ટનલનો ફેરફાર નહીં.

ટ્રાન્સપોર્ટ બદલો, ફરી પરીક્ષણ કરો અને એ જ રનમાં બીજું કંઈ બદલો નહીં. એક ચલવાળું પરીક્ષણ તમને કહે છે કે રીસેટ માર્ગથી આવ્યો કે સેવાથી.

જોડાણો જે ફક્ત મોટા પેલોડ પર બંધ થાય છે

સફળ થઈને લગભગ એક સેકન્ડ પછી મરી જતી વિનંતી, પણ ફક્ત ત્યારે જ જ્યારે બૉડી મોટી હોય, મધ્યમાં ક્યાંક કદની મર્યાદા તરફ ઇશારો કરે છે. સંદેશાના બાઇટ ગણતું મધ્યસ્થ જોડાણને સ્થાનાંતરણની વચ્ચે પડી જવા દઈ શકે છે, અને ક્લાયન્ટ સમયસીમાને બદલે અસામાન્ય બંધ હોવાનું જણાવે છે.

પેલોડને એપ્લિકેશન સ્તરે ટુકડામાં વિભાજિત કરો. તેને MTU કાર્યથી અલગ રાખો: ટનલનું પેકેટ કદ ઘટાડવું ત્યારે મદદ કરે છે જ્યારે સામાન્ય TCP સત્રો સ્થિર બાઇટ ગણતરી પર અટકી જાય છે, અને મધ્યસ્થ જેને ખૂબ મોટો ગણે તેવા સંદેશા માટે તે કંઈ કરતું નથી.

એક જ પાસમાં ચારને કેવી રીતે અલગ પાડવા

ત્રણ અવલોકનો મોટાભાગના કિસ્સા નક્કી કરે છે. નિષ્ફળતા તરત થાય છે કે ફક્ત મોટી બૉડી સાથે? પ્રોક્સી બંધ હોય ત્યારે એ જ વિનંતી સફળ થાય છે? પોર્ટ કે ટ્રાન્સપોર્ટ બદલો ત્યારે પરિણામ બદલાય છે? આગળના ફેરફાર પહેલા જવાબો લખી લો, કારણ કે કોર્પોરેટ VPN વત્તા વારસાગત પ્રોક્સી વત્તા એપનું ડિફૉલ્ટ તમને એકસાથે ત્રણ સંભવિત કારણો આપે છે.

દરેક પરીક્ષણમાં એક ચલ રાખો અને તમે વાપરેલું ગંતવ્ય હોસ્ટ નોંધો. એ આધારરેખા વિના, આગલી વ્યક્તિ ચારેય પગલાં શરૂઆતથી પુનરાવર્તિત કરે છે.