کلاینت‌های OpenVPN یکدیگر را نمی‌بینند: subnet یا net30؟
کلاینت‌ها به سرور می‌رسند اما به یکدیگر نه. خطا را با یک ping جدا کنید و سپس توپولوژی subnet، گزینه client-to-client یا یک بخش TAP پل‌شده را انتخاب کنید.
دو خطای نامرتبط همان شکایت را تولید می‌کنند. در اولی، یک کلاینت حتی با نشانی تونل به دیگری نمی‌رسد، زیرا نشانی‌ها در یک subnet نیستند یا سرور ترافیک همتاها را ارسال نمی‌کند. در دومی، ping کار می‌کند و فهرست دستگاه‌های برنامه خالی می‌ماند، زیرا کشف به broadcast متکی است که تونل لایه 3 نمی‌تواند حمل کند. یک ping آن دو را جدا می‌کند، و راه‌حل هر کدام هیچ شبیه راه‌حل دیگری نیست.
یک ping مشکل را به دو نیم می‌کند
از یک کلاینت، نشانی تونل کلاینت دیگر را ping کنید، نه نامش و نه نشانی LAN او را. اگر شکست خورد، مشکل ارسال یا نشانی‌دهی است و کشف تا رفع آن بی‌ربط است. اگر موفق شد، ارسال از قبل کار می‌کند و شکاف باقی‌مانده broadcast یا حل نام است.
ip addr show tun0پیش از هر چیز رابط کلاینت را بخوانید، زیرا ماسک شبکه نام توپولوژی را می‌گوید. یک /24 یا ماسک subnet دیگر یعنی یک استخر مشترک؛ یک /30 با نشانی همتا یعنی چیدمان قدیمی نقطه‌به‌نقطه، که در آن هر کلاینت دقیقاً یک همسایه دارد، سرور.
net30 در برابر subnet، از سمت کلاینت خوانده شود
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
با net30 سرور به هر کلاینت یک بلوک کوچک می‌دهد، بنابراین مسیری به نشانی تونل کلاینت دیگر وجود ندارد مگر اینکه سرور آن را ارسال کند. با subnet تمام استخر یک شبکه است، هر کلاینت می‌تواند هر دیگری را خطاب کند و سرور میان آن‌ها ارسال می‌کند. به همین دلیل یک پیکربندی سرور می‌تواند سالم به نظر برسد در حالی که ping همتاها شکست می‌خورد: هیچ چیز خراب نیست، کلاینت‌ها فقط در یک شبکه نیستند. کلاینت یک پیوند کارکننده و نشانی همتایی می‌بیند که پاسخ نمی‌دهد، چیزی که مانند فایروال خوانده می‌شود اما یک چیدمان نشانی‌دهی است.
تغییر دستورالعمل ویرایشی در سمت سرور به‌همراه راه‌اندازی دوباره است و برای اتصال بعدی اعمال می‌شود، نه نشست‌هایی که از قبل برقرارند. پیش از داوری درباره تغییر، کلاینت‌ها را دوباره متصل کنید. اگر دستگاهی پیکربندی را از یک رابط وب بازتولید می‌کند، دستورالعمل، فایل و تاریخ را ثبت کنید و ویرایش را در صورت وجود از طریق رابط انجام دهید، زیرا بازسازی، ویرایش دستی را در ذخیره بعدی بازنویسی می‌کند.
client-to-client دروازه‌ای جداگانه است
حتی درون یک subnet، سرور بسته‌هایی را که از یک کلاینت می‌رسند و به دیگری نشانه‌گذاری شده‌اند دور می‌ریزد مگر اینکه client-to-client تنظیم شده باشد. آن کلیدواژه سرور را به یک ارسال‌کننده برای ترافیک همتاها تبدیل می‌کند نه یک نقطه پایانی که فقط آن را می‌پذیرد. این دومین شرطی است که مردم پس از درست کردن توپولوژی از دست می‌دهند.
این به broadcast گسترش نمی‌یابد. این تنظیم unicast را میان کلاینت‌ها ارسال می‌کند؛ تونل را به یک بخش مشترک تبدیل نمی‌کند، و هیچ مقدار آن پرس‌وجوی کشف multicast را به هر همتا تحویل نخواهد داد.
TUN در برابر TAP، و اینکه هر کدام چه چیزی می‌تواند حمل کند
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
پل‌کردن یک دستگاه tap به LAN کلاینت‌های دوردست را در دامنه broadcast دفتر قرار می‌دهد، که کشف را کاملاً حل می‌کند. بهایش سکوهایی است که TAP را پیاده نمی‌کنند، پلی که باید روی سرور وجود داشته باشد، و دامنه خرابی‌ای که در آن طوفان broadcast روی کابل دفتر به هر لپ‌تاپ دوردست می‌رسد.
برای دو یا سه ایستگاه کاری که به حل نام نیاز دارند، یک ورودی hosts یا یک نشانی unicast بسیار ارزان‌تر از پل است. زمانی به TAP دست بزنید که پروتکلی که نمی‌توانید جایگزینش کنید به کشف لایه 2 وابسته است، و نه پیش از آن.
کلاینت‌های همان subnet بدون پل
اختصاص نشانی از محدوده LAN کلاینت را روی کابل قرار نمی‌دهد. سرور میان تونل و اترنت مسیریابی می‌کند، بنابراین ARP برای آن نشانی در رابط سرور متوقف می‌شود و بقیه LAN هرگز نمی‌فهمد کجا زندگی می‌کند.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP این شکاف را می‌بندد و سرور از طرف کلاینت پاسخ می‌دهد. برای یک محدوده، parpd با آمدن و رفتن کلاینت‌ها ورودی‌ها را مدیریت می‌کند، در حالی که sysctl net.ipv4.conf.eth0.proxy_arp=1 برای هر چیزی که جای دیگری مسیریابی می‌شود پاسخ می‌دهد، که به‌قدری گسترده است که روی یک بخش شلوغ شگفتی‌های خودش را بسازد.
هر مسیری که برگزینید، NAT را از میان تونل و کابل بردارید. قاعده MASQUERADE دقیقاً همان پرسش نشانی‌دهی را که می‌خواهید پاسخ دهید پنهان می‌کند. همچنین برای نفر بعدی توپولوژی‌ای باقی می‌گذارد که از سمت کلاینت نمی‌تواند درباره‌اش استدلال کند.
پیش از تغییر هر چیزی، یک تلاش روی سرور را با tcpdump -ni tun0 ثبت کنید و تأیید کنید که بسته همتا اصلاً می‌رسد یا نه. رسیدن و دور انداخته شدن به client-to-client اشاره دارد؛ هرگز نرسیدن به توپولوژی یا مسیریابی. راهنمای OpenVPN 2.6 هر دو کلیدواژه و توپولوژی پیش‌فرض را مستند می‌کند و ارزش دارد پیش از کپی کردن یک خط از یک پست انجمن آن را با نسخه خود بسنجید.
- رابط tun ماسک استخر نشان می‌دهد نه یک جفت همتای /30.
- ping مستقیم به نشانی تونل دیگر پیش از آزمودن کشف موفق می‌شود.
- پیکربندی سرور هر زمان که همتاها باید بسته‌ها را مبادله کنند شامل
client-to-clientاست. - پروتکل کشفی را که می‌آزمایید نام ببرید، نه اینکه بگویید برنامه شکست می‌خورد.
- TAP را فقط زمانی به کار ببرید که هر سکوی کلاینت در گروه از آن پشتیبانی کند.
- وقتی دسترس‌پذیری درون همان subnet اهمیت دارد، NAT را از مسیر میان تونل و LAN بیرون نگه دارید.