സൈറ്റ്-ടു-സൈറ്റ് VPN ഒരു ദിശയിൽ മാത്രം പ്രവർത്തിക്കുന്നു: രണ്ട് വ്യത്യസ്ത തകരാറുകൾ

സൈറ്റ് A സൈറ്റ് B യിലേക്ക് എത്തുന്നു, B യ്ക്ക് A യിലേക്ക് എത്താൻ കഴിയുന്നില്ല, ടണൽ രണ്ട് ദിശകളിലും കുഴപ്പമില്ലാതെ കാണുന്നു. ടണലിൽ സ്പർശിക്കുന്നതിന് മുൻപ് നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ ഏത് തകരാറാണെന്ന് തീരുമാനിക്കുക. B യിൽ തുടങ്ങി നിരസിക്കപ്പെടുന്ന പുതിയ കണക്ഷനും A യിൽ തുടങ്ങിയ കണക്ഷനുള്ള ഒരിക്കലും എത്താത്ത മറുപടിയും സമാനമായ പരാതികളും തികച്ചും വ്യത്യസ്തമായ രോഗനിർണയങ്ങളും ഉണ്ടാക്കുന്നു. ഒന്ന് വഴിയിലെ നയ അല്ലെങ്കിൽ റൂട്ട് പ്രശ്നമാണ്; മറ്റൊന്ന് ഇതിനകം അനുവദിച്ച ട്രാഫിക്കിന്റെ തിരികെ വരുന്ന വഴി അല്ലെങ്കിൽ അവസ്ഥയുടെ പ്രശ്നമാണ്.

ഈ വ്യത്യാസമാണ് ഏത് കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കേണ്ടതെന്ന് തീരുമാനിക്കുന്നത്.

ഒരേപോലെ കാണുന്ന രണ്ട് തകരാറുകൾ

ആദ്യ സന്ദർഭത്തിൽ B യുടെ ഹോസ്റ്റ് A യിലേക്ക് ഒരു SYN അയക്കുന്നു, ഒന്നും തിരികെ വരുന്നില്ല. രണ്ടാമത്തേതിൽ A യുടെ ഹോസ്റ്റ് വിജയകരമായി സെഷൻ തുറക്കുന്നു, മറുപടി തിരികെ വരുന്ന വഴിയിൽ അപ്രത്യക്ഷമാകുന്നു. രണ്ട് ഉപയോക്താക്കളും ലിങ്ക് ഒരു ദിശയിലാണെന്ന് പറയുന്നു, ഇരുവരും അപ്രത്യക്ഷമായ ഒരു പാക്കറ്റ് വിവരിക്കുന്നു, അതിനാൽ വിവരണം മാത്രം അവരെ വേർതിരിക്കാൻ കഴിയില്ല.

പരാജയപ്പെട്ട ശ്രമം ഏത് വശമാണ് തുടങ്ങിയതെന്ന് ചോദിക്കുക. ആ ഒരു വസ്തുത സാധ്യമായ കാരണങ്ങളുടെ പകുതി ഒഴിവാക്കുന്നു.

തുടർന്ന് പരിശോധനയിൽ ആദ്യം മുതൽ അവസാനം വരെ അതേ ഹോസ്റ്റുകളും അതേ സേവനവും ഉപയോഗിച്ചിരുന്നോ എന്ന് ഉറപ്പാക്കുക. ഒരു വശത്തുനിന്നുള്ള ping ഉം മറുവശത്തുനിന്നുള്ള ഫയൽ പങ്കിടൽ കണക്ഷനും രണ്ട് വ്യത്യസ്ത കാര്യങ്ങളാണ് പരിശോധിക്കുന്നത്, ഗേറ്റ്‌വേയിൽ നിന്നുള്ള രോഗനിർണയം ഒരു ഉപയോക്തൃ ട്രാഫിക്കും ഉപയോഗിക്കാത്ത ടണൽ വിലാസം തിരഞ്ഞെടുത്തേക്കാം.

ആദ്യ സന്ദർഭം: തിരികെ വരുന്ന വഴി ഇല്ല

