കോർപ്പറേറ്റ് 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 പരീക്ഷണത്തിന്റെ ശേഷിപ്പായിരുന്നോ എന്ന് അറിയില്ല.