گذرواژه‌های بیست‌کاراکتری که هر ماه تغییر می‌کنند و در گاوصندوق نگهداری می‌شوند، سرور PPTP با MS-CHAPv2 را به یک VPN مدرن تبدیل نمی‌کنند. گذرواژه ورودی یک تبادل است که ضعفش در خودِ تبادل نهفته است. این راهنما برای کسی است که آن سرور را به ارث برده و باید کاربران را از آن جدا کند، بی‌آنکه سایتی را که به آن وابسته است قطع کند. مراحل را به ترتیب انجام دهید، چون هر کدام سابقه‌ای بر جای می‌گذارد که وقتی کسی بپرسد چرا دسترسی ناگهان عوض شد به آن نیاز خواهید داشت.

پیش از دست زدن به هر چیز، پشته را بنویسید

سه لایه در واژه PPTP جمع می‌شوند و هر یک به شیوه خود شکست می‌خورد. تونل خود PPTP است، یعنی GRE به‌همراه TCP 1723. احراز هویت هر روش PPP است که سرور عرضه می‌کند، اینجا MS-CHAPv2. حفاظت پیوند MPPE است که کلیدهایش از همان تبادل احراز هویت مشتق می‌شوند. نام بردن هر سه مانع می‌شود که اصلاح بعدی روی لایه اشتباه بنشیند.

پیکربندی زنده را بخوانید نه اینکه به یک صفحه ویکی اعتماد کنید، و فایل، شنونده و آخرین نشست‌هایی را که احراز هویت شده‌اند یادداشت کنید.

grep -RniE 'mschap|mppe|require-mppe' /etc/ppp/options.pptpd /etc/pptpd.conf
ss -lntp 'sport = :1723'
journalctl -u pptpd -n 40 --no-pager

در نقش دسترسی از راه دور ویندوز همان فهرست از دو فرمان به دست می‌آید، و دومی مهم است چون نقش می‌تواند چند روش را همزمان اعلام کند در حالی که کلاینت‌های میدانی همیشه فقط ضعیف‌ترین را مذاکره می‌کنند.

Get-VpnAuthProtocol
netstat -ano | findstr :1723

تصمیم بگیرید تونل امروز واقعاً چه چیزی حمل می‌کند

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

سپس بپرسید مهاجمی که می‌تواند تبادل ورود را ببیند یا بر آن اثر بگذارد چه به دست می‌آورد. با MS-CHAPv2 پاسخ شامل موادی است که بازیابی برون‌خط گذرواژه کاربر را ممکن می‌کند، و دقیقاً به همین دلیل طول و چرخش طراحی را اصلاح نمی‌کنند: راز بازیابی‌شده روی هر سامانه‌ای معتبر است که کاربر آن را دوباره به کار برده باشد.

MPPE همان ضعف را به ارث می‌برد، چون کلیدهایش از آن تبادل می‌آید، و یکپارچگی هر بسته و رفتار بازپخش یک رمزنگاری AEAD مدرن را به شما نمی‌دهد. نشستی که پاک احراز هویت شود فقط سازگاری با بررسی‌های پیکربندی‌شده را اثبات کرده و نه بیشتر.

نه یک استراحت کوتاه ناهار و نه شمار کم کاربران، یک ویژگی رمزنگاری را به ویژگی سیاستی تبدیل نمی‌کند.

مهاجرت را در یک پنجره نگهداری انجام دهید

جانشین را برپا کنید، با یک گروه آزمایشی اثباتش کنید، سپس شنونده قدیمی را متوقف کنید نه اینکه آن را به عنوان عقب‌نشینی خاموش رها کنید. عقب‌نشینی‌ای که هنوز همه می‌توانند به آن برسند مهاجرت نیست، و تبادل ضعیف را دقیقاً برای همان کاربرانی در دسترس نگه می‌دارد که هرگز زحمت تغییر را به خود نمی‌دهند.

