تونل تقسیم‌شده PPTP کار نمی‌کند: اول مسیر GRE را درست کنید

ببینید یک اتصال PPTP بالا می‌آید و به‌راحتی باور می‌کنید که بخش سخت تمام شده است: کلاینت احراز هویت می‌کند، یک آداپتور ppp0 یا WAN Miniport ظاهر می‌شود و پنجره وضعیت سبز می‌شود. سپس اولین درخواست به یک میزبان داخلی به پایان مهلت می‌رسد و پروفایل سرزنش می‌شود. در عمل دو لایه مستقل باید پاک شوند: انتقال بیرونی که TCP 1723 و GRE را حمل می‌کند، و سیاست داخلی که تعیین می‌کند کدام مقاصد از رابط PPP استفاده کنند. وضعیت سبز فقط ثابت می‌کند که لایه اول مذاکره کرده است؛ درباره دومی چیزی نمی‌گوید.

کلاینت را از پروفایل تا سوکت کنترل دنبال کنید

گزارش کلاینت را باز کنید و نقطه‌ای را پیدا کنید که با سرور تماس می‌گیرد. PPTP ابتدا یک اتصال TCP به پورت 1723 باز می‌کند و پارامترهای تونل را روی همان کانال مذاکره می‌کند. اگر این مرحله شکست بخورد، هیچ چیز بعدی مهم نیست، و خطا معمولاً آدرس سرور یا یک پایان مهلت را نام می‌برد.

پیش از دست زدن به هر مسیری، اتصال کنترل را روی شبکه تأیید کنید. روی کلاینت یا یک پورت آینه‌ای، برای یک تلاش اتصال TCP 1723 را ثبت کنید:

sudo tcpdump -ni any 'tcp port 1723' -c 20

دست‌دادن کامل و نشست برقرارشده یعنی کانال کنترل بیرونی کار می‌کند. یک SYN که هرگز SYN-ACK نمی‌گیرد به دیوار آتش، آدرس سرور اشتباه یا ارائه‌دهنده‌ای اشاره دارد که پورت را فیلتر می‌کند. دست‌دادنی که بلافاصله با بازنشانی همراه شود اغلب یعنی سرور اعتبارنامه‌ها یا نوع تونل را رد کرده است.

GRE یک پروتکل دوم است، نه یک پورت

PPTP بار PPP را داخل GRE تقویت‌شده، پروتکل IP شماره 47، حمل می‌کند که شماره پورتی برای پیگیری روتر ندارد. به همین دلیل قاعده‌ای که TCP 1723 را مجاز می‌کند باز هم می‌تواند تونل را بدون مسیر داده رها کند. دستگاه‌های NAT حالت‌دار باید شناسه فراخوان داخل GRE را بفهمند تا پاسخ‌ها را بازنگاشت کنند، و بسیاری این کار را نمی‌کنند. مشخصات PPTP کانال کنترل و بار GRE را قطعات جداگانه نگه می‌دارد، و طرح آزمایش شما هم باید چنین باشد.

پروتکل 47 را در همان ثبت مشاهده کنید، سپس آنچه خارج می‌شود را با آنچه برمی‌گردد مقایسه کنید:

sudo tcpdump -ni any 'proto gre' -c 20

بسته‌هایی که بدون پاسخ خارج می‌شوند، در حالی که TCP 1723 سالم می‌ماند، امضای کلاسیک GRE مسدود است. عبور PPTP روی یک روتر خانگی از ویژگی همان firmware خاص است، بنابراین یک شبکه هتل که کار می‌کند چیزی درباره شبکه بعدی ثابت نمی‌کند. اگر روتر عبور ارائه نمی‌دهد و نمی‌توانید تغییرش دهید، مشکل انتخاب پروتکل است، نه جدول مسیر.

ثابت کنید تونل یک بسته را جابه‌جا می‌کند

وقتی 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 از هر گام وابسته است. گواهی و قرارداد احراز هویت جانشین را بررسی کنید، نه اینکه پروفایل قدیمی را در نسخه جدید کپی کنید.