કોર્પોરેટ VPN પર કન્ટેનર HTTPS અટકી જાય છે? DTLS પગની કસોટી કરો

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

બે ટ્રાન્સપોર્ટ, એક ગૂંચવણભરી લક્ષણ

TLS આધારિત કોર્પોરેટ ક્લાયન્ટ સામાન્ય રીતે સામાન્ય TLS કનેક્શન પર પ્રમાણીકરણ કરે છે, પછી સત્ર માટે UDP આધારિત બીજી ડેટા ચેનલ પર વાટાઘાટ કરે છે. જ્યારે તે બીજો પગ કામ કરે છે, ત્યારે થ્રુપુટ અને લેટન્સી સુધરે છે. જ્યારે તે ફિલ્ટર થાય છે અથવા માર્ગમાં ફિટ થઈ શકતો નથી, ત્યારે બલ્ક ટ્રાન્સફર પહેલાંનું બધું સફળ થાય છે અને ટ્રાન્સફર પોતે અટકી જાય છે, જે ઉપરની પેટર્ન બરાબર છે.

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

અનુભવથી નહીં, પ્રયોગથી નિર્ણય કરો

સૌથી સસ્તો પ્રયોગ UDP ડેટા ચેનલ બંધ કરે છે અને વિનંતીનું પુનરાવર્તન કરે છે. ડેસ્કટોપ રેપરને બદલે કમાન્ડ-લાઇન ક્લાયન્ટ વાપરો, જેથી ફ્લેગ ખરેખર લાગુ થાય: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. જો અટકેલી વિનંતી હવે પૂરી થાય, તો DTLS પગ જ સમસ્યા હતો અને બાકીનું ઘોંઘાટ હતું.

એક જ કન્ટેનરમાંથી બંને દિશામાં પરિણામની પુષ્ટિ કરો: ફ્લેગ સાથે એક બલ્ક વિનંતી અને વગર એક. ફ્લેગનું અનુસરણ કરતો વર્તન ફેરફાર પુરાવો છે; આખરે લોડ થતું પેજ પુરાવો નથી.

જો ફ્લેગ તેને ઠીક કરે, તો કારણ નક્કી કરો

ત્રણ સ્થિતિઓ સમાન લક્ષણ ઉત્પન્ન કરે છે, અને તે વિવિધ પ્રતિસાદ માગે છે. માર્ગ UDPને સંપૂર્ણ ફિલ્ટર કરી શકે છે, જે તે નેટવર્ક માટે ફ્લેગને યોગ્ય કાયમી જવાબ બનાવે છે. માર્ગ UDPને મંજૂરી આપી શકે છે પણ મોટા ડેટાગ્રામ ફેંકી શકે છે, જે ફિલ્ટરિંગ નહીં પણ MTU તરફ ઇશારો કરે છે. અથવા માર્ગ એટલો ક્ષયકારક હોઈ શકે કે UDP પગ TCP કરતાં ખરાબ કામ કરે, જે પહોંચનો નહીં પણ ક્ષમતાનો નિર્ણય છે.

વર્કઅરાઉન્ડનું દસ્તાવેજીકરણ કરતાં પહેલાં તેમને અલગ પાડો. ફિલ્ટરિંગ દરેક પેકેટ કદમાં ટકી રહે છે, MTU સમસ્યાઓ ફક્ત થ્રેશોલ્ડની ઉપર દેખાય છે, અને ક્ષય સ્વચ્છ અટકવા તરીકે નહીં પણ પુનઃપ્રેષણ અને બદલાતા વિલંબ તરીકે દેખાય છે. દરેક પરીક્ષણ ક્લાયન્ટ રૂપરેખા બદલ્યા વિના કારણને સાંકડું કરે છે.

વર્કઅરાઉન્ડ રાખતાં પહેલાં પેકેટ કદ તપાસો

જો કદ કારણ હોય, તો ટનલ ઇન્ટરફેસ એવા પેકેટ સ્વીકારે છે જે માર્ગ વહન કરી શકતો નથી, અને પેલોડ વધતાં જ સમસ્યા કોઈપણ ટ્રાન્સપોર્ટ પર પાછી આવે છે. ઇન્ટરફેસની સરખામણી કરો: હોસ્ટ પર ip link show tun0, પછી નેટવર્ક વિકલ્પોમાં નોંધાયેલ MTU વાંચવા docker network inspect bridge. ઓછું વહન કરતી ટનલ નીચે હજી 1500 બાઇટ પર રહેલો કન્ટેનર બ્રિજ સામાન્ય શોધ છે.

ટનલની અંદર નોટ-ફ્રેગમેન્ટ પરીક્ષણ સાથે જાણીતા સારા કદથી ઉપર તપાસો, પછી કન્ટેનર નેટવર્કનું MTU ઘટાડો અથવા ટનલ પર TCP MSS ક્લેમ્પ કરો. બેમાંથી કોઈપણ સુધારો ઘણી વાર UDP માર્ગને ફરી વાપરી શકાય તેવો બનાવે છે અને ફ્લેગની જરૂર દૂર કરે છે, જે ફિલ્ટરિંગ કારણ ન હોય ત્યારે વધુ સારું પરિણામ છે.

તમે શું બદલવા તૈયાર છો તે નક્કી કરો

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

તમે કોઈપણ વિકલ્પ પસંદ કરો, ટનલે આખરે કયો ટ્રાન્સપોર્ટ વાપર્યો અને કેમ તે નોંધો. કોઈએ મહિનાઓ પહેલાં ઉમેરેલા ફ્લેગ પર ચૂપચાપ આધાર રાખતું કન્ટેનર જ આગલું વિક્ષેપ છે, અને તેને ડિબગ કરનારને ખબર નહીં પડે કે ફ્લેગ ફિલ્ટરિંગ માટેનું વર્કઅરાઉન્ડ હતું કે MTU પ્રયોગનું અવશેષ.