کدام نشانی باید در DNS برای سروری که از طریق VPN متصل است قرار گیرد؟
یک سرور میزبانی‌شده سه نشانی دارد و این نشانی‌ها قابل تبادل نیستند. مقداری را که هر سرویس به آن نیاز دارد انتخاب کنید و سپس آن را از بیرون ماشین تأیید کنید.
یک سرور میزبانی‌شده که VPN روی آن نصب شده در نهایت سه نشانی را نگه می‌دارد، و تنها یکی از آن‌ها به هر جایی تعلق دارد که در شرف پیکربندی آن هستید. کپی کردن شماره از پنل ارائه‌دهنده به DNS، به یک شنونده یا به فهرست مجاز همان مسیری است که یک تونل کارآمد به سرویسی تبدیل می‌شود که هیچ‌کس نمی‌تواند به آن برسد. این راهنما کار را طوری مرتب می‌کند که هر نشانی برای هدفی اعلام‌شده انتخاب شود. همچنین دستورهایی را فهرست می‌کند که تأیید می‌کنند واقعاً چه چیزی منتشر کرده‌اید.
پیش از انتشار هر چیز، سه نشانی را نقشه‌برداری کنید
آن‌ها را بر اساس کارکرد نام‌گذاری کنید. نشانی underlay چیزی است که ماشین برای رسیدن به نقطه پایانی VPN از طریق اینترنت استفاده می‌کند، و اغلب پشت NAT ارائه‌دهنده خصوصی است. نشانی تونل درون VPN زندگی می‌کند و بسته به محصول توسط سرور یا کلاینت داده می‌شود. خروجی عمومی نشانی‌ای است که یک وب‌سایت راه دور پس از ترجمه ثبت می‌کند، و لازم نیست روی هیچ رابطی که می‌توانید پرس‌وجو کنید وجود داشته باشد.
پنلی که یک نشانی عمومی برای یک ماشین نشان می‌دهد، درباره دو نقش دیگر بسیار کم به شما می‌گوید. دسترس‌پذیری underlay یک الزام است، نه یک خرید: یک لپ‌تاپ پشت روتر خانگی می‌تواند بدون داشتن نشانی عمومی IPv4 به نقطه پایانی VPN میزبانی‌شده برسد. کاری که نمی‌توانید بکنید این است که با نوشتن نامی که به نشانی‌ای که هیچ‌کس آن را هدایت نمی‌کند تفکیک می‌شود، مسیر ورودی اختراع کنید.
نشانی را بر اساس سرویس انتخاب کنید، نه بر اساس برچسب
بنویسید سرور پیش از انتخاب شماره چه کاری باید انجام دهد. فراخوانی‌های خروجی API هنگامی که طرف مقابل فهرست مجاز نگه می‌دارد به خروجی پایدار نیاز دارند. دسترسی خصوصی به نشانی تونلی نیاز دارد که کلاینت‌ها بتوانند به آن مسیریابی کنند و به شنونده‌ای متصل به آن. میزبانی عمومی به نگاشت ورودی نیاز دارد که ارائه‌دهنده واقعاً ارائه می‌کند، و نشانی خروجی به‌تنهایی آن را فراهم نمی‌کند.
یک ماشین می‌تواند به هر سه هدف خدمت کند و در همان حال سه نشانی متفاوت به کار ببرد. آنچه می‌شکند این فرض است که یک مقدار همه آن‌ها را پوشش می‌دهد:
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
سطر ورودی همان سطری است که مردم درباره‌اش بحث می‌کنند. رکوردی که به نشانی خروجی اشاره می‌کند هیچ شنونده، هیچ بازشدن دیوار آتش و هیچ نگاشت پورتی ایجاد نمی‌کند، و انتظار کشیدن این را تغییر نمی‌دهد. وقتی ارائه‌دهنده نشانی اختصاصی را همراه با یک قاعده ورودی می‌فروشد، آن بسته همان توانمندی است که خریده‌اید؛ خود نشانی به‌تنهایی حق نیست.
دستورهایی که نشان می‌دهند کدام نشانی کدام است
ماشین را بخوانید، نه پنل را. نام رابط‌ها بین سیستم‌ها متفاوت است، پس نشانی‌ها را به دستگاه‌ها نسبت دهید به‌جای اعتماد به یک برچسب.
خط اول هر نشانی IPv4 و دستگاه آن را فهرست می‌کند، و دومی از هسته می‌پرسد برای یک مقصد شناخته‌شده بیرونی از کدام دستگاه استفاده می‌کند:
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'اگر جست‌وجوی مسیر برای ترافیک عمومی با یک دستگاه تونل پاسخ دهد، تونل کامل شما برقرار است. بررسی شنونده به همان اندازه مهم است، زیرا فرایندی که فقط به 127.0.0.1 متصل است هرگز روی نشانی تونل پاسخ نمی‌دهد، هر نامی که منتشر کنید.
آن را منتشر کنید و سپس از بیرون بررسی کنید
فقط مقداری را منتشر کنید که سرویس به آن نیاز دارد: رکورد A یا AAAA برای میزبانی، ورودی فهرست مجاز برای فراخوانی‌های خروجی، نمایه کلاینت برای دسترسی خصوصی. سپس از موقعیتی که اهمیت دارد آزمایش کنید، و آن هرگز ماشینی نیست که همین حالا ویرایش کردید.
دو بررسی بیشتر موارد را پوشش می‌دهد، و هر دو به‌قدری ارزان هستند که در یک اسکریپت بمانند:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthپاسخ DNS که ثابت می‌کند رکورد شما وجود دارد، اثباتی بر رسیدن یک درخواست نیست، و یک درخواست موفق تنها ثابت می‌کند که یک مسیر از یک شبکه کار می‌کند. وقتی فهرست مجاز در میان است، بررسی را از یک اتصال موبایل تکرار کنید، زیرا خروجی‌ای که مشاهده می‌کنید می‌تواند به خانواده نشانی و مسیر طی‌شده بستگی داشته باشد. یادداشت کنید کدام خانواده را تأیید کردید؛ یک مسیر IPv4 کارآمد هیچ چیزی درباره IPv6 نمی‌گوید.
اگر سرویس ورودی است، نشانی خروجی کافی نیست
دسترسی ورودی به چهار چیز هم‌راستا نیاز دارد: نامی یا نشانی‌ای که کلاینت می‌تواند به آن برسد، مسیری که بسته را به ماشین می‌رساند، شنونده‌ای که آن را می‌پذیرد، و سیاستی که آن را دور نمی‌اندازد. VPN مورد دوم و گاهی اولی را تغییر می‌دهد و برای سومی و چهارمی هیچ کاری نمی‌کند. وقتی تونل مسیر تحویل است، کلاینت‌ها به نشانی تونل متصل می‌شوند، نه به خروجی.
یادداشت کنید هر سرویس به کدام نشانی وابسته است، و هر زمان ارائه‌دهنده مدل مسیریابی خود را تغییر داد آن یادداشت را دوباره مرور کنید. سروری که به‌صورت خصوصی پاسخ می‌دهد و به‌صورت عمومی شکست می‌خورد معمولاً خراب نیست؛ با هویت اشتباه پاسخ می‌دهد، و اصلاح آن تصمیمی درباره نگاشت است نه تغییری در دیوار آتش.