آیا یک کلاینت VPN متحرک می‌تواند میزبان سرویسی برای دفتر باشد؟

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

جهت شماره‌گیری درباره جهت سرویس چیزی نمی‌گوید

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

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

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

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

مسیر سه بخش دارد: مسیری روی دروازه که به نشانی درونی کلاینت اشاره می‌کند، سیاستی که تماس‌گیرنده مشخص را مجاز می‌کند، و سرویسی شنونده روی هدف. هر بخش به شکلی متفاوت شکست می‌خورد، از این رو «VPN روشن است» تقریباً هیچ چیز نمی‌گوید.

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

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

نام‌ها و نشانی‌ها تصمیم‌های طراحی هستند

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

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

نام را با هر کسی که مالک هویت VPN است هماهنگ کنید، تا رکورد، تخصیص نشانی و سیاست دسترسی با هم تغییر کنند نه در سه بلیت جداگانه.

سرویس را بیازمایید، نه عضویت را

از هدف تأیید کنید چه چیزی و روی کدام نشانی گوش می‌دهد، سپس دید دروازه از مسیر بازگشت را تأیید کنید:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

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

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

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