L2TP نښلوي خو د PPP خبرې اترې ناکامېږي: کومه پړاوه؟

د IPsec تونل جوړېږي، کڅوړه خوندي همکار ښیي، او بیا اړیکه مري مخکې لدې چې څه خصوصي فرعي شبکې ته ورسېږي۔ دا تشه PPP دی چې خپله کار کوي: د لینک انتخابونه، د کاروونکي تصدیق او د پت وېش ټول هغه وخت پېښېږي چې کوډشوی تونل شتون لري۔ د لومړي پړاو په بریالۍ تبادله کې هیڅ شی پټنوم یا داخلي پت نه ورکوي۔ پړاوونه په ترتیب سره ولولئ، ناکامي معمولاً خپل نوم اخلي۔

تونل یوازې لومړی پوړ دی

L2TP د IPsec په ساتل شوي تونل کې PPP چوکاټونه لېږدوي، یعنې د بنډل د لارې کولو دمخه باید دوه خپلواکې خبرې اترې بریالۍ شي۔ بهرنۍ ثابتوي چې دواړه سرونه پر کیلي ګانو او هویتونو سره یو دي۔ داخلي د لینک پیرامیټرونه، چې کاروونکی تصدیقیږي که نه، او کڅوړه کوم پت اخلي، هغه ټاکي۔

د PPP دننه ناکامي د هر هغه کڅوړې په نظر مات تونل ښکاري چې یوازې یو حالت څراغ ښیي۔ که ورته د تونل ستونزه وګڼل شي، نو د کیلي ګانو بیا جوړول، د خدمتونو بیا پیلول او په پای کې د هغه شریک راز بدلول چې هیڅکله غلط نه و۔ ګټور توپیر ارزان دی: که له همکار سره تبادله بشپړه شوه او کڅوړه د کاروونکي نوم غوښتنې یا تصدیق پړاو ته واوښته، تونل سم دی۔ له هغې نقطې وروسته هر څه PPP پورې اړه لري۔

هغه وروستې پړاوه ولولئ چې بریالۍ شوه

لاګ په مخ وګرځوئ او په لومړنۍ پړاوه کې ودرېږئ چې بشپړه نه شوه۔ لومړی LCP راځي، بیا تصدیق، بیا د IPv4 پیرامیټرونو لپاره IPCP۔

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

د LCP وخت تېرېدل یعنې دواړه سرونه هیڅکله د لینک بنسټیزو انتخابونو باندې سره یو نه شول، چې دا بد پټنوم نه، بلکې د پروفایل ناسمونو یا د داخلي پروتوکول بندښت دی۔ ښکاره تصدیق ردول مخالف حالت دی: لینک پورته شو او یوه خوا د ننوتلو معلومات رد کړل۔ د بریالي تصدیق وروسته د IPCP وخت تېرېدل د پت حوضونو یا د سرور پالیسۍ ته اشاره کوي۔ هر یو له دوی بېل مالک او بېل سمون لري، له همدې کبله پړاوه د وروستي تېروتنې متن څخه مهمه ده۔

په ټیکټ کې د پړاوې نوم سره یوځای د لاګ برخه وساتئ۔ د پړاوې له حد پرته نښلول شوې لکۍ بل لوستونکی اټکل ته رابولي، او دلته اټکل کول یو ساعت لګښت لري۔

د کڅوړې او سرور ترمنځ موافقه

دواړه سرونه باید یو شان تصدیق طریقه ومني، او خوندي شوی پروفایل کېدای شي هغه وغواړي چې سرور تېره ربع له کاره ایستلې وه۔ مديري ځای پرځای کول سرور خوا هم پټوي، چېرې چې د رد سبب معمولاً د وسیلې پر ځای پر کاروونکي لیکل کېږي۔

د هر پخواني انتخاب پر ځای یوه ملاتړ شوې طریقه فعاله کړئ، ځکه چې پنځه طریقې وړاندې کونکې کڅوړه پټوي چې کومه ناکامه شوه۔ له مدیر څخه د سرور خوا پالیسي او دقیق رد وغواړئ، چې د دې لپاره اړینه نه ده چې څوک پټنوم خپور کړي۔ یوه پخوانۍ طریقه چې د یوې کڅوړې د ژغورلو لپاره فعاله شي، د فایل کاپي کونکي هر پروفایل ته خپرېدل غواړي۔

پت وګورئ، نه ننوتل

بشپړ شوی ننوتل کارېدونکې ناسته نه ده۔ IPCP د داخلي پت په اړه خبرې کوي، او خالي شوی حوض یا هغه پالیسي چې کڅوړه ردوي کېدای شي لا هم نښلېدلی تونل پرته له دې چې څه لاره ورکړل شي پرېږدي۔

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

لومړی داخلي پت وګورئ، بیا هغه سرچینې لپاره لار او حل کوونکی چې واقعاً ورته اړتیا لرئ۔ داخلي پت هغه عامه وتل نه دی چې یو ویب پاڼه یې راپور ورکوي، او د دواړو ګډول خلک د هغې بهېدنې په لټه کې استوي چې نشته۔ شخصي سرچینه لومړی په پت او بیا په نوم وآزموئ، ترڅو د DNS ناکامي د لارې کولو ناکامي ونه ګڼل شي۔

پړاوه، طریقه او پت په یوه یادداشت کې ولیکئ او نېټه پرې کېږدئ۔ که هماغه حساب یوه میاشت وروسته بیا ناکام شي، هغه یادداشت د پنځو دقیقو کتنې او نوي پلټنې ترمنځ توپیر دی۔ په بېلو پړاوونو کې ناکامۍ بېلې پېښې دي، حتی کله چې کڅوړه یوه خبرې اترې ښیي۔