sudo systemctl disable --now pptpd
sudo ss -lntp | grep -E ':(1723|1194|51820)\b'
sudo nft list ruleset | grep -i gre

مسیر دیوار آتش را در همان پنجره ببندید. GRE پورتی ندارد که به یاد بماند، پس قاعده‌ای که پروتکل 47 را با شماره مجاز می‌کند آسان از نظر می‌افتد و سرویس را حتی پس از رفتن دیمن در دسترس باقی می‌گذارد. قاعده‌ای را که حذف کردید، جایگاه پیشین و دلیلش را ثبت کنید تا بازبینی تغییرات بعدی آن را تصادفی بازنگرداند.

اعتبارنامه‌ها را جدا از پیکربندی رسیدگی کنید. حذف نمایه کلاینت ابطال نیست، و حسابی که هنوز جای دیگری احراز هویت می‌شود بازنشسته نشده است.

تأیید کنید که جانشین کارهایی را که PPTP انجام می‌داد انجام می‌دهد

فهرست بررسی «آیا وصل می‌شود» نیست. این است که آیا احراز هویت، تخصیص نشانی، حل DNS، انتخاب مسیر، رفتار اتصال دوباره و تأیید همتا همه زیر جانشین برقرار می‌مانند. هر یک را روی دستگاهی آزمایشی، به همان ترتیب بیازمایید و نتیجه مشاهده‌شده را کنار انتظار بنویسید.

ip -4 addr show tun0
ip route get 198.51.100.23
resolvectl query intranet.example.net

نشانی روی واسط ثابت می‌کند مذاکره کامل شده است. ثابت نمی‌کند طرف دور مسیری را که انتظار دارید مجاز کرده باشد، و پرسش بالا فقط برای همین میزبان پاسخ می‌دهد نه برای یک LAN ارسال‌شده. پاسخ یک حل‌کننده دسترسی‌پذیری حل‌کننده را ثابت می‌کند، نه اینکه سیاست DNS تفکیک‌شده نام‌های درست را به آن می‌فرستد.

اتصال دوباره را آخر از همه بررسی کنید، چون بیشتر جانشین‌ها همان‌جا پسرفت می‌کنند: لپ‌تاپ را به خواب ببرید، شبکه‌ها را عوض کنید و تأیید کنید تونل بدون بر جای گذاشتن مسیرهای کهنه دوباره برقرار می‌شود.

بازگردانی، ابطال و سابقه‌ای که بر جای می‌گذارید

بازگردانی سرویس را بازمی‌گرداند؛ امنیت را بازنمی‌گرداند، و این تفاوت باید پیش از باز شدن پنجره بلند گفته شود. اگر مسیر جدید شکست بخورد، کاربران را از طریق یک نقطه پایانی مدرن دوم یا دروازه موقت برگردانید، نه با فعال کردن دوباره PPTP برای همه. نگه داشتن یک مسیر اضطراری روی پروتکل قدیمی، آسیب‌پذیری‌ای را که همین حالا مستند کردید گسترش می‌دهد.

پس از تغییر، حساب‌هایی را که از طریق PPTP احراز هویت کرده‌اند ابطال کنید، بگذارید نمایه‌های ذخیره‌شده‌شان منقضی شوند، و تأیید کنید قاعده GRE از هر دستگاه لبه‌ای رفته است، از جمله نسخه بازیابی از فاجعه که هیچ‌کس به یاد ندارد.

سابقه‌ای کوتاه بر جای بگذارید: پروتکل‌هایی که یافتید، تاریخی که هر شنونده متوقف شد، نسخه‌های کلاینتی که جانشین پشتیبانی می‌کند، و مالکی که می‌تواند تصمیم را دوباره باز کند. بهداشت گذرواژه پس از آن هم مهم است، اما به عنوان بهداشت روی پروتکلی که سزاوار آن است، نه به عنوان دلیلی برای زنده نگه داشتن قدیمی.

مقالات مرتبط