کلاینت‌های PPTP در DD-WRT به هم نمی‌رسند: پنج بررسی

دو لپ‌تاپ به سرور PPTP روی یک جعبه DD-WRT شماره می‌گیرند، هرکدام یک نشانی می‌گیرند، و هیچ‌کدام نمی‌تواند دیگری را پینگ کند. پوشه‌های اشتراکی هرگز ظاهر نمی‌شوند و نخستین فکر این است که ماسک 255.255.255.255 که روتر می‌دهد باید غلط باشد. این سبب نیست، و تغییرش حتی یک همسایه تازه نمی‌سازد. پنج بررسی زیر را به ترتیب انجام دهید و به‌محض شکست یکی متوقف شوید، چون هرکدام درمان دیگری دارد.

بررسی یک: /32 اشکال نیست

PPTP پروتکل PPP را حمل می‌کند، و پیوند PPP دقیقاً دو نقطه پایانی را به هم می‌پیوندد: کلاینت شما و سرور. ماسک شبکه توصیف می‌کند کدام نشانی‌ها یک قطعه محلی را شریک‌اند، و اینجا هیچ قطعه‌ای نیست، فقط همتا در انتهای دیگر یک سیم. ماسکی از همه یک‌ها دقیقاً همین را می‌گوید، پس DD-WRT مقدار درست برای این نوع پیوند را می‌دهد. نشانی، نشانی همتاست، نه نشانی واسط روی یک LAN.

ماسک 255.255.255.0 جای خود را روی رسانه اشتراکی با صدها دستگاه دارد، و گذاشتنش روی واسط PPP هم طرف دیگر تونل را همسایه نمی‌کند.

بررسی دو: مقادیر صفحه سرور PPTP را بخوانید

همه تنظیمات مهم در بخش سرویس‌ها، VPN، سرور PPTP است. سرور را فعال کنید، نشانی سرور را روی نشانی LAN روتر بگذارید، و محدوده کلاینت را بیرون از استخر DHCP نگه دارید تا کلاینت شماره‌گیر و ماشین کابلی نشانی یکسان نگیرند. زیر CHAP-Secrets برای هر حساب یک خط به شکل username * password * اضافه کنید، بدون فاصله درون نام. اعمال کنید، سپس با پروفایلی که روتر و یکی از آن حساب‌ها را نام می‌برد وصل شوید.

اینکه کلاینت کجا متوقف می‌شود می‌گوید کدام لایه را بررسی کنید. کلاینتی که احراز هویت می‌شود ولی نشانی نمی‌گیرد مشکل استخر یا رمزها دارد؛ کلاینتی که نشانی می‌گیرد و به جایی نمی‌رسد مشکل مسیریابی یا دیوار آتش دارد.

بررسی سه: به‌دنبال مسیری میان دو همتا بگردید

هر تونلی که روی روتر تمام می‌شود واسط خودش را دارد، معمولاً ppp0، ppp1 و به همین ترتیب. ترافیک از یک کلاینت به دیگری باید میان این واسط‌ها مسیریابی شود، و روتر باید حاضر باشد آن را جلو بفرستد. روی روتر ip route را اجرا کنید و برای هر همتای متصل یک مسیر میزبان بجویید که به واسط PPP متناظر اشاره کند. اگر همتایی مسیر نداشته باشد، تونل کاملاً بالا نیست، هرچه صفحه وضعیت کلاینت ادعا کند.

دو مسیر میزبان به دو واسط ppp جداگانه همان شکلی است که پیش از ادامه می‌خواهید.

بررسی چهار: زنجیره FORWARD را ببینید، نه INPUT

ترافیک کلاینت به کلاینت جلو فرستاده می‌شود، نه اینکه محلی پذیرفته شود، پس زنجیره INPUT جای اشتباهی است. iptables -L FORWARD -v -n را اجرا کنید و به‌دنبال قاعده drop بگردید که واسط‌های PPP را می‌گیرد، به‌همراه شمارنده‌های بسته که نشان می‌دهد اصلاً چیزی به زنجیره می‌رسد یا نه. سیاست drop پیش‌فرض بدون قاعده پذیرش برای ترافیک تونل دقیقاً همان نشانه‌ای را می‌سازد که با آن شروع کردید: هر کلاینت تنها خوب است، با هم برای یکدیگر نامرئی‌اند.

اگر پینگ‌های کوچک کار کنند و انتقال‌های بزرگ بایستند، تونل مسدود نمی‌شود بلکه قطعه‌قطعه می‌شود. PPTP روی PPP معمولاً MTU و MRU حدود 1450 می‌خواهد، و رها کردنشان روی 1500 پیوندی می‌دهد که دست‌دادن‌ها را رد می‌کند و در بار واقعی شکست می‌خورد.

بررسی پنج: تصمیم بگیرید دسترسی اینترنت چه باید بکند

کلاینت‌هایی که باید از دفتر مرور کنند به ترجمه نشانی مبدأ به سمت واسط WAN نیاز دارند. کلاینت‌هایی که فقط باید به LAN برسند به یک مسیر و هیچ چیز دیگر نیاز ندارند. اینها نیت‌های متفاوت با مجموعه قواعد متفاوت‌اند، و پرسش ماسک این تصمیم دوم را کاملاً پنهان می‌کند. پیش از افزودن حتی یک قاعده بنویسید چه رفتاری می‌خواستید، چون کلاینتی که به‌طور غیرمنتظره از خط دفتر بیرون می‌رود غافلگیری‌ای است که در جلسه سر باز می‌کند نه در گزارش.

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