کمک‌کننده سرور OpenVPN: شبکه به‌همراه ماسک، هرگز CIDR

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

دو آرگومانی که کمک‌کننده می‌پذیرد

نخست شبکه را بنویسید و سپس ماسک را، بدون آنکه چیزی به نشانی بچسبد:

server 10.72.16.0 255.255.240.0

این شکل مربوط به /20 است. خط زیر اشتباه است و در تجزیه گزینه‌ها شکست می‌خورد، نه در زمان اجرا:

server 10.72.16.0/20 255.255.240.0

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

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

نشانی نخست نشانی شبکه بازه است، نه یک نشانی کلاینت راحت درون آن. برای /20 بازه از 10.72.16.0 تا 10.72.31.255 کشیده می‌شود، و تنها اولی از آنها آرگومان معتبر شبکه است. /21 از 255.255.248.0 استفاده می‌کند و از 10.72.16.0 تا 10.72.23.255 را پوشش می‌دهد، پس خط آن server 10.72.16.0 255.255.248.0 است.

تغییر پیشوند بازه را تغییر می‌دهد و بس. تعداد نشانی‌هایی که یک کلاینت می‌گیرد را تغییر نمی‌دهد، زیرا این ویژگی توپولوژی است، نه ماسک روی این خط.

استخر را از سمت سرور تأیید کنید

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

openvpn --config /etc/openvpn/server.conf --verb 4 --dev tun9 --port 1195

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

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

ماسک کلاینت را با در نظر گرفتن توپولوژی بخوانید

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

پیش از نتیجه‌گیری، توپولوژی پیکربندی‌شده و نشانی تخصیص‌یافته را با هم بررسی کنید:

ip -4 addr show tun0

اگر نشانی درون استخر باشد و ماسک از استخر تنگ‌تر باشد، این توپولوژی است که کار خود را می‌کند. اگر نشانی بیرون از استخر باشد، استخر اشتباه است و هیچ بازرسی سمت کلاینت آن را درست نمی‌کند.

تغییر یک استخر زنده

بازه‌ای انتخاب کنید که با استخر فعلی، LAN یا هر مسیری که پیش‌تر به کلاینت‌ها فرستاده شده همپوشانی نداشته باشد. همپوشانی همان شکستی است که از راه‌اندازی مجدد جان سالم به در می‌برد و بعد روزها بعد به‌صورت یک سایت دسترس‌ناپذیر از یک جهت ظاهر می‌شود.

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

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