د PPTP ویشل شوی ټنل کار نه کوي: لومړی د GRE لاره سمه کړئ
د PPTP ویشل شوی ټنل د دوو بېلو لاملونو له امله ناکامېږي: GRE بند دی یا داخلي لاره نهشته. لومړی ترانسپورت وازموئ، بیا پالیسي.
وګورئ چې د PPTP نښلونکی پورته کېږي او باور کول اسانه دي چې سخت برخه پای ته رسېدلې، کلاینټ ځان تصدیق کوي، د ppp0 اډاپټر یا WAN Miniport څرګندېږي، او د حالت کړکۍ شنه شي۔ بیا داخلي هوسټ ته لومړنۍ غوښتنه د وخت پای ته رسېږي، او پروفایل تورن کېږي۔ په عمل کې دوه خپلواکې پوړې باید پاکې شي: بهرنی ترانسپورت چې TCP 1723 او GRE وړي، او داخلي پالیسي چې پرېکړه کوي کوم ځایونه د PPP انټرفیس کاروي۔ شنه حالت یوازې دا ثابتوي چې لومړی پوړ موافقه کړې؛ د دویم په اړه هېڅ نه وایي۔
کلاینټ له پروفایل څخه تر کنټرول ساکټ پورې تعقیب کړئ
د کلاینټ لاګ پرانیزئ او هغه نقطه ومومئ چې هلته له سرور سره اړیکه نیسي۔ PPTP لومړی د 1723 پورټ ته TCP نښلونکی پرانیزي او په همدې چینل کې د ټنل پیرامیټرونو باندې خبرې کوي۔ که دا ګام ناکام شي، وروسته هېڅ شی مهم نه دی، او تېروتنه معمولاً د سرور پته یا د وخت پای ښیي۔
له هرې لارې څخه مخکې په تار باندې د کنټرول نښلونکی تایید کړئ۔ په کلاینټ یا په هنداره پورټ کې، د یوې نښلونکې هڅې لپاره TCP 1723 ونیسئ:
sudo tcpdump -ni any 'tcp port 1723' -c 20
بشپړ شوی لاس ورکول او ټینګه شوې ناسته معنا دا ده چې بهرنی کنټرول چینل کار کوي۔ هغه SYN چې هېڅکله SYN-ACK نه ترلاسه کوي د اور وژونکي، غلطې سرور پتې یا د پورټ فلټر کوونکي عرضه کوونکي په لور اشاره کوي۔ له لاس ورکولو وروسته سمدلاسه بیا تنظیمېدل ډېری وخت معنا دا ده چې سرور د ننوتلو معلومات یا د ټنل ډول رد کړی۔
GRE دویم پروتوکول دی، پورټ نه
PPTP د PPP بار د پراخ شوي GRE، IP پروتوکول 47 دننه وړي، چې د پورټ شمېره نلري چې روټر یې تعقیب کړای شي۔ له همدې امله هغه قاعده چې TCP 1723 ته اجازه ورکوي بیا هم ټنل پرته له معلوماتي لارې پرېږدي۔ د حالت لرونکي NAT وسایل باید د GRE دننه د زنګ ID وپېژني ترڅو ځوابونه بیرته نقشه کړي، او ډېری یې نه کوي۔ د PPTP مشخصات کنټرول چینل او GRE بار د جلا برخو په توګه ساتي، او ستاسو د ازموینې پلان هم باید همداسې وي۔
په هماغه نیول کې پروتوکول 47 وګورئ، بیا هغه څه چې وتلي د هغو سره پرتله کړئ چې بیرته راځي:
sudo tcpdump -ni any 'proto gre' -c 20
هغه پیکټونه چې پرته له ځوابونو وتلي، په داسې حال کې چې TCP 1723 روغ پاتې دی، د بند GRE کلاسیک نښه ده۔ په کورني روټر باندې د PPTP تېرېدل د هماغه ځانګړي فرم ویئر ځانګړنه ده، نو یو کار کوونکی هوټل شبکه د بل په اړه هېڅ نه ثابتوي۔ که روټر تېرېدل وړاندې نه کړي او تاسو یې نه شئ بدلولی، ستونزه د لارو جدول نه، د پروتوکول غوره کول دي۔
ثابت کړئ چې ټنل یو پیکټ ځای په ځای کوي
کله چې GRE بهېږي، د PPP خبرې اترې کلاینټ انټرفیس ته پته ورکوي۔ د فرض کولو پرځای تخصیص ولولئ:
ip -4 addr show ppp0
هغه پیر پتې ته پنګ وکړئ چې د نقطه تر نقطې تړون د منزل په توګه ښودل شوې۔ په دې پړاو کې ځواب ثابتوي چې پوښل شوې لار له سره تر پایه کار کوي او سرور د ټنل دننه ځواب وایي۔ که پیر ځواب ووایي خو داخلي هوسټونه نه، بهرنی ترانسپورت سم دی او نیمګړتیا دننه تللې ده۔
دا د هرې ویشل شوې لارې له اضافه کولو مخکې وکړئ۔ د ترانسپورت د خرابېدو پر مهال د لارې بدلون دویم متغیر جوړوي او لومړی پټوي۔
ویشلې پالیسي ولیکئ، DNS په ګډون
ویشل شوی روټینګ د پرېکړو لیست دی، نه د چیک بکس۔ هر خصوصي مخکښ چې باید ټنل تېر کړي، د PPP انټرفیس له لارې لاره ته اړتیا لري، او هر مخکښ چې باید ځایي پاتې شي باید په هغه کې نه وي۔ د یوې اپلیکیشن فرعي شبکې لپاره پرته د هغې خصوصي حل کوونکي ته د سمونې لارې لاره جوړول د خراب اپ په څېر ښکارېدونکې خنډ جوړولو عادي لاره ده۔
په هرې کټګورۍ کې د یوې پتې لپاره د کرنل پرېکړه وګورئ:
ip route get 10.20.5.10
ip route get 203.0.113.25
لومړی باید ppp0 او دویم باید عادي ګېټ ووایي۔ که دواړه یو شان انټرفیس ووایي، پالیسي هېڅ ویشل شوې نه ده۔ د DNS سرور خپله پته د ټنل لیست ته اضافه کړئ، که نه د داخلي هوسټونو لپاره د نومونو حل د ځایي حل کوونکي له لارې وځي او هېڅ ګټور بیرته نه راوړي۔
په پنځو ګامونو کې تکرارېدونکې څېړنه
پوړونه په ترتیب چل کړئ او په لومړني ناکام پوړ بند شئ: کنټرول چینل، د GRE لید، د PPP پیر ځواب، د یوې داخلي پتې لپاره ویشل شوې لاره، او د ټنل له لارې اپلیکیشن غوښتنه۔ هر ګام خپل امر لري، نو نیمګړتیا د راز په توګه نه، بلکې د نسبت وړ ده۔
د Linux کلاینټ لپاره لنډه نسخه داسې ښکاري:
sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10
په Windows کې هماغه ترتیب د route print او په کلاینټ کې ښودل شوي اډاپټر حالت سره پلي کېږي۔ PPTP زوړ پروتوکول دی، او که سرور SSTP یا IKEv2 وړاندې کړي، نو تلل معمولاً د وخت غوره کارونه ده تر د هغې لارې تنظیمولو چې په هر ګام کې د پروتوکول 47 تېرېدو پورې تړلې ده۔ د بدیل سند او د تصدیق تړون وګورئ، نه دا چې زوړ پروفایل په نوي خپرونه کې کاپي کړئ۔