OpenVPN تونل کامل: یک خروجی اینترنت در سمت سرور اضافه کنید
هل دادن یک مسیر پیشفرض تنها نیمی از سرویس تونل کامل است. سرور همچنین به ارسال، یک قاعده ارسال محدود و مسیری بازگشتی برای استخر نیاز دارد.
یک کلاینت احراز هویت میکند، نشانی از استخر میگیرد و به سرویسهای روی میزبان VPN میرسد، اما هر مقصد عمومی به پایان مهلت میخورد. تونل بدون خروج اینگونه است و تا وقتی چهار چیز جداگانه درست نشوند همینطور میماند. کلاینت باید مسیر پیشفرض را بپذیرد، سرور باید ارسال کند، دیوار آتش باید عبور را مجاز کند و پاسخها به مسیری بازگشتی به استخر نیاز دارند. هر چهار خرابی یک نشانه دارند، پس در هر تلاش یک مورد را تغییر دهید و نتیجه را یادداشت کنید.
مسیر پیشفرض را هل دهید و تأیید کنید که کلاینت چه نصب کرده است
خط سمت سرور کوتاه است و فقط بر کلاینتهایی اثر میگذارد که گزینههای هلدادهشده را میپذیرند. شکل def1 دو مسیر نیمهپیشفرض نصب میکند بهجای حذف پیشفرض موجود، که اتصال فعلی را زنده نگه میدارد و همزمان هر مقصدی را میگیرد.
push "redirect-gateway def1"
پس از اتصال دوباره، جدول مسیریابی کلاینت را بخوانید نه اینکه به پروفایل اعتماد کنید. در Linux دو ورودی /1 در کنار پیشفرض اصلی ظاهر میشوند و Windows همان جفت را بهصورت 0.0.0.0/1 و 128.0.0.0/1 نشان میدهد. کلاینتی که گزینههای هلدادهشده را نادیده میگیرد، یا کلاینتی که برای رد کردن آنها پیکربندی شده است، پیشفرض قدیمی خود را نگه میدارد و هرگز ترافیک اینترنت را به تونل نمیفرستد. این مسئله را پیش از تغییر هر چیزی روی سرور حل کنید، زیرا هیچ قاعدهای در سمت سرور نمیتواند آن را جبران کند.
ارسال یک تنظیم سرور است، نه تنظیم VPN
پرچم ارسال را پیش از دست زدن به مسیریابی بخوانید. صفر در آنجا یعنی هسته بسته کلاینت را میگیرد و از فرستادن آن خودداری میکند، که دقیقاً مانند مسدودسازی دیوار آتش از سوی دور به نظر میرسد. مقدار را از طریق پوشه پیکربندی سیستم تنظیم کنید تا از راهاندازی دوباره جان سالم به در ببرد.
sysctl net.ipv4.ip_forward
echo 'net.ipv4.ip_forward=1' | sudo tee /etc/sysctl.d/99-vpn-forward.conf
sudo sysctl --system
سپس تأیید کنید که خود میزبان مسیر کاری به خروجی اینترنت دارد. درخواست از پوسته سرور ثابت میکند مسیر بالادست قابل استفاده است و هیچ چیزی درباره ارسال بسته یک کلاینت نمیگوید، پس آن دو را دو آزمون جدا بدانید. اگر سرور به مقصد نرسد، هیچ مقدار پیکربندی ارسال کمکی نمیکند.
دقیقاً همان عبوری را مجاز کنید که منظورتان است، و هیچ چیز دیگر
بستههای ارسالشده مسیر forward را میپیمایند؛ ترافیکی که به خود میزبان VPN نشانه رفته است مسیر input را میپیماید. اینها تصمیمهای جدایی هستند و باز کردن مسیر input عبور از دستگاه را مجاز نمیکند. اشتباه گرفتن این دو، رایجترین دلیل آن است که دیوار آتش به نظر میرسد همه چیز را مجاز میکند در حالی که کلاینتها همچنان به پایان مهلت میخورند.
یک سیاست حداقلی اتصالهای تازه از استخر به سمت رابط خروج را میپذیرد و پاسخهایی را که به جریانهای برقرارشده تعلق دارند میپذیرد. آن را در همان صاحب مجموعهقواعدی بگذارید که توزیع شما استفاده میکند، نه اینکه در هر راهاندازی یک قاعده تکراری بیفزایید؛ قواعد تکراری انباشته میشوند و شمارندهها دیگر معنایی ندارند.
sudo iptables -A FORWARD -i tun0 -o eth0 -s 10.90.0.0/24 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
تغییر همه زنجیرهها به پذیرش آزمون را پاس میکند و دلیل وجود دیوار آتش را از میان میبرد. دامنه را به استخر و رابط خروج محدود کنید و ارسال بیربط را به حال خود بگذارید.
به پاسخها جایی برای رفتن بدهید
نشانیهای استخر خصوصی هستند، پس یک سرور عمومی نمیتواند پاسخ را مستقیم به آنها برساند. یا میزبان VPN نشانی مبدأ را در مسیر خروج ترجمه میکند، یا دستگاهی در بالادست مسیری بازگشتی به استخر دارد.
sudo iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o eth0 -j MASQUERADE
دقیقاً یک لایه ترجمه بیفزایید. NAT دوم در بالادست اولی را پنهان میکند و وقتی بعداً چیزی خراب شود هر دو گزارش را تقریباً بیفایده میکند. اگر مسیریابی در بالادست از قبل استخر را بازمیگرداند، افزودن ترجمه روی میزبان زائد است و مسیر بازگشت آنگاه به پیکربندی همان مسیریاب وابسته است نه به پیکربندی شما.
نمونههای ابری یک دروازه دیگر اضافه میکنند، زیرا برخی سکوها بستههایی را که نشانی مبدأشان متعلق به خود نمونه نیست دور میریزند مگر اینکه آن بررسی سست شود. این تنظیم بیرون از مهمان قرار دارد و وقتی یک ماشین آزمون محلی کار میکند فراموش کردنش آسان است.
آن را از کلاینت ثابت کنید، نه از پوسته سرور
با یک درخواست عددی IPv4 شروع کنید، سپس جستوجوی نام، سپس برنامه. ping ارسال و ترجمه را ثابت میکند؛درباره تفکیک نام هیچ چیز را ثابت نمیکند، زیرا گزینههای DNS تنها زمانی اثر میکنند که یکپارچهسازی کلاینت آنها را نصب کند.
curl -4 -m 5 http://198.51.100.10/
dig +short example.com
تغییرها و گام بازگشت را همانطور که پیش میروید ثبت کنید تا سیاست خروج هنگام شکست یک آزمون با یک اقدام برگشتپذیر باشد. این دستور تنها IPv4 را پوشش میدهد؛ پیش از ادعای اینکه استقرار همه ترافیک را حمل میکند، IPv6 را جداگانه فهرستبرداری کنید.