కార్పొరేట్ 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 ప్రయోగం యొక్క మిగిలిన భాగమా అని తెలియదు.