ඔබ මුරපදය වෙනස් කළත් කිසිවක් නොසෙල්වුණි, මන්ද දෝෂය කිසිදා PPP තුළ නොතිබුණි. L2TP/IPsec ඉතා වෙනස් භාරදීම් පහක් සඳහා එක් සම්බන්ධතා දෝෂයක් වාර්තා කරන අතර, සෑම භාරදීමකටම තමන්ගේම අලුත්වැඩියාවක් ඇත. පසුපසට වැඩ කරන්න: අවසාන සාර්ථක අවස්ථාව සොයා ඊට පසුව එන දේ පමණක් වෙනස් කරන්න. පහත අනුපිළිවෙල මුලින්ම කුමන සාක්ෂි රැස් කරන්නේ ද යන්නද තීරණය කරයි.

ප්‍රශ්න හතරකට පිළිවෙලින් පිළිතුරු දෙන්න

නව උත්සාහයක් බලකරන්න, මන්ද සමහර සේවාලාභීහු පැතිකඩ විසන්ධා කර නැවත සම්බන්ධ නොකරන තෙක් පෙර දෝෂය පෙන්වති. පසුව මෙයට පිළිතුරු දෙන්න: IPsec ආරක්ෂක සංගතියක් තිබුණි ද, L2TP පාලන සම්බන්ධතාවක් හා ඇමතුමක් පෙනුණි ද, PPP සත්‍යාපන තීන්දුවකට පැමිණියේ ද, IPCP සේවාලාභියාට ලිපිනයක් දුන්නේ ද? පළමු නැත යනු ඔබ නිවැරදි කරන අවස්ථාවයි. ඊට පසු සියල්ල පරීක්ෂා නොකළ බැවින්, සංගතිය කිසිදා නොතිබුණා නම් ප්‍රතික්ෂේප වූ පරිශීලක නාමය කිසිවක් ඔප්පු නොකරයි.

සංසන්දනයට පෙර දෙකෙළවරේ ඔරලෝසු සමමුහුර්ත කරන්න. IPsec පිරිසිදු කර PPP හි අසාර්ථක වූ නැවත උත්සාහය, සේවාලාභියා අවසන් පණිවිඩය පමණක් පෙන්වන විට සහ සේවාදායක ලොගය තවමත් පෙර උත්සාහය තබා ගන්නා විට එක් අසාර්ථකත්වයක් ලෙස පෙනේ. හොඳම හඬ ඇති පේළියෙන් නොව, කාල මුද්‍රාවෙන් කියවන්න.

ඔබට ඇත්තේ පරිශීලකයාගේ තිර රුව පමණක් නම්, ලාභම වෙන් කිරීම මත රඳා සිටින්න: වැරදි පෙර බෙදාගත් යතුරක් සහ කිසිදා පිළිතුරු නොදෙන xl2tpd එකක් Windows සංවාදයේ එකම පෙළ නිපදවයි, නමුත් එකකට දෙකෙළවරේම වෙනස් කළ රහසක් අවශ්‍ය වන අතර අනෙකට සේවාදායකයේම ආරම්භ කළ ඩීමන් එකක් හෝ ගිනිපවුරු නියමයක් අවශ්‍ය වේ. මධ්‍යයේ ඇති උපාංගයට තුළ 1701 ඉවත නොහැක, එය ප්‍රවාහණ මාදිලියේ IPsec විසින් ඔතා දැමූ පසු, එබැවින් නොමැති මාර්ග පෙරහනක් සොයන්නට යන්න එපා.

සෑම ස්ථරයක්ම සැබවින්ම ලබා ගෙන ඇත්තේ කුමක්ද

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 missingWhat it meansChange this
No IKE reply on 500 or 4500The path or the listener never answeredFirewall, NAT-T forwarding, server listener
IKE runs, no IPsec associationIdentity, key, or proposal mismatchProposal and PFS set, pre-shared key, local and remote ID
Association up, no L2TP control connectionInner signalling never reached xl2tpdUDP 1701, tunnel and session sections, NAT encapsulation
Control connection up, PPP auth refusedThe user or method was rejectedCredential format, allowed auth method, account policy
PPP auth accepted, no address assignedIPCP never completedAddress pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd
Address assigned, applications failThe inner path is wrongRoutes, 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 තද කරන්න. බෙදුණු උමග මාර්ගගත කිරීම අනෙක් රැවටිල්ලයි; වැරදි ආවරණයක් සමඟ තල්ලු කළ උපජාලයක් උමග නිරෝගීව තබා එක් යෙදුමක් ළඟා නොවන ලෙස තබයි. පෞද්ගලික සත්කාරක නාමයක් තමන්ගේම පියවරක් එකතු කරයි: විමසුම දේශීය විසඳන්නා හරහා පිටව යන්නේ නම්, කිසිදු මාර්ගයක් පරීක්ෂා කිරීමට පෙර නම විසඳා ගැනීම අසාර්ථක වේ.

අක්තපත්‍ර ස්පර්ශ කිරීමට පෙර පිරික්සුම් ලැයිස්තුව

ලැයිස්තුව පිළිවෙලින් කර පළමු අසාර්ථක අයිතමයේ නතර වන්න. සෑම පියවරක්ම ලාභදායකය, සහ සෑම එකක්ම සංස්කරණ පන්තියක් මුළුමනින්ම ඉවත් කරයි.

  1. සංගතිය දෙකෙළවරේම ඇති බව තහවුරු කරන්න, සම්බන්ධ ලේබලයෙන් නොව සහකරුගේ අනන්‍යතාවෙන් ගැළපී.
  2. UDP 1701 xl2tpd වෙත ළඟා වන බව තහවුරු කරන්න; ඇමතුමක් නැති සංගතිය ඔබේ අසාර්ථකත්වයයි.
  3. මුරපදය වැරදි යැයි උපකල්පනය කිරීමට පෙර PPP හි තීන්දුව, සත්‍යාපනය වූයේ නම් IPCP හි ප්‍රතිඵලය කියවන්න.
  4. දැන් පමණක් අක්තපත්‍ර සේවාදායකයා බලාපොරොත්තු වන ආකෘතියෙන් නැවත ඇතුළත් කරන්න, මන්ද වසම් උපසර්ගය ගිණුම වෙනස් කරයි.
  5. තවමත් අසාර්ථක නම් දෙකෙළවර පෙළගැස්වූ කාල මුද්‍රා සමඟ ග්‍රහණය කර අවස්ථාවෙන් අවස්ථාව සසඳන්න.

දෙවන පියවරේ නතර වීම යනු මාර්ග හෝ කැප්සියුලන ගැටලුවකි, මුරපද සංස්කරණයකින් එය නොසෙල්වේ. තෙවන පියවරේ නතර වීම යනු ලොගය දැනටමත් නිවැරදි කළ යුතු ක්‍රමය හෝ ලිපින තටාකය නම් කර ඇති බවයි. ඕනෑම අවස්ථාවක ඊළඟ වෙනස ඔබට සාධාරණීකරණය කළ හැකි එකක් වන අතර, කිසිදා සම්බන්ධ නොවූ සැකසුම් අතර කැරකෙන එක නවත්වයි.

අදාළ ලිපි