ഏത് VPN ഘട്ടം പരാജയപ്പെട്ടു: IPsec, L2TP നിയന്ത്രണം അല്ലെങ്കിൽ PPP പ്രമാണീകരണം
അവസാനം വിജയിച്ച ഘട്ടം കണ്ടെത്തി ആ പാളി മാത്രം പരിഹരിക്കുക: IPsec, L2TP നിയന്ത്രണ ചാനൽ, PPP പ്രമാണീകരണം അല്ലെങ്കിൽ വിലാസ അനുവദനം.
പാസ്‌വേഡ് മാറ്റിയിട്ടും ഒന്നും നീങ്ങിയില്ല, കാരണം പരാജയം ഒരിക്കലും PPP-യിലായിരുന്നില്ല. L2TP/IPsec അഞ്ച് തികച്ചും വ്യത്യസ്ത കൈമാറ്റങ്ങൾക്ക് ഒരു കണക്ഷൻ പിശക് റിപ്പോർട്ട് ചെയ്യുന്നു, ഓരോ കൈമാറ്റത്തിനും അതിന്റേതായ പരിഹാരമുണ്ട്. തിരിച്ച് പ്രവർത്തിക്കുക: അവസാനം വിജയിച്ച ഘട്ടം കണ്ടെത്തി അതിനു ശേഷം വരുന്നത് മാത്രം മാറ്റുക. താഴെയുള്ള ക്രമം ഏത് തെളിവാണ് ആദ്യം ശേഖരിക്കേണ്ടതെന്നും തീരുമാനിക്കുന്നു.
നാല് ചോദ്യങ്ങൾക്ക് ക്രമത്തിൽ ഉത്തരം നൽകുക
പുതിയ ശ്രമം നിർബന്ധമാക്കുക, കാരണം ചില ക്ലയന്റുകൾ പ്രൊഫൈൽ വിച്ഛേദിച്ച് വീണ്ടും ബന്ധിപ്പിക്കുന്നതുവരെ മുൻ പിശക് കാണിക്കുന്നു. പിന്നെ ഇതിന് ഉത്തരം നൽകുക: IPsec സുരക്ഷാ സംയോഗം ഉണ്ടായിരുന്നോ, L2TP നിയന്ത്രണ ബന്ധവും വിളിയും പ്രത്യക്ഷപ്പെട്ടോ, PPP പ്രമാണീകരണ വിധിയിൽ എത്തിയോ, IPCP ക്ലയന്റിന് വിലാസം നൽകിയോ? ആദ്യത്തെ ഇല്ല ആണ് നിങ്ങൾ പരിഹരിക്കുന്ന ഘട്ടം. അതിനു ശേഷമുള്ളതെല്ലാം പരിശോധിക്കപ്പെട്ടിട്ടില്ല, അതിനാൽ സംയോഗം ഒരിക്കലും ഉണ്ടായിരുന്നില്ലെങ്കിൽ നിരസിക്കപ്പെട്ട ഉപയോക്തൃനാമം ഒന്നും തെളിയിക്കുന്നില്ല.
താരതമ്യം ചെയ്യുന്നതിന് മുമ്പ് ഇരു അറ്റങ്ങളിലെയും ഘടികാരങ്ങൾ സമന്വയിപ്പിക്കുക. IPsec വൃത്തിയാക്കി PPP-യിൽ പരാജയപ്പെട്ട വീണ്ടും ശ്രമം, ക്ലയന്റ് അവസാന സന്ദേശം മാത്രം കാണിക്കുകയും സർവർ ലോഗ് മുൻ ശ്രമം ഇപ്പോഴും സൂക്ഷിക്കുകയും ചെയ്യുമ്പോൾ ഒരൊറ്റ പരാജയമായി തോന്നും. ഏറ്റവും ഉച്ചത്തിലുള്ള വരിയല്ല, സമയമുദ്ര അനുസരിച്ച് വായിക്കുക.
ഉപയോക്താവിന്റെ സ്ക്രീൻഷോട്ട് മാത്രമേ ഉള്ളൂവെങ്കിൽ ഏറ്റവും വിലകുറഞ്ഞ വിഭജനത്തിൽ ആശ്രയിക്കുക: തെറ്റായ മുൻകൂട്ടി പങ്കിട്ട കീയും ഒരിക്കലും ഉത്തരം നൽകാത്ത xl2tpd-യും Windows ഡയലോഗിൽ ഒരേ പാഠം സൃഷ്ടിക്കുന്നു, പക്ഷേ ഒന്നിന് ഇരു അറ്റങ്ങളിലും മാറ്റിയ രഹസ്യം വേണം, മറ്റൊന്നിന് സർവറിൽ തന്നെ ഡീമൺ ആരംഭിക്കുകയോ ഫയർവാൾ നിയമം വേണം. ഇടയിലുള്ള ഉപകരണത്തിന് ട്രാൻസ്‌പോർട്ട് മോഡ് IPsec അത് പൊതിഞ്ഞതിന് ശേഷം ആന്തരിക 1701 ഉപേക്ഷിക്കാനാവില്ല, അതിനാൽ ഇല്ലാത്ത പാത്ത് ഫിൽട്ടർ തിരയരുത്.
ഓരോ പാളിയും യഥാർത്ഥത്തിൽ എന്ത് കൈവശം വയ്ക്കുന്നു
IPsec രണ്ട് പങ്കാളികൾക്കിടയിലെ പാക്കറ്റുകൾ സംരക്ഷിക്കുന്നു; L2TP ആ സംരക്ഷിത പാതയ്ക്കുള്ളിൽ PPP സെഷൻ വഹിക്കുന്നു, അതുകൊണ്ടാണ് RFC 3193 സ്വന്തം ടണലിനു പകരം ട്രാൻസ്‌പോർട്ട് മോഡ് നിർദ്ദേശിക്കുന്നത്. ക്ലയന്റിന്റെ ലേബൽ L2TP എന്ന് പറയുന്നു, അതിനാൽ ടണലും ലോഗിനും ഒരൊറ്റ സംവിധാനമായി തോന്നുന്നു. അങ്ങനെയല്ല: L2TP നിയന്ത്രണ ബന്ധം വിന്യാസം അത് പ്രവർത്തനക്ഷമമാക്കുന്നിടത്ത് ടണലിന്റെ അറ്റങ്ങൾ പ്രമാണീകരിക്കുന്നു, PPP സർവർ നയപ്രകാരം CHAP, PAP അല്ലെങ്കിൽ MS-CHAPv2 ഉപയോഗിച്ച് ഉപയോക്താവിനെ വെവ്വേറെ പ്രമാണീകരിക്കുന്നു.
ഈ വിഭജനം ആളുകൾ തുടർച്ചയായി കൂട്ടിക്കലർത്തുന്ന രണ്ട് രഹസ്യങ്ങൾ വിശദീകരിക്കുന്നു. മുൻകൂട്ടി പങ്കിട്ട കീ IPsec പങ്കാളികളെ പ്രമാണീകരിക്കുന്നു. ഉപയോക്തൃനാമവും പാസ്‌വേഡും PPP-യുടെ മുന്നിൽ ഉപയോക്താവിനെ തിരിച്ചറിയിക്കുന്നു. സർട്ടിഫിക്കറ്റുകൾ ഉപയോഗിച്ച് പ്രമാണീകരിക്കുന്ന പ്രൊഫൈലിൽ Windows-ന്റെ പങ്കിട്ട രഹസ്യം വീണ്ടും ടൈപ്പ് ചെയ്യുന്നത് പരാജയപ്പെടുന്ന ഘട്ടത്തിൽ ഒന്നും മാറ്റുന്നില്ല, PPP പാസ്‌വേഡ് തിരുത്തുന്നത് കാണാത്ത സംരക്ഷിത ചാനൽ നൽകാനാവില്ല. അതേ സംയമനം ഐഡന്റിറ്റി പരിശോധനയ്ക്കും ബാധകമാണ്: ടണൽ ലഭിക്കാൻ പങ്കാളിയുടെ ഐഡന്റിറ്റിയോ സർട്ടിഫിക്കറ്റ് സാധുതയോ ഓഫ് ചെയ്യരുത്, കാരണം അപ്പോൾ ബന്ധിപ്പിക്കുന്നത് പങ്കാളിയല്ല, പാതയാണ്.
പ്രമാണീകരണം PPP-യുടെ അവസാനവുമല്ല. ഉപയോക്താവ് സ്വീകരിക്കപ്പെട്ടതിന് ശേഷം IPCP ക്ലയന്റിന്റെ വിലാസവും സർവർ നൽകാൻ തയ്യാറുള്ള DNS, WINS ഓപ്ഷനുകളും ചർച്ച ചെയ്യുന്നു. ക്ലയന്റിന് CHAP അല്ലെങ്കിൽ MS-CHAPv2 വിജയിച്ചിട്ടും വിലാസമില്ലാതെ തുടരാം, അത് റൂട്ടിംഗ് പ്രശ്നമല്ല, PPP-യ്ക്കുള്ളിലെ പരാജയമാണ്. IPsec ഇല്ലാത്ത സാധാരണ L2TP സാധുവും അസംരക്ഷിതവുമായി തുടരുന്നു, അതിനാൽ വിജയകരമായ കണക്ഷൻ ട്രാഫിക് സംരക്ഷിതമാണെന്ന് ഒരിക്കലും തെളിയിക്കുന്നില്ല; സർവർ എന്ത് ആവശ്യപ്പെടുന്നു എന്ന് പരിശോധിക്കുക, ക്ലയന്റിന്റെ ലേബലല്ല.
ആദ്യം കാണാത്ത ഘട്ടത്തിൽ നിന്ന് തീരുമാനിക്കുക
പട്ടിക ആദ്യം കാണാത്ത ഇനം അനുസരിച്ച് ഇടത്തുനിന്ന് വലത്തോട്ട് വായിക്കുക. വലത് നിരയാണ് ആ നിമിഷത്തിൽ മൂല്യമുള്ള ഒരേയൊരു ജോലി; അതിന്റെ ഇടതുവശത്തുള്ളതെല്ലാം ഇതിനകം തെളിയിക്കപ്പെട്ടതാണ്, അത് വീണ്ടും പരിശോധിക്കുന്നത് വിവരം ചേർക്കാതെ തടസ്സ വിൻഡോ കത്തിക്കുന്നു.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
മൂന്ന് വരികൾ മുന്നറിയിപ്പ് അർഹിക്കുന്നു. 1701 വരി NAT-ന് പിന്നിലുള്ള Windows ക്ലയന്റുകൾ സാധാരണ ഇറങ്ങുന്ന സ്ഥലമാണ്: സംയോഗം പൂർത്തിയാകുന്നു, പിന്നെ ഒന്നും എത്തുന്നില്ല, കാരണം മോശം പാസ്‌വേഡല്ല, എൻകാപ്സുലേഷനാണ്. IPCP വരി റൂട്ട് പ്രശ്നമായി തെറ്റായി വായിക്കപ്പെടുന്നതാണ്, കാരണം Windows കാണാത്ത വിലാസം പിശക് 720-ൽ പൊതിയുന്നു, ട്രേ ഐക്കൺ കണക്ഷൻ പരാജയപ്പെട്ടു എന്ന് മാത്രം പറയുന്നു; ആ പരാജയം പ്രമാണീകരണത്തിന് ശേഷവും റൂട്ടിംഗിന് മുമ്പും നിൽക്കുന്നു. അവസാന വരി IPsec പരാജയമേയല്ല, ട്രേ ഐക്കൺ വിച്ഛേദിച്ചു എന്ന് പറഞ്ഞാലും.
പാളികളെ വേർതിരിക്കുന്ന കമാൻഡുകൾ
strongSwan പ്രവർത്തിക്കുന്ന Linux സർവറിൽ swanctl --list-sas സ്ഥാപിത സംയോഗങ്ങൾ പങ്കാളിയുടെ ഐഡന്റിറ്റിയോടെ പട്ടികപ്പെടുത്തുന്നു, ipsec statusall പഴയ strongSwan, libreswan ഹോസ്റ്റുകൾ ഉൾക്കൊള്ളുന്നു. അതിനടിയിൽ ip xfrm state കർണലിന്റെ യഥാർത്ഥ സംയോഗങ്ങൾ കാണിക്കുന്നു, ss -lunp | grep 1701 xl2tpd എവിടെ ബന്ധിച്ചിരിക്കുന്നു എന്ന് തെളിയിക്കുന്നു. നിയന്ത്രണ ബന്ധങ്ങളും വിളികളും പ്രത്യക്ഷപ്പെടുന്നത് കാണാൻ xl2tpd -D മുൻപിലായി ഓടിക്കുക, നിർദ്ദേശിച്ച രീതിയും ഉത്തരവും കാണാൻ /etc/ppp/options.xl2tpd-ൽ pppd ഡീബഗ് ഓണാക്കുക.
ലോഗുകൾ വിജയകരമായ പ്രമാണീകരണം കാണിക്കുമ്പോൾ അടുത്ത ചോദ്യം IPCP പൂർത്തിയായോ എന്നതാണ്. /etc/xl2tpd/xl2tpd.conf-ന്റെ [lns default] വിഭാഗത്തിലെ ip range-ന് ഇപ്പോഴും സ്വതന്ത്ര വിലാസങ്ങളുണ്ടോ, ക്ലയന്റ് പ്രതീക്ഷിക്കുന്നെങ്കിൽ /etc/ppp/options.xl2tpd യഥാർത്ഥത്തിൽ ms-dns, ms-wins വഹിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക. ക്ഷയിച്ച പൂളും കാണാത്ത DNS ഓപ്ഷനും വയറിൽ വ്യത്യസ്തമായി കാണാം: ആദ്യത്തേത് ക്ലയന്റിനെ വിലാസമില്ലാതെയും 720-നൊപ്പവും വിടുന്നു, രണ്ടാമത്തേത് വിലാസം നൽകുന്നു പക്ഷേ റിസോൾവർ നൽകുന്നില്ല, അതിനാൽ പേരുകൾ പരാജയപ്പെടുമ്പോൾ അസംസ്കൃത വിലാസങ്ങളിലേക്കുള്ള ping പ്രവർത്തിക്കുന്നു. രണ്ടും പാസ്‌വേഡ് വീണ്ടും നൽകി ശരിയാക്കാനാവില്ല.
ക്ലയന്റിൽ NetworkManager-ന്റെ L2TP പ്ലഗിൻ pppd സംഭാഷണം ജേണലിൽ എഴുതുന്നു, അതിനാൽ journalctl -u NetworkManager -b സാധാരണയായി ടണൽ ഉയർന്നു, പ്രമാണീകരണം നിരസിച്ചു എന്ന അവസ്ഥയെ ടണൽ ഒട്ടുമില്ല എന്നതിൽ നിന്ന് വേർതിരിക്കുന്നു. Windows-ൽ Get-VpnConnection പ്രൊഫൈലിന്റെ യഥാർത്ഥ പ്രമാണീകരണ ക്രമീകരണങ്ങൾ റിപ്പോർട്ട് ചെയ്യുന്നു, Event Viewer-ൽ Application-ന് കീഴിലുള്ള RasClient ഇവന്റുകൾ പരാജയപ്പെട്ട ഘടകത്തെ പേരിടുന്നു. ഡയലോഗ് വളരെ അവ്യക്തമാണെങ്കിൽ netsh ras set tracing * enable പ്രവർത്തനക്ഷമമാക്കുക.
ക്യാപ്ചറുകൾക്ക് ഒരു മുൻകരുതൽ വേണം. ട്രാൻസ്‌പോർട്ട് മോഡ് IPsec-ൽ ആന്തരിക UDP 1701 എൻക്രിപ്റ്റ് ചെയ്തിരിക്കുന്നു, അതിനാൽ പുറം ഇന്റർഫേസിലെ ക്യാപ്ചർ ESP കാണിക്കുന്നു, അല്ലെങ്കിൽ NAT-T-യിൽ UDP 4500, L2TP ഒട്ടുമില്ല. ക്യാപ്ചറിൽ 1701 ഇല്ലാതിരിക്കുന്നത് പ്രതീക്ഷിതമാണ്, തടഞ്ഞ പോർട്ടിന്റെ തെളിവല്ല; ESP അല്ലെങ്കിൽ 4500 കൗണ്ടറുകൾ നീങ്ങുന്നുണ്ടോ എന്ന് നോക്കുക.
NAT, MTU, റൂട്ടുകൾ: സ്റ്റാക്ക് നിങ്ങളെ തെറ്റിദ്ധരിപ്പിക്കുന്നിടം
എന്തെങ്കിലും പ്രമാണീകരിക്കപ്പെടുന്നതിന് മുമ്പേ NAT ഊഹങ്ങൾ തകർക്കുന്നു. ESP സ്വന്തം IP പ്രോട്ടോക്കോളാണ്, അതിനാൽ പരിഭാഷപ്പെടുത്തുന്ന ഉപകരണം പങ്കാളികൾ എൻകാപ്സുലേറ്റ് ചെയ്യുന്നില്ലെങ്കിൽ അത് വലിച്ചെറിയുന്നു; UDP 4500 അതാണ് നൽകുന്നത്. സ്വയം ഭവന റൂട്ടറിന് പിന്നിലോ ക്ലൗഡ് NAT ഗേറ്റ്‌വേയ്ക്ക് പിന്നിലോ നിൽക്കുന്ന Windows സർവറിൽ IPsec ഘട്ടം പിശക് 789-ൽ പരാജയപ്പെടുന്നു, PolicyAgent കീയ്ക്ക് കീഴിൽ AssumeUDPEncapsulationContextOnSendRule 2 ആക്കി യന്ത്രം പുനരാരംഭിക്കുന്നതുവരെ, പരാജയം അടച്ച പോർട്ടിൽ നിന്ന് വേർതിരിച്ചറിയാനാവില്ല. NAT-ന് പിന്നിലുള്ള ക്ലയന്റുകൾ എളുപ്പമാണ്: സർവറിൽ പൊതു വിലാസമുണ്ടെങ്കിൽ UDP 4500-ലെ NAT-T അവയെ വഹിക്കുന്നു, ആ മൂല്യം ഉൾപ്പെടുന്നില്ല.
PPP ഉയർന്നതിന് ശേഷം കറുത്ത ദ്വാരമുള്ള MTU മരിച്ച ടണലിനെ അനുകരിക്കുന്നു: ചെറിയ പാക്കറ്റുകൾ കടക്കുന്നു, TLS ഹസ്തദാനമോ പേജ് ലോഡോ തൂങ്ങിക്കിടക്കുന്നു, ക്ലയന്റ് ഇപ്പോഴും ബന്ധിപ്പിച്ചതായി കാണിക്കാം. സർവറിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ഇന്റർഫേസ് MTU കുറയ്ക്കുക അല്ലെങ്കിൽ ഗേറ്റ്‌വേയിൽ MSS മുറുക്കുക. വിഭജിത ടണൽ റൂട്ടിംഗ് മറ്റൊരു വ്യാജനാണ്; തെറ്റായ മാസ്കോടെ അയച്ച സബ്നെറ്റ് ടണൽ ആരോഗ്യകരമായി വിട്ട് ഒരു ആപ്ലിക്കേഷനെ എത്താനാവാത്തതാക്കുന്നു. സ്വകാര്യ ഹോസ്റ്റ്നാമം സ്വന്തം ചുവട് ചേർക്കുന്നു: അന്വേഷണം പ്രാദേശിക റിസോൾവർ വഴി പുറത്തുപോകുന്നെങ്കിൽ, ഏതെങ്കിലും റൂട്ട് പരിശോധിക്കുന്നതിന് മുമ്പ് പേര് പരിഹരിക്കാനാവില്ല.
ക്രെഡൻഷ്യലുകൾ തൊടുന്നതിന് മുമ്പുള്ള ചെക്ക്‌ലിസ്റ്റ്
പട്ടിക ക്രമത്തിൽ ചെയ്ത് ആദ്യം പരാജയപ്പെടുന്ന ഇനത്തിൽ നിർത്തുക. ഓരോ ചുവടും വിലകുറഞ്ഞതാണ്, ഓരോന്നും ഒരു മുഴുവൻ തിരുത്തൽ വിഭാഗത്തെ ഒഴിവാക്കുന്നു.
- സംയോഗം ഇരു അറ്റങ്ങളിലുമുണ്ടെന്ന് ഉറപ്പാക്കുക, ബന്ധിപ്പിച്ച ലേബലല്ല, പങ്കാളിയുടെ ഐഡന്റിറ്റി അനുസരിച്ച് ചേർത്തത്.
- UDP 1701 xl2tpd-യിൽ എത്തുന്നുവെന്ന് ഉറപ്പാക്കുക; വിളിയില്ലാത്ത സംയോഗമാണ് നിങ്ങളുടെ പരാജയം.
- പാസ്‌വേഡ് തെറ്റാണെന്ന് കരുതുന്നതിന് മുമ്പ് PPP-യുടെ വിധിയും, പ്രമാണീകരിച്ചെങ്കിൽ IPCP-യുടെ ഫലവും വായിക്കുക.
- ഇപ്പോൾ മാത്രം സർവർ പ്രതീക്ഷിക്കുന്ന ഫോർമാറ്റിൽ ക്രെഡൻഷ്യലുകൾ വീണ്ടും നൽകുക, കാരണം ഡൊമെയിൻ പ്രിഫിക്സ് അക്കൗണ്ട് മാറ്റുന്നു.
- ഇപ്പോഴും പരാജയപ്പെട്ടാൽ രണ്ട് അറ്റങ്ങളും വിന്യസിച്ച സമയമുദ്രകളോടെ ക്യാപ്ചർ ചെയ്ത് ഘട്ടം തോറും താരതമ്യം ചെയ്യുക.
രണ്ടാം ചുവട്ടിൽ നിർത്തുന്നത് പാത അല്ലെങ്കിൽ എൻകാപ്സുലേഷൻ പ്രശ്നമാണ്, പാസ്‌വേഡിന്റെ ഏത് തിരുത്തും അതിനെ നീക്കില്ല. മൂന്നാം ചുവട്ടിൽ നിർത്തുന്നത് ലോഗ് ഇതിനകം പരിഹരിക്കേണ്ട രീതിയോ വിലാസ പൂളോ പേരിട്ടു എന്നാണർത്ഥം. ഏതായാലും അടുത്ത മാറ്റം നിങ്ങൾ ന്യായീകരിക്കാനാവുന്നതാണ്, ഒരിക്കലും ഉൾപ്പെടാത്ത ക്രമീകരണങ്ങളിൽ കറങ്ങുന്നത് നിർത്തുന്നു.