آیا هر همتای OpenVPN به یک خط remote نیاز دارد؟ نه دقیقاً
remote مشخص می‌کند بسته اول به کجا می‌رود؛ نقش کلاینت، سرور یا TLS را انتخاب نمی‌کند. پیش از کپی کردن آن به هر دو طرف، چیدمان را بخوانید.
دو پیکربندی همتا کنار هم مقایسه می‌شوند، یکی خط remote دارد و دیگری ندارد، و نتیجه این است که یکی از آن‌ها خراب است. این استنباط به‌قدری غالباً نادرست است که ارزش واکاوی داشته باشد. دستورالعمل توصیف می‌کند که بسته اول باید کجا فرستاده شود. اما انتخاب نمی‌کند که فرایند به‌عنوان کلاینت آغازگر یا دروازه منتظر عمل کند، و تعیین نمی‌کند کدام طرف هویت خود را به دیگری اثبات می‌کند.
remote در واقع چه چیزی را مشخص می‌کند
یک ورودی remote یک میزبان، به‌صورت اختیاری یک پورت و یک ترابری، و به‌صورت اختیاری چندین ورودی از این نوع را نام می‌برد که به‌ترتیب آزموده می‌شوند.
نبودن آن معنایی معین دارد نه مبهم: فرایند منتظر می‌ماند و تا وقتی آن همتا احراز هویت نکند، به بسته‌های یک نشانی واکنش نمی‌دهد. بنابراین دروازه‌ای که به کاربران سیار خدمت می‌دهد دلیلی ندارد از پیش هیچ‌یک از آن‌ها را نام ببرد.
ورودی را به‌عنوان رابطه نشانی بخوانید. اینکه طرف دور قابل اعتماد است یا نه را گواهی‌ها و گزینه‌های بررسی پاسخ می‌دهند، نه این واقعیت که نشانی‌ای نوشته شده است.
سه چیدمان پاسخ را تعیین می‌کند
کلاینت سیار به مقصد نیاز دارد، چون باید آغاز کند و بدون آن نمی‌داند دروازه کجاست. دروازه چندکلاینتی به مقصدی برای هر کاربر نیاز ندارد، چون کلاینت‌ها می‌رسند و احراز هویت می‌کنند. پیوند عمدی دو همتا با نقاط پایانی شناخته‌شده می‌تواند در یک طرف، در هر دو طرف یا در هیچ‌کدام مقصد داشته باشد، بسته به اینکه کدام طرف آغاز کند.
چسباندن یک نشانی ثابت کلاینت در یک دروازه عمومی همان خطایی است که از نادیده گرفتن این دسته‌ها ناشی می‌شود. برای تنها همتایی که نشانی‌اش ثبت شده کار می‌کند و بقیه را گمراه می‌کند.
هیچ چیز در دستورالعمل یک پیکربندی را به سرور چندکلاینتی تبدیل نمی‌کند، و هیچ چیز در وجود آن مانع نقش سرور نمی‌شود. مرجع OpenVPN 2.6 آرگومان‌های اختیاری و رفتار بدون remote را جداگانه مستند می‌کند، که نشانه‌ای از میزان استقلال آن‌هاست.
| Arrangement | Needs a destination |
|---|---|
| Roaming client | Yes, which gateway to contact |
| Multi-client gateway | No, peers authenticate on arrival |
| Two known peers | Depends on which side initiates |
نقش‌های ترابری محور دیگری هستند
در TCP یک طرف منتظر می‌ماند و طرف دیگر تماس می‌گیرد. این‌ها دستورالعمل‌هایی جدا از مقصد هستند و آمیختنشان جفتی می‌سازد که هر دو منتظر می‌مانند یا هر دو تماس می‌گیرند.
نقش پالایه منبع TCP هم وجود دارد، و به همین دلیل این گزاره صاف که سرور هرگز نمی‌تواند remote داشته باشد نادرست است.
در UDP اتصالی برای برقراری وجود ندارد، پس دو سر از ترابری UDP متناظر استفاده می‌کنند و دستورالعمل فقط می‌گوید به کجا نشانه بگیرید. تغییر نشانی از سوی همتای احراز‌شده با رفتار اختصاصی اداره می‌شود نه با افزودن ورودی‌های بیشتر. درست بودن ترابری پیش‌شرط معنادار بودن مقصد است، و آمیختن این دو پیکربندی‌هایی می‌سازد که محتمل به نظر می‌رسند و هرگز دست‌دادن را کامل نمی‌کنند.
چرا نبودن remote در باز نیست
فرایندی بدون مقصد همچنان ترافیک همتاهایی را که احراز هویت نمی‌کنند رد می‌کند، و این همان بخشی است که مردم از دست می‌دهند وقتی خط غایب را شنونده‌ای باز برای همه می‌خوانند.
احراز هویت و مقصد مستقل‌اند، و اولی همان است که برای اعتماد اهمیت دارد.
خطای معکوس خطرناک‌تر است. یک نشانی مبدأ ثابت می‌تواند مثل کنترل دسترسی احساس شود چون مشخص و آسان برای بررسی است، اما هیچ چیز درباره اینکه چه کسی در طرف دیگر است اثبات نمی‌کند. بررسی گواهی و بررسی‌های هویتی را که گواهی را به نقشش می‌بندند نگه دارید. جایگزین کردن آن‌ها با تطبیق نشانی، کنترلی واقعی را با ظاهر آن معاوضه می‌کند.
بنویسید پیکربندی چه چیزی را فرض می‌کند
برای هر طرف سه چیز را ثبت کنید: بسته اول چگونه به همتا می‌رسد، کدام طرف می‌تواند ترابری را بپذیرد، و هر طرف درباره دیگری چه چیزی را بررسی می‌کند.
این فرض‌ها همان طراحی‌اند. دستورالعمل‌ها فقط املای آن‌ها هستند.
اگر دو فایل متفاوت‌اند، بررسی کنید آیا فرض‌های متفاوتی را بیان می‌کنند، نه اینکه فرض کنید یکی نادرست است. جفت متقارن فایل‌ها برای یک تونل کارآمد نه لازم است نه کافی، و نامتقارنی غالباً همان بخشی است که یک توپولوژی را کار می‌اندازد.