മറ്റൊരു സ്ഥിരസ്ഥിതി ഗേറ്റ്‌വേ വഴി മറുപടി നൽകുന്ന വിദൂര സർവറിന് അഭ്യർത്ഥന സ്വീകരിച്ച് മറുപടി മറ്റൊരിടത്തേക്ക് റൂട്ട് ചെയ്യാം. അപ്പോൾ അവസ്ഥ പിന്തുടരുന്ന ഫയർവാളുകൾ അസമമായ മറുപടി ഉപേക്ഷിക്കുന്നു, കാരണം അത് സ്ഥാപിതമായ ഒഴുക്കുമായി പൊരുത്തപ്പെടുന്നില്ല, ഇത് ഒരിക്കലും പ്രവർത്തിക്കാത്ത ഒരു ദിശയെപ്പോലെ കാണപ്പെടുന്നു. വിവർത്തനം മറ്റൊരു രൂപം കൂട്ടിച്ചേർക്കുന്നു: ലക്ഷ്യസ്ഥാനം വിവർത്തനം ചെയ്ത ഉറവിടം കണ്ട് അതിന് മറുപടി നൽകുന്നു, അതിനാൽ യഥാർത്ഥ വിലാസത്തിനായി എഴുതിയ നിയമം ഒരിക്കലും പൊരുത്തപ്പെടുന്നില്ല.

വിവർത്തനത്തിന് ശേഷം ലക്ഷ്യസ്ഥാനം യഥാർത്ഥത്തിൽ കാണുന്ന വിലാസവും, യഥാർത്ഥ സബ്നെറ്റിന് പകരം ആ വിലാസത്തിനുള്ള തിരികെ വരുന്ന റൂട്ടും പരിശോധിക്കുക.

രണ്ടാം സന്ദർഭം: നയം ഒരിക്കലും അത് അനുവദിച്ചിട്ടില്ല

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

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

അതേ ഹോസ്റ്റുകളിൽ മുൻപും ശേഷവും താരതമ്യം ചെയ്യുക

രണ്ട് വെവ്വേറെ ശ്രമങ്ങളല്ല, ഒരേ ശ്രമത്തിന്റെ രണ്ട് അറ്റങ്ങൾ നിരീക്ഷിക്കുക. തുടങ്ങുന്ന ഹോസ്റ്റിന്റെ ഗേറ്റ്‌വേയിലും ലക്ഷ്യസ്ഥാനത്തും ക്യാപ്ചർ ചെയ്ത്, എന്ത് അകത്തേക്ക് വന്നു, എന്ത് പുറത്തേക്ക് പോയി, വിദൂര വശം ഏത് വിലാസം കണ്ടു എന്നിവ താരതമ്യം ചെയ്യുക.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

ലക്ഷ്യസ്ഥാനത്തുള്ള ക്യാപ്ചർ അഭ്യർത്ഥന പ്രതീക്ഷിക്കാത്ത ഉറവിട വിലാസത്തോടെ കാണിക്കുന്നുവെങ്കിൽ, ഉത്തരം ടണലിന്റെ സുരക്ഷാ നയത്തിലല്ല, വിവർത്തനത്തിലോ റൂട്ടിംഗിലോ ആണ്. ലക്ഷ്യസ്ഥാനം അഭ്യർത്ഥന ഒട്ടും കാണിക്കുന്നില്ലെങ്കിൽ, പാക്കറ്റ് സംരക്ഷിത വഴി ഒരിക്കലും കടന്നിട്ടില്ല.

തിരുത്തലിന് ശേഷം അതേ ഹോസ്റ്റിൽ നിന്ന് അതേ പരിശോധന ആവർത്തിച്ച്, ബന്ധമില്ലാത്ത ആക്സസ് ഇപ്പോഴും നിരസിക്കപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക. “established” ടണൽ നില സ്വന്തമായി രണ്ട് നിഗമനങ്ങളിൽ ഒന്നിനെയും പിന്തുണയ്ക്കുന്നില്ല.