پیشوند عمومی برای کلاینتهای VPN: واقعاً چه چیزی را خراب میکند
پیشوند عمومی قرضگرفتهشده بهخودیخود کلاینتها را افشا نمیکند. مقصدهایی را که مال دیگری است میگیرد و وقتی تونل قطع میشود معنا را عوض میکند.
مجموعهای از کلاینتها که چون اعداد مرتب به نظر میرسند انتخاب شده، مسیری است که در انتظار نصب است. پیشوند برای کارکردن VPN لازم نیست خصوصی باشد، و استفاده از بلوکی که مال شخص دیگری است هم بهطور خودکار کاربران شما را در اینترنت افشا نمیکند. کاری که میکند این است که تا وقتی تونل بالاست این نشانیها معنای دیگری داشته باشند و بعد وقتی قطع شد دوباره معنای دیگری. پنج بررسی زیر را به ترتیب انجام دهید و همانجا که پاسخ «در جای دیگر تخصیص یافته» است توقف کنید.
تخصیص اعلام نیست
گذاشتن یک نشانی روی واسط تونل آن را در اینترنت اعلام نمیکند. دسترسپذیری عمومی به مسیر، مسیر مجاز و ارائهدهندهای نیاز دارد که حاضر به حمل آن باشد، و هیچیک از اینها بهخاطر دریافت نشانی از یک مجموعه توسط کلاینت پدید نمیآید. سیاست دیوار آتش و مجوز میزبان هم دوباره تصمیمهای جداگانهاند.
به همین دلیل ریسک آن چیزی نیست که بیشتر مردم فرض میکنند. پیشوند قرضی کلاینتهای شما را در دسترس نمیکند؛ مقصدهای شخص دیگری را از کلاینتهای شما غیرقابل دسترس میکند، که خرابی متفاوتی با مالک متفاوت است. به کسی حمله نمیشود و هیچ اعلامی بیرون نمیرود. کاربر بهسادگی نمیتواند سایتی را که دیروز کار میکرد باز کند و میز پشتیبانی هیچ دلیلی برای مشکوک شدن به مجموعه VPN ندارد.
این تفاوت هنگام انتخاب مجموعه اهمیت دارد. اگر تنها نگرانی شما مواجهه با اینترنت بود، بلوک عمومی ایمن به نظر میرسید چون چیزی آن را اعلام نمیکند. نگرانی مسیر محلیای است که کلاینت برای آن پیشوند نصب میکند، و این مسیر نصب میشود چه کس دیگری آن را ببیند چه نه.
مسیر کلاینت واقعاً چه چیزی را میگیرد
وقتی تونل بالا میآید، کلاینت مسیری برای پیشوند مجموعه دریافت میکند و آن مسیر بر مسیر پیشفرض برای هر مقصدی درونش پیروز میشود. درخواست به یک میزبان مشروع در آن بلوک اکنون بهجای اینترنت به VPN میرود. اینکه شکست بخورد، معلق بماند یا به سرور اشتباه برسد بستگی دارد به اینکه سمت شما با آن چه میکند.
ip route get 198.51.100.20 ip -br addr show tun0 traceroute -n 198.51.100.20
جستوجو را با تونل بالا و دوباره با آن پایین اجرا کنید. نشانی در حالت اول یک معنا دارد و در حالت دوم معنایی کاملاً متفاوت، و هر برنامهای که در این گذار یک اتصال یا یک حل نام را در حافظه پنهان نگه داشته باشد ناسازگار رفتار میکند. این ناسازگاری از یک شکست تمیز سختتر پشتیبانی میشود، چون به زمانبندی بستگی دارد. کاربری که در لحظه اشتباه دوباره وصل میشود تجربهای متفاوت از کسی دارد که این کار را نمیکند.
به همین دلیل هم یک نشانی IP آشنا اثبات هویت نیست. اعتبارسنجی گواهی و نام سرور را برای مقصد واقعی نگه دارید، چون نشانی عددیای که پنج دقیقه پیش به آن رسیدید ممکن است اکنون به گفتوگوی دیگری تعلق داشته باشد.
مجموعه را با هر شبکهای که میشناسید مقایسه کنید
RFC 1918 سه بلوک را برای استفاده خصوصی کنار میگذارد: 192.168.0.0/16، 172.16.0.0/12 و 10.0.0.0/8. میلیونها سازمان جداگانه از آنها دوباره استفاده میکنند، پس خصوصی بیانیهای درباره تخصیص است و هرگز وعدهای نیست که هیچکس دیگری همان اعداد را انتخاب نکرده است.
مجموعه نامزد را با LANهای اداری، VPCهای ابری، مجموعههای VPN دیگر، پیوندهای شرکا و بازههایی که کارکنان دورکار بهاحتمال زیاد در خانه دارند مقایسه کنید. مورد خانه دلیلی برای اختراع یک پیشوند عجیب نیست؛ دلیلی است برای کوچک و مستند نگه داشتن مجموعه.
تخصیص را با کسی که مالک مسیریابی است هماهنگ کنید و مسیر بازگشت را در همان جا ثبت کنید. مجموعهای که هیچکس نمیتواند به آن بازمسیریابی کند مجموعهای است که در هنگام یک قطعی دوباره کشف خواهد شد. مجموعه را در همان سندی بگذارید که بازههای سایت را دارد، نه در پیکربندی کلاینتی که فقط یک نفر ویرایشش کرده است. سند همان چیزی است که برخورد بعدی را قابل اجتناب میکند.
چه زمانی آدرسدهی عمومی پاسخ درست است
سازمانهایی با فضای جهانی درست تخصیصیافته میتوانند کاملاً یک مجموعه VPN با نشانیهای عمومی بسازند، و بعضیها این کار را عمداً برای پرهیز از ترجمه انجام میدهند. آن طراحی همچنان به مسیریابی، اعتبارسنجی منبع، قواعد دسترسی و احراز هویت کلاینت نیاز دارد؛ تخصیص هیچیک از اینها را فراهم نمیکند.
آنچه فراهم میکند یکتایی است، همان ویژگیای که پیشوند قرضی فاقد آن است. اگر مالک بلوک باشید، مسیری که کلاینت شما نصب میکند به نشانیهایی اشاره میکند که واقعاً مال شما هستند، و معنا وقتی تونل قطع میشود عوض نمیشود.
برای جبران انتخاب مجموعه بهطور خودکار NAT اضافه نکنید. طراحی خصوصی مسیریابیشده با مسیرهای بازگشت صریح از ترجمهای که چون آدرسدهی هرگز برنامهریزی نشده بود اعمال میشود پاکیزهتر است، و IPv6 به برنامه عمدی خودش نیاز دارد نه کپی از فرضهای IPv4.
مجموعه بد را بدون از دست دادن دسترسی بازنشسته کنید
اگر مجموعه قبلاً مستقر شده است، پیش از تغییر آن فهرستبرداری کنید: رزروهای نشانی، مسیرهای نصبشده، رکوردهای DNS که به بلوک حل میشوند، دامنههای دیوار آتش و برنامههایی که به آنها وابستهاند. سپس تغییر را با همان دقتی برنامهریزی کنید که برای هر تغییر مسیریابی دیگری. آن را به کسانی که متوجه میشوند اعلام کنید، چون با جابهجایی مجموعه نشستهایشان قطع میشود. تغییر خاموش در آدرسدهی کلاینتها تیکتهای پشتیبانیای تولید میکند که بیربط به کار به نظر میرسند.
مسیر بازیابیای را حفظ کنید که به مجموعهای که حذف میکنید وابسته نباشد، چون لحظهای که آن را پس میگیرید همان لحظهای است که دسترسی از راه دور شما ممکن است با آن ناپدید شود. سپس هر دو جهت را اعتبارسنجی کنید: مقصدهای خصوصی موردنظر همچنان کار میکنند و مقصدهای اینترنتی که قبلاً گرفته میشدند اکنون به مالکان واقعی خود حل میشوند.
آنچه میخواهید مجموعهای است که تیم شبکه بتواند آن را بهعنوان یک چیز منسجم تخصیص دهد، مسیریابی کند و بازنشسته کند. قالب نشانی بهتنهایی نه امنیت را برقرار میکند نه اتصال را.