Virtio-യിൽ pfSense: offload ഓഫ് ചെയ്യുന്നതുവരെ TCP നിൽക്കുന്നു

ഒരു ക്ലയന്റ് റിപ്പോർട്ട് ചെയ്യുന്നു: ടണൽ കണക്റ്റ് ചെയ്യുന്നു, പിംഗ് ഉത്തരം നൽകുന്നു, ലോഗിൻ പേജ് ലോഡ് ചെയ്യുന്നു, പിന്നീട് ഓരോ ശ്രമത്തിലും കൈമാറ്റം അതേ സ്ഥലത്ത് തന്നെ മരവിക്കുന്നു. ഈ മാതൃക തന്നെ ഏറെ പറയുന്നു: എത്തിച്ചേരാനാകുന്നത് പ്രവർത്തിക്കുന്നു, തുടർച്ചയായ ത്രൂപുട്ട് പ്രവർത്തിക്കുന്നില്ല. ഫയർവാൾ തുറക്കുന്നതിന് മുൻപ് VPN ഈ പരാജയത്തിൽ ഉൾപ്പെട്ടിട്ടുണ്ടോ എന്ന് കണ്ടെത്തുക. അതേ ഗേറ്റ്വേ വഴി പാതയിൽ ടണൽ ഇല്ലാതെ വലിയ TCP അയക്കുക; അതും മരവിച്ചാൽ OpenVPN ഒരിക്കലും ഉൾപ്പെട്ടിട്ടില്ല.

virtio നെറ്റ്വർക്ക് കാർഡ് ഉപയോഗിക്കുന്ന pfSense അതിഥിക്ക് കൃത്യമായി ആ രൂപത്തിൽ പരാജയപ്പെടാൻ വളരെ നല്ല കാരണമുണ്ട്.

ചെറിയ പാക്കറ്റുകൾ കടക്കുന്നു, വലിയ TCP തൂങ്ങുന്നു

ഹാൻഡ്ഷേക്കുകൾ, DNS ഉത്തരങ്ങൾ, ICMP പ്രതിധ്വനികൾ എന്നിവ ചെറുതാണ്, സാധാരണയായി കടക്കുന്നു. തുടർച്ചയായ കൈമാറ്റങ്ങൾ അതിഥിയെ സെഗ്മെന്റ് ചെയ്യാൻ നിർബന്ധിക്കുന്നു, അവിടെയാണ് കേടായ offload പാത പുറത്തുവരുന്നത്. തകരാർ സമമിതിയായിരിക്കണമെന്നില്ല: പുറത്തേക്കുള്ള ട്രാഫിക് ശുദ്ധമായിരിക്കുമ്പോൾ അകത്തേക്കുള്ളത് വീഴാം, അല്ലെങ്കിൽ നേരെ മറിച്ചും, അതിനാൽ ഉപയോക്താവിന് ലോഗിൻ ചെയ്ത് പിന്നീട് ആദ്യ വലിയ പ്രതികരണത്തിൽ നിൽക്കാം. അതേ ക്ലയന്റ് മറ്റൊരു ഗേറ്റ്വേ വഴി പ്രവർത്തിക്കുന്നതിനാൽ കുറ്റം പുതിയ ഘടകത്തിന് മേൽ വീഴുന്നു.

അതിനാൽ ടണൽ ഇല്ലാതെ ഗേറ്റ്വേ പരീക്ഷിക്കുക. കുറച്ച് സെക്കൻഡ് നടക്കാൻ മതിയായ വലുപ്പമുള്ള LAN-ൽ നിന്ന് WAN-ലേക്കുള്ള ഡൗൺലോഡ് മതി, അത് ഏതെങ്കിലും ക്രമീകരണ മാറ്റത്തിന് മുൻപ് ചെയ്യണം, പിന്നീടുള്ള താരതമ്യത്തിന് അർഥമുണ്ടാകാൻ.

offload യഥാർഥത്തിൽ എന്താണ് വാഗ്ദാനം ചെയ്യുന്നത്

virtio പാരാവിർച്വൽ ആണ്: ഹോസ്റ്റും അതിഥിയും ജോലി പങ്കിടുന്നു, ഹോസ്റ്റ് ചെക്സം, സെഗ്മെന്റേഷൻ കഴിവുകൾ പ്രഖ്യാപിക്കുന്നു, അതിഥി തുടങ്ങിയത് പൂർത്തിയാക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു. അതിഥിയുടെ സ്റ്റാക്ക് അത് ചെയ്യുന്നില്ലെങ്കിൽ ഫ്രെയിമുകൾ അപൂർണ ചെക്സവുമായി പുറത്തുപോകുന്നു അല്ലെങ്കിൽ ഹോസ്റ്റ് അവ വലിച്ചെറിയുന്നു. എമുലേറ്റ് ചെയ്ത E1000 ലളിതവും മന്ദഗതിയിലുള്ളതുമായ മാതൃക നൽകുന്നു, അതിൽ pfSense-ൽ ഒരു മാറ്റവുമില്ലാതെ പ്രശ്നം മായുന്നു. കഴിവുകളുടെ ചർച്ച ഓരോ ഉപകരണത്തിനും വെവ്വേറെ നടക്കുന്നു, അതാണ് ഒരു അതിഥി മാസങ്ങളോളം പ്രവർത്തിക്കുമ്പോൾ അതിന്റെ പുനർനിർമിച്ച ഇരട്ട പ്രഥമ ദിവസം തന്നെ പരാജയപ്പെടുന്നതിന്റെ വിശദീകരണം.

