سرور PPTP پشت روتر خانگی: اول 1723 و GRE را درست کنید

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

دو حامل، و تنها یکی از آنها درگاه دارد

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

دیوار آتش خود سرور هم باید پروتکل 47 را از نشانی روتر اجازه دهد. دیوار آتش میزبان که فقط 1723/tcp را می پذیرد، خطای 619 را از داخل LAN بازتولید می کند، که هدایت خراب و قاعده خراب میزبان را یکسان نشان می دهد.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

اگر ماژول ها نیستند، آنها را با sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre بارگذاری کنید و بارگذاری را ماندگار کنید، چون راه اندازی دوباره ای که کمک کننده را فراموش کند تونل کارا را دوباره به خطای 619 برمی گرداند. قاعده هدایت باید پروتکل 47 را فقط به سمت نشانی سرور بپذیرد، نه کل LAN. تعریف RFC 2637 مسیر کنترل و داده را جدا می کند، به همین دلیل هیچ صفحه هدایت درگاه واحدی PPTP را کامل توصیف نمی کند.

جعبه عبور یا قاعده صریح پروتکل

جعبه عبوری که فقط دیوار آتش را باز می کند به درست نزدیک تر از ALG است که شناسه های تماس را بازنویسی می کند. نیمه دیوار آتش قابل پیش بینی است، چون پروتکل 47 یا پذیرفته می شود یا دور ریخته می شود و شمارنده ها می گویند کدام. نیمه بازنویسی جایی است که فروشندگان تفاوت دارند، چون شناسه های تماس PPTP برای هر تونل جداگانه است و NAT که آنها را ویرایش می کند باید هر تماسی را که لمس می کند دنبال کند. وقتی یک کلاینت وصل می شود و دو تا نه، ALG نخستین مظنون است.

قاعده NAT مقصد برای 1723 هم مشکل مالکیت دارد. اگر قاعده ای قدیمی هنوز 1723 را به میزبانی می فرستد که سرور را متوقف کرده است، بسته ها روی درگاه بسته فرود می آیند و سرویس PPTP خود روتر از پاسخ دادن باز می ایستد، که مثل خرابی دیوار آتش خوانده می شود اما در واقع هدفی کهنه است. قاعده و مقصدش را پیش از افزودن دومی بخوانید. روی روترهایی که خودشان PPTP را پایان می دهند، قاعده WAN با سرویس داخلی رقابت می کند، پس برای 1723 و پروتکل 47 یک مالک انتخاب کنید.

دو کلاینت پشت یک NAT همان حالتی است که هدایت ساده را از هدایت هوشمند جدا می کند. هدایت پروتکل 47 بدون بازنویسی شناسه های تماس معمولا بهتر از کمک کننده ای عمل می کند که می خواهد آنها را درست کند.

پیش از متهم کردن روتر، تونل را اندازه بگیرید

PPTP بار مفید را کوچک می کند و این کوچک شدن حساب است نه راز. هر بسته تونل یک سرآیند IP بیرونی، یک سرآیند GRE تقویت شده، یک سرآیند PPP و با رمزنگاری یک سرآیند MPPE حمل می کند. وقتی مسیر نمی تواند قاب حاصل را حمل کند، بسته های کوچک عبور می کنند، ورود کامل می شود و نشست نخستین بار که انتقال فایل یا دست دادن TLS بسته ای با اندازه کامل می فرستد متوقف می شود.

عدد را حساب کنید نه حدس بزنید. GRE تقویت شده 8 بایت است، PPP 4 بایت، MPPE 4 بایت و سرآیند IP بیرونی 20 بایت، پس تونل پیش از هر باری 36 بایت می خورد. روی WAN از نوع PPPoE که روی 1492 تمام می شود، بزرگ ترین MTU برای PPP که جا می شود 1492 منهای 36 است، یعنی 1456. mtu و mru را در گزینه های PPP روی همان مقدار بگذارید و با پینگ بدون قطعه بندی دوباره آزمایش کنید.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

پینگ مسیر را اندازه می گیرد نه تونل را: 1464 بایت بار به علاوه 28 بایت سرآیند IP و ICMP دقیقا یک قاب 1492 بایتی را پر می کند. اگر آن پینگ شکست بخورد، عدد را پایین بیاورید تا عبور کند و 36 را از نتیجه کم کنید. MTU تونل که بالاتر از حد مسیر تنظیم شده باشد، انجماد را بدون هیچ خط گزارش که اندازه را ذکر کند تولید می کند.

PPTP، L2TP/IPsec یا OpenVPN روی همان روتر

همان روتر می تواند هر یک از سه تونل رایج را حمل کند و تفاوت در این است که چه چیزی باید بیان کند. PPTP دو قاعده در دو لایه متفاوت می خواهد. L2TP روی IPsec برای تبادل کلید به UDP 500 و 4500 نیاز دارد و اگر NAT-T آن را حمل نکند، برای بار به پروتکل 50. OpenVPN یک درگاه UDP می خواهد و هیچ کمک کننده ای.

ستون L2TP به طور خودکار از GRE مهربان تر نیست. ESP پروتکل IP 50 است و آن هم درگاه ندارد، پس روتری که با پروتکل 47 مشکل دارد می تواند به همان دلیل با پروتکل 50 مشکل داشته باشد. NAT-T برای پیچیدن ESP در UDP 4500 وجود دارد و وقتی دو طرف آن را پشتیبانی کنند، قاعده پروتکل 50 بی نیاز می شود. این ویژگی دو سر است نه جعبه PPTP روتر. پیش از نوشتن قاعده برای هر دو، تایید کنید کلاینت واقعا کدام کپسوله سازی را مذاکره کرده است.

OpenVPN گزینه ای با کمترین قطعات متحرک در سمت روتر است. یک درگاه UDP، یک هدایت، هیچ کمک کننده ردیابی اتصال و هیچ بازنویسی شناسه تماس. معامله اش کلاینتی است که باید نصب شود به جای شماره گیر داخلی، و اغلب همین تنها دلیل ماندن PPTP در گفتگو است.

چه چیزی را تعمیر و چه چیزی را جایگزین کنیم

درست کردن هدایت و MTU به شما تونلی می دهد که کار می کند، نه تونلی که باید نگه دارید. احراز هویت MSCHAPv2 در PPTP سال ها آسیب پذیر بوده و تونل کارا اعتبارنامه هایی را جابه جا می کند که می توان بیرون از شبکه بازیابی کرد. اگر دستگاه دور می تواند L2TP/IPsec یا OpenVPN اجرا کند، تعمیر را اقدامی موقت با تاریخ بدانید.

تصمیم به این بستگی دارد که سر دور چه چیزی را پشتیبانی می کند و این ترتیب چقدر باید دوام بیاورد. دستگاه قدیمی که فقط PPTP می فهمد تعمیر می شود؛ هر چیزی که بتواند کلاینت نصب کند منتقل می شود.

پیش از بستن تیکت، تایید کنید که کلاینت از یک انتقال بزرگ جان سالم به در می برد نه فقط از ورود، و روتر پس از راه اندازی دوباره هم قاعده پروتکل 47 خود را نگه می دارد. تونلی که یک کپی فایل را رد می کند و پس از به روزرسانی بعدی firmware می میرد، هرگز تمام نشده بود.