VPN و شبکه خانگی در یک زیرشبکه: اول مسیر را دنبال کنید
هر دو آداپتر مدعی 192.168.1.0/24 هستند و یک مسیر برنده می‌شود. پیش از شماره‌گذاری مجدد یا متهم کردن DNS، فهرست آداپترها، مسیر برنده و مسیر بازگشت را دنبال کنید.
به VPN محل کار وصل می‌شوید، آیکون سینی سبز می‌شود، اینترانت بارگذاری می‌شود و چاپگری که دو متر آن‌طرف‌تر است از پاسخ دادن باز می‌ایستد. اشتراکی که امروز صبح کار می‌کرد روی همان رایانه مهلتش تمام می‌شود و هیچ گزارش‌گیری از چاپگر نامی نمی‌برد. اولین واکنش DNS است، چون نامی که حل نمی‌شود شبیه نامی است که وجود ندارد، اما مشکل نشانی است: دو آداپتر اکنون مدعی 192.168.1.0/24 هستند و تنها یک مسیر می‌تواند این پیشوند را ببرد. این را به همین ترتیب دنبال کنید تا پیش از تغییر هر چیزی ببینید کدام آداپتر آن را گرفته است.
از نشانه شروع کنید، نه از تونل
نشانه، دامنه است. اگر اینترانت کار می‌کند و همه دستگاه‌های محلی از کار می‌افتند، تونل سالم است و مسیر محلی نه. اگر دستگاه‌های محلی کار می‌کنند و اینترانت از کار می‌افتد، برعکس. اگر همه‌چیز جز یک میزبان کار می‌کند، با یک نشانی روبه‌رو هستید که در هر دو طرف وجود دارد.
پیش از دست زدن به تنظیمات، یک نشانی محلی و یک نشانی دور را بنویسید. «چاپگر» آزمون‌پذیر نیست؛ 192.168.1.40 هست. همان یک قدم از رایج‌ترین ساعت هدررفته در این مشکل جلوگیری می‌کند، یعنی بازنویسی تنظیمات DNS برای یک تصمیم مسیریابی.
گام 1: هر دو آداپتر را ببینید که پیشوند را ادعا می‌کنند
«اتصالات شبکه» (ncpa.cpl) را باز کنید و دو آداپتر را کنار هم بخوانید. آداپتر Ethernet نشانی 192.168.1.50/24 را با دروازه 192.168.1.1 نشان می‌دهد. آداپتر VPN نشانی 192.168.1.201/24 را نشان می‌دهد که سرور فرستاده است. هر دو مشروع‌اند، هر دو باور دارند پیشوند on-link است، و پشته برای آن یک مسیر نگه می‌دارد.
Get-NetIPAddress -AddressFamily IPv4 نشانی‌ها را فهرست می‌کند و Get-NetIPInterface | Sort-Object InterfaceMetric ترتیبی را نشان می‌دهد که پشته آن‌ها را به کار می‌برد. همان ستون متریک تصمیمی است که در شرف خواندنش هستید، پس اعداد را یادداشت کنید نه اینکه به حافظه بسپارید.
نظریه DNS را ارزان رد کنید: Resolve-DnsName printer.office.lan همان نشانی دیروز را برمی‌گرداند. نام حل شد؛ سپس بسته از آداپتر اشتباه بیرون رفت. دو دقیقه اینجا یک بعدازظهر در تنظیمات حل‌کننده صرفه‌جویی می‌کند.
گام 2: مسیری را بخوانید که واقعاً برنده شد
Find-NetRoute -RemoteIPAddress 192.168.1.40 رابط، پرش بعدی و مبدأیی را چاپ می‌کند که پشته برای آن نشانی به کار می‌برد. آن خروجی را پاسخ بدانید، نه اشاره. route print -4 کل جدول را می‌دهد وقتی می‌خواهید ببینید کدام ورودی باخت و چقدر.
ویژگی بر نیت چیره می‌شود. یک 192.168.0.0/25 فرستاده‌شده بر 192.168.0.0/24 محلی چیره می‌شود چون پیشوند بلندتر است، پس 192.168.0.0 تا 192.168.0.127 از تونل بیرون می‌روند و نیمه بالا محلی می‌ماند. ناپدید شدن نیمی از شبکه محلی بدون پیام خطا رفتار درست همان جدول است.
tracert -d 192.168.1.40 آن را از بیرون جدول تأیید می‌کند: اگر پرش اول نشانی تونل باشد نه روتر خودتان، مسیر تمام ماجراست. در Linux همان پرسش ip route get 192.168.1.40 است که نشانی مبدأ و دستگاه را در یک خط چاپ می‌کند. وقتی پاسخ tun0 را نام می‌برد، نگاه کردن به مرورگر را رها کنید.
گام 3: پیش از متهم کردن کلاینت مسیر بازگشت را بررسی کنید
مسیر رفتِ درست هم اگر طرف دور نتواند پاسخ دهد شکست می‌خورد. وقتی به شبکه محلی یک کلاینت از طریق تونل می‌رسیم، دروازه آن شبکه باید بداند استخر تونل کجاست: ip route add 10.8.0.0/24 via 192.168.1.12 روی همان روتر، و push «route 192.168.1.0 255.255.255.0» از سرور تا کلاینت‌ها مسیر بازگشت را بدانند.
بدون ورودی اول، پاسخ هدف را به سوی دروازه پیش‌فرضش ترک می‌کند که یک نشانی خصوصی را به ارائه‌دهنده می‌فرستد و دور می‌ریزد. نشانه یک‌طرفه است و به‌راحتی بد فهمیده می‌شود: درخواست‌ها روی tun0 دیده می‌شوند، پاسخ‌ها هرگز.
قاعده masquerade روی میزبان VPN نیاز به آن مسیر ایستا را برمی‌دارد: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. همچنین نشانی‌های مبدأ واقعی را پنهان می‌کند و این هر پرسش بعدی درباره گزارش‌ها را سخت‌تر می‌کند. میزبان هدف با دروازه پیش‌فرض اشتباه همان سکوت را تولید می‌کند، با تغییرمسیر ICMP در بهترین حالت و چاله سیاه در حالت عادی، و به همین دلیل ضبط به هر دو سر تعلق دارد.
گام 4: تعمیری را انتخاب کنید که بتوانید با آن زندگی کنید
برای این کار پنج تعمیر به کار می‌رود و جای یکدیگر را نمی‌گیرند. بر اساس اینکه چه چیزی باید همزمان در دسترس بماند انتخاب کنید، نه بر اساس اینکه کدام فرمان کوتاه‌تر است.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
متریک‌ها گزینه ارزان و همان چیزی هستند که مردم اول به آن چنگ می‌زنند. تغییر به رابط مربوط است، پس تا وقتی تونل بالاست کار می‌کند، و جای آن در اسکریپتی کنار کلاینت است نه در پوسته‌ای که فراموش خواهید کرد. نمی‌تواند دسترسی همزمان به یک نشانی در دو شبکه بدهد، و همین محدودیت همه را به پایین جدول می‌فرستد.
شماره‌گذاری مجدد شبکه خانگی به 10.10.0.0/24 راه‌حل تمیز است: یک تمدید اجاره DHCP به‌همراه رزروها، صف‌های چاپ و نشانی‌های سخت‌کدشده‌ای که بازه قدیم را ذکر می‌کنند. شماره‌گذاری مجدد سمت دفتر معمولاً تصمیم شما نیست. IPv6 وقتی هر دو شبکه آن را داشته باشند برخورد را کامل حذف می‌کند، با پیشوند محلی یکتا از fd00::/8 به جای چیزی که به یاد بماند، اما برنامه را روی TCP آزمایش کنید نه با ping، چون ICMP می‌تواند کار کند در حالی که سرویس کار نمی‌کند.
گزینه ترجمه خود OpenVPN آخرین راه است که از سرور به یک ورودی پوشه مخصوص کلاینت فرستاده می‌شود. پس از نام گزینه چهار پارامتر می‌گیرد — جهت، شبکه، ماسک و نام مستعار — و نام مستعار اختیاری نیست: push "route 192.168.2.0 255.255.255.0" و push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". شبکه و ماسک همان بازه‌ای است که کلاینت می‌بیند (192.168.2.0/24)، نام مستعار بازه واقعی دفتر در سمت سرور است (192.168.1.0/24)، و مسیر فرستاده‌شده همان چیزی است که آن بازه دیدنی را در دسترس می‌کند. دفتر سپس برای آن کلاینت زیر 192.168.2.x دیده می‌شود. نگاشت را در پروفایل مستند کنید وگرنه نفر بعدی آن را خطای مسیریابی اشکال‌زدایی می‌کند.
انتشار یک سرویس تنها، نسخه باریک ترجمه است و اصلاً به گزینه OpenVPN نیاز ندارد. یک قاعده DNAT روی میزبان VPN یک درگاه را دوباره منتشر می‌کند، پس شبکه محلی نشانی‌هایش را نگه می‌دارد و به سرویس روی نشانی میزبانی می‌رسد که از قبل می‌شناسد. هزینه همان هزینه معمول است: سرویس میزبان VPN را به‌عنوان مبدأ می‌بیند، پس گزارش‌های هر کلاینت و جست‌وجوهای معکوس دیگر معنایی ندارند. این یک صف چاپ یا یک صفحه مدیریت را پوشش می‌دهد، نه میزبان‌های دو طرف را که به هم برسند.
چه چیزی هنوز کار نخواهد کرد، و چه چیزی را ثبت کنید
پخش همگانی از تونل مسیریابی‌شده عبور نمی‌کند. DLNA، UPnP، مرور NetBIOS و Wake-on-LAN به پخش همگانی یا چندپخشی وابسته‌اند که دستگاه tun آن را حمل نمی‌کند، پس هیچ مسیری کشف را درست نمی‌کند. پل‌سازی با dev tap بخش را گسترش می‌دهد و با آن پخش‌های DHCP، ARP و هر بسته کشف دیگر را؛ مسیر میزبان یک‌پخشی مانند route 192.168.2.1 255.255.255.255 را برای نشانی سمت شبکه محلی یک روتر دور ترجیح دهید.
دو روتر که هر دو 192.168.1.1 را روی یک مسیر به کار می‌برند به همان خانواده مشکل تعلق دارند: نشانی محلی همیشه برنده است، پس صفحه روتر دور تا وقتی یک شبکه جابه‌جا نشود در دسترس نمی‌ماند. افزودن آداپتر دوم در هیچ‌یک از دو حالت چیزی را تغییر نمی‌دهد.
پیش از ویرایش هر چیزی شواهد را ثبت کنید: ip route get یا Find-NetRoute، ping -c 3 به نشانی موردبحث، یک traceroute، و tcpdump -ni tun0 icmp روی کلاینت، سپس جدول مسیریابی و شمارنده‌های NAT روی سرور. pingی که یک طرف کار می‌کند و طرف دیگر می‌میرد به مسیر بازگشت اشاره دارد نه تونل، و همین یک تفاوت تعیین می‌کند کدام تعمیر بالا را واقعاً لازم دارید.