Nebula punchy ക്രമീകരണങ്ങൾ: ഏതാണ് നിങ്ങളുടെ NAT ശരിയാക്കുന്നത്

രണ്ട് പിയറുകൾ വിളക്കുമാടത്തിലൂടെ പരസ്പരം കണ്ടെത്തി, പിന്നീട് നേരിട്ടുള്ള പാത നിർമ്മിക്കാൻ പരാജയപ്പെടുന്നു, ആദ്യ പ്രവണത എല്ലാ punchy ഓപ്ഷനുകളും ഓണാക്കുക എന്നതാണ്. ആ പ്രവണത മൂന്ന് മാറ്റങ്ങളുള്ള ക്രമീകരണം സൃഷ്ടിക്കുന്നു, ഏതാണ് പ്രധാനമെന്ന് അറിയാതെ. ക്രമീകരണങ്ങൾ വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു: ഒന്ന് ഇതിനകം ഉള്ള മാപ്പിംഗ് നിലനിർത്തുന്നു, മറ്റൊന്ന് വിപരീത ദിശയിൽ ഹസ്തദാനം ശ്രമിക്കുന്നു. ഏതെങ്കിലും തൊടുന്നതിന് മുൻപ് നിങ്ങളുടെ ചോദ്യം ഏതാണെന്ന് തീരുമാനിക്കുക.

സമയത്തിന് മുൻപ് എൻഡ്പോയിന്റ് സ്ഥിരീകരിക്കുക

പ്രതീക്ഷിച്ച വിലാസത്തിൽ ഒരിക്കലും പ്രത്യക്ഷപ്പെടാത്ത പിയറിനെ punch ട്യൂണിംഗ് രക്ഷിക്കില്ല. വിളക്കുമാടത്തിന് പിയറിനെക്കുറിച്ച് എന്തറിയാം, പിയറിന്റെ സ്വന്തം ക്രമീകരണം എന്ത് പ്രഖ്യാപിക്കുന്നു എന്ന് പരിശോധിക്കുക, കാരണം പഴയ bootstrap വിലാസമോ തെറ്റായി പ്രസിദ്ധീകരിച്ച സ്വകാര്യ വിലാസമോ എല്ലാ കടന്നുപോകൽ വിദ്യയെയും പരാജയപ്പെടുത്തുന്നു. സർട്ടിഫിക്കറ്റ് വിശ്വസനീയമാണെന്നും ഉറപ്പാക്കുക, കാരണം വിശ്വസനീയമല്ലാത്ത ഐഡന്റിറ്റി NAT പ്രധാനമാകുന്നതിന് വളരെ മുൻപ് സംഭാഷണം നിർത്തുന്നു. തുടർന്ന് UDP വിളക്കുമാടത്തിൽ എത്തുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക. സമയ മൂല്യങ്ങൾ ആദ്യം നോക്കേണ്ടതല്ല, ഒടുവിൽ നോക്കേണ്ടതാണ്.

നിങ്ങൾ പരീക്ഷിക്കുന്ന എൻഡ്പോയിന്റ് ജോടി രേഖപ്പെടുത്തുക, പിന്നീടുള്ള താരതമ്യങ്ങൾ രണ്ട് വേറെ യന്ത്രങ്ങളെക്കാൾ അതേ പിയറുകൾ ഉപയോഗിക്കാൻ.

punch മാപ്പിംഗ് സൂക്ഷിക്കുന്നു, respond ദിശ തുറക്കുന്നു

punch ഓപ്ഷൻ ഇതിനകം ടണൽ ഉള്ള പിയറിന്റെ അടിസ്ഥാന പാളി വിലാസത്തിലേക്ക് ഇടയ്ക്കിടെ ശൂന്യ പാക്കറ്റുകൾ അയക്കുന്നു. അതിന്റെ ലക്ഷ്യം മിന്നുന്നതല്ല: നേരിട്ടുള്ള പാത ആശ്രയിക്കുന്ന മാപ്പിംഗ് കാലഹരണപ്പെടാൻ സ്റ്റേറ്റ്ഫുൾ NAT അല്ലെങ്കിൽ ഫയർവാൾ അനുവദിക്കുന്നില്ല. respond ഓപ്ഷൻ വിളക്കുമാട അറിയിപ്പിൽ സംഭവിക്കുന്നത് മാറ്റുന്നു, ഹോസ്റ്റിനെ തന്നിലേക്ക് എത്താൻ ശ്രമിക്കുന്ന പിയറിലേക്ക് തിരികെ ഹസ്തദാനം ശ്രമിക്കാൻ പ്രേരിപ്പിക്കുന്നു. ഇവ വ്യത്യസ്ത പരാജയ രീതികളുള്ള വ്യത്യസ്ത സംവിധാനങ്ങളാണ്.

നേരിട്ടുള്ള പാത പ്രവർത്തിച്ച് പിന്നീട് ക്ഷയിക്കുമ്പോൾ punch തിരഞ്ഞെടുക്കുക. പാത ഒരു ദിശയിൽ ഒരിക്കലും രൂപപ്പെടാത്തപ്പോൾ respond തിരഞ്ഞെടുക്കുക. രണ്ടും ഓണാക്കി പ്രതീക്ഷിക്കുന്നതാണ് അഞ്ച് മിനിറ്റത്തെ അറ്റകുറ്റപ്പണി ഒരാഴ്ചയുടെ ട്യൂണിംഗാക്കി മാറ്റുന്ന വഴി.