ചർച്ച ചെയ്ത ഗണം ഹൈപ്പർവൈസർ പതിപ്പിനെയും തിരഞ്ഞെടുത്ത NIC മാതൃകയെയും ആശ്രയിച്ചിരിക്കുന്നു, നിങ്ങൾ ഇറക്കുമതി ചെയ്ത കോൺഫിഗറേഷനെ മാത്രമല്ല.

ഒരു ചെക്ക്ബോക്സ് virtio നിലനിർത്തുന്നു

pfSense ഇന്റർഫേസിൽ, സിസ്റ്റം പിന്നീട് വിപുലമായത് പിന്നീട് നെറ്റ്വർക്കിംഗ് എന്ന പാതയിൽ ഹാർഡ്വെയർ ചെക്സം offload പ്രവർത്തനരഹിതമാക്കുക എന്ന ചെക്ക്ബോക്സ് ഉണ്ട്. അത് അടയാളപ്പെടുത്തുമ്പോൾ അതിഥി ചെക്സങ്ങൾ സോഫ്റ്റ്വെയറിൽ കണക്കാക്കുന്നു, അത് pfSense-ന് പിന്നിലുള്ള FreeBSD സ്റ്റാക്ക് പാരാവിർച്വൽ ഉപകരണത്തിൽ നിന്ന് പ്രതീക്ഷിക്കുന്നതുമായി യോജിക്കുന്നു. അതേ പേജിലെ രണ്ട് ബന്ധപ്പെട്ട ഓപ്ഷനുകൾ ഹാർഡ്വെയർ TCP സെഗ്മെന്റേഷൻ offload-ഉം ഹാർഡ്വെയർ വലിയ സ്വീകരണ offload-ഉം ഉൾക്കൊള്ളുന്നു. ഹാൻഡ്ഷേക്കുകൾ വിജയിക്കുമ്പോൾ വലിയ കൈമാറ്റങ്ങൾ വിജയിക്കാത്തപ്പോൾ അവയിലേക്ക് തിരിയുക.

മാറ്റം ചെയ്യുമ്പോൾ NIC virtio ആയി തന്നെ വിടുക. E1000-ലേക്ക് മാറുന്നത് VM-ന്റെ മുഴുവൻ ആയുസ്സിലും ഓരോ പാക്കറ്റിലും CPU കത്തിക്കുന്നു, ഹോസ്റ്റ് അവകാശമായി ലഭിക്കുന്ന ആർക്കും കോൺഫിഗറേഷൻ പ്രശ്നം മറയ്ക്കുന്നു, ഇത് അൽപം മന്ദഗതിയിലുള്ളതും എന്നാൽ പ്രവചിക്കാവുന്നതുമായ ഡാറ്റാ പാതയേക്കാൾ മോശം കൈമാറ്റമാണ്.

ഇപ്പോൾ സ്വീകരിച്ച ചെലവ് അളക്കുക

സോഫ്റ്റ്വെയർ ചെക്സം ജോലി അതിഥിയിലേക്ക് മാറ്റുന്നു, അതിനാൽ ഒന്നും ചെലവില്ലെന്ന് കരുതുന്നതിനു പകരം പിന്നീട് ത്രൂപുട്ട് അളക്കുക. ചെറിയ VM-ൽ ശിക്ഷ യഥാർഥമാണ്, പക്ഷേ നിശബ്ദ നഷ്ടത്തിൽ നിന്ന് വ്യത്യസ്തമായി അത് കാണാവുന്നതും സ്ഥിരവുമാണ്. മുൻപും ശേഷവും ഇന്റർഫേസ് പിശക് കൗണ്ടറുകളും അതിഥിയുടെ കെർണൽ ലോഗും താരതമ്യം ചെയ്യുക. ബ്രിഡ്ജ് ഫിൽട്ടർ ചെയ്യുന്ന ഹൈപ്പർവൈസർ വ്യത്യസ്ത തെളിവുകളുള്ള പ്രത്യേക തകരാറാണ്, ഒരു offload പതാകയും അതിനെ സുഖപ്പെടുത്തില്ല.

ഓരോ പരീക്ഷണത്തിലും ഒരു കാര്യം മാറ്റി മെനു പാത, അടയാളപ്പെടുത്തിയ ബോക്സ്, അളന്ന സംഖ്യ എന്നിവ എഴുതുക. അടുത്ത പുനർനിർമിത അതിഥിയെ നേരിടുന്ന ആർക്കും മൂന്നും വേണ്ടിവരും.

BSD അടിസ്ഥാനമാക്കിയ മറ്റ് ഫയർവാളുകൾ അവയുടെ സ്വന്തം ഇന്റർഫേസ് ക്രമീകരണങ്ങളിൽ തുല്യമായ നിയന്ത്രണം നൽകുന്നു, അതിനാൽ മെനു പാത ഇല്ലെങ്കിലും യുക്തി ബാധകമാണ്.