കാലതാമസങ്ങൾ എപ്പോൾ എന്ന് തീരുമാനിക്കുന്നു, ഉണ്ടാകുമോ എന്നല്ല

കാലതാമസ മൂല്യങ്ങൾ സമയം നീക്കുന്നു: ഒന്ന് അറിയിപ്പിന് ശേഷം അയക്കുന്ന പാക്കറ്റിന് ബാധകമാണ്, മറ്റൊന്ന് വിപരീത ഹസ്തദാന ശ്രമത്തിന്. രണ്ടും തടഞ്ഞ ദിശ പ്രവർത്തിപ്പിക്കുന്നില്ല. രണ്ടും ഒരുമിച്ച് മാറ്റുന്നത് നിങ്ങൾ ചെയ്യാൻ പോകുന്ന താരതമ്യം നശിപ്പിക്കുന്നു.

സംവിധാനം ശരിയാകുന്നതുവരെ അവ അവിടെ വിടുക. പിന്നീട് ഒന്ന് ക്രമീകരിച്ച് പഴയ മൂല്യം എഴുതി സൂക്ഷിക്കുക.

റിലേ ആണ് സത്യസന്ധമായ ഉത്തരം എന്ന് വരുമ്പോൾ

ചില NAT കോമ്പിനേഷനുകൾക്ക് സമയം എങ്ങനെ ക്രമീകരിച്ചാലും നേരിട്ടുള്ള പാത പിന്തുണയ്ക്കാനാവില്ല. ഇരുവശവും സമമിതി NAT, അല്ലെങ്കിൽ ആവശ്യപ്പെടാത്ത ഇൻബൗണ്ട് ട്രാഫിക് പൂർണ്ണമായി ഉപേക്ഷിക്കുന്ന ഫയർവാൾ, തുളച്ചുകയറാൻ ഒന്നും ബാക്കിയാക്കുന്നില്ല.

എത്തിച്ചേരാവുന്ന വിലാസമുള്ള റിലേ നോഡ് ആ പിയറുകൾക്ക് കടന്നുപോകലിന്റെ വിജയത്തെ ആശ്രയിക്കാത്ത പാത നൽകുന്നു. അത് ആ നോഡിലൂടെ ബാൻഡ്വിഡ്ത്ത് ചെലവാക്കുന്നു, അതിനാൽ ഇത് ഒഴിവാക്കലല്ല, ശേഷിയെക്കുറിച്ചുള്ള തീരുമാനമാണ്. റിലേ ബോധപൂർവ്വം ക്രമീകരിക്കുക എന്നിട്ട് പിയറുകൾക്ക് അതിൽ എത്താമോ എന്ന് പരിശോധിക്കുക, കാരണം സ്വയം ബുദ്ധിമുട്ടുള്ള NAT-ന് പിന്നിലുള്ള റിലേ ഒന്നും മാറ്റുന്നില്ല. തുടർന്ന് ആ ജോടിക്കുള്ള punch ക്രമീകരണങ്ങൾ ട്യൂൺ ചെയ്യുന്നത് നിർത്തുക, കാരണം നേരിട്ടുള്ള പാത ഒരിക്കലും വരാനിരുന്നതല്ല.

പരാജയപ്പെട്ട ജോടി നിഷ്ക്രിയതയ്ക്ക് ശേഷം പരീക്ഷിക്കുക

തകർന്ന അവസ്ഥ പുനഃസൃഷ്ടിക്കുക: ജോടിയെ അതേ ഇടവേളയ്ക്ക് നിഷ്ക്രിയമായി വിടുക, അല്ലെങ്കിൽ മുൻപ് പരാജയപ്പെട്ട ഹസ്തദാന ക്രമം ആവർത്തിക്കുക. തുടർന്ന് വിളക്കുമാടത്തിലേക്കുള്ള അഭ്യർത്ഥനയല്ല, ആ രണ്ട് പിയറുകൾക്കിടയിൽ അപ്ലിക്കേഷൻ പ്രവർത്തിപ്പിക്കുക. വിളക്കുമാടത്തിന്റെ പ്രതികരണം നിയന്ത്രണ പാത തെളിയിക്കുന്നു, ഡാറ്റ പാതയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

ഏത് ക്രമീകരണം മാറി, സമയം, ഒരു നേരിട്ടുള്ള പാത വന്നോ അതോ ട്രാഫിക് റിലേയിൽ തന്നെ തുടർന്നോ എന്ന് രേഖപ്പെടുത്തുക. തുടർന്നെങ്കിൽ ഉത്തരം റിലേയും ശേഷി കുറിപ്പുമാണ്, അത് തികച്ചും നല്ല ഫലമാണ്. വന്നെങ്കിൽ അടുത്ത ചോദ്യം അത് ഒരു മണിക്കൂർ നിഷ്ക്രിയത്വം അതിജീവിക്കുമോ എന്നാണ്, കാരണം ക്ഷയിക്കുന്ന മാപ്പിംഗാണ് punch ഉള്ളതിന്റെ കാരണമായ പ്രശ്നം.