آیا می خواهید از لینوکس در محل کار استفاده کنید، اما VPN شرکت شما به شما اجازه نمی دهد؟ سپس این مقاله ممکن است کمک کند، اگرچه این قطعی نیست. پیشاپیش به شما هشدار میدهم که من مسائل مدیریت شبکه را به خوبی درک نمیکنم، بنابراین ممکن است همه کارها را اشتباه انجام داده باشم. از طرفی این امکان وجود دارد که بتوانم راهنما را طوری بنویسم که برای مردم عادی قابل درک باشد، پس توصیه می کنم آن را امتحان کنید.
مقاله حاوی اطلاعات غیر ضروری زیادی است، اما بدون این دانش من نمی توانستم مشکلاتی را که به طور غیرمنتظره با راه اندازی VPN برای من ظاهر شد را حل کنم. من فکر می کنم هرکسی که سعی کند از این راهنما استفاده کند، مشکلاتی خواهد داشت که من نداشتم، و امیدوارم این اطلاعات اضافی به حل این مشکلات به تنهایی کمک کند.
اکثر دستورات استفاده شده در این راهنما باید از طریق sudo اجرا شوند که برای اختصار حذف شده است. یادت باشه.
اکثر آدرس های IP به شدت مبهم شده اند، بنابراین اگر آدرسی مانند 435.435.435.435 را مشاهده کردید، باید مقداری IP معمولی، مخصوص مورد شما، وجود داشته باشد.
من اوبونتو 18.04 دارم، اما فکر میکنم با تغییرات جزئی میتوان این راهنما را برای توزیعهای دیگر اعمال کرد. با این حال، در این متن لینوکس == اوبونتو.
Cisco Connect
کسانی که از Windows یا MacOS استفاده می کنند می توانند از طریق Cisco Connect به VPN شرکتی ما متصل شوند، که باید آدرس دروازه را مشخص کند و هر بار که متصل می شوید، رمز عبوری متشکل از یک بخش ثابت و یک کد ایجاد شده توسط Google Authenticator را وارد کنید.
در مورد لینوکس، من نتوانستم Cisco Connect را اجرا کنم، اما موفق شدم توصیه ای برای استفاده از openconnect را در گوگل جستجو کنم، که به طور خاص برای جایگزینی Cisco Connect ساخته شده بود.
اتصال را باز کنید
در تئوری، اوبونتو یک رابط گرافیکی ویژه برای openconnect دارد، اما برای من کار نکرد. شاید برای بهتر شدن باشد.
در اوبونتو، openconnect از مدیر بسته نصب شده است.
apt install openconnect
بلافاصله پس از نصب، می توانید اتصال به VPN را امتحان کنید
openconnect --user poxvuibr vpn.evilcorp.com
vpn.evilcorp.com آدرس یک VPN ساختگی است
poxvuibr - نام کاربری ساختگی
openconnect از شما می خواهد پسوردی را وارد کنید که یادآور می شوم از یک قسمت ثابت و یک کد از Google Authenticator تشکیل شده است و سپس سعی می کند به vpn متصل شود. اگر جواب داد، تبریک میگوییم، میتوانید با خیال راحت از وسط رد شوید، که بسیار دردناک است، و به نقطه اجرای openconnect در پسزمینه بروید. اگر کار نکرد، می توانید ادامه دهید. اگر چه اگر هنگام اتصال، به عنوان مثال، از وای فای مهمان در محل کار، کار کرد، ممکن است برای خوشحالی خیلی زود باشد؛ باید سعی کنید این روش را از خانه تکرار کنید.
گواهی
احتمال زیادی وجود دارد که هیچ چیز شروع نشود و خروجی openconnect چیزی شبیه به این خواهد بود:
POST https://vpn.evilcorp.com/
Connected to 777.777.777.777:443
SSL negotiation with vpn.evilcorp.com
Server certificate verify failed: signer not found
Certificate from VPN server "vpn.evilcorp.com" failed verification.
Reason: signer not found
To trust this server in future, perhaps add this to your command line:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progress
از یک طرف، این ناخوشایند است، زیرا هیچ اتصالی به VPN وجود ندارد، اما از طرف دیگر، نحوه رفع این مشکل، در اصل، روشن است.
در اینجا سرور یک گواهی برای ما ارسال کرد که به وسیله آن می توانیم تشخیص دهیم که اتصال به سرور شرکت بومی ما انجام می شود و نه به یک کلاهبردار شیطانی و این گواهی برای سیستم ناشناخته است. و بنابراین او نمی تواند بررسی کند که آیا سرور واقعی است یا نه. و بنابراین، در هر صورت، کار را متوقف می کند.
برای اینکه openconnect به سرور متصل شود، باید با استفاده از کلید —servercert به صراحت به آن بگویید که کدام گواهی باید از سرور VPN باشد.
و می توانید دریابید که سرور کدام گواهی را مستقیماً از آنچه openconnect چاپ شده برای ما ارسال کرده است. این هم از این قطعه:
To trust this server in future, perhaps add this to your command line:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progress
با این دستور می توانید دوباره سعی کنید وصل شوید
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com
شاید اکنون کار می کند، سپس می توانید تا انتها حرکت کنید. اما شخصا اوبونتا یک انجیر به این شکل به من نشان داد
POST https://vpn.evilcorp.com/
Connected to 777.777.777.777:443
SSL negotiation with vpn.evilcorp.com
Server certificate verify failed: signer not found
Connected to HTTPS on vpn.evilcorp.com
XML POST enabled
Please enter your username and password.
POST https://vpn.evilcorp.com/
Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 300, Keepalive 30
Set up DTLS failed; using SSL instead
Connected as 192.168.333.222, using SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK answers: File exists
/etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf
/etc/resolv.conf
# Generated by NetworkManager
search gst.evilcorpguest.com
nameserver 127.0.0.53
/run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 192.168.430.534
nameserver 127.0.0.53
search evilcorp.com gst.publicevilcorp.com
habr.com حل خواهد شد، اما شما نمی توانید به آنجا بروید. آدرس هایی مثل jira.evilcorp.com اصلا حل نمی شوند.
چه اتفاقی در اینجا افتاد برای من روشن نیست. اما آزمایش نشان می دهد که اگر خط را به /etc/resolv.conf اضافه کنید
nameserver 192.168.430.534
سپس آدرسهای داخل VPN به طور جادویی شروع به حل شدن میکنند و میتوانید از میان آنها عبور کنید، یعنی آنچه DNS برای حل کردن آدرسها به دنبال آن است، به طور خاص در /etc/resolv.conf به نظر میرسد، نه در جای دیگری.
میتوانید تأیید کنید که اتصالی به VPN وجود دارد و بدون ایجاد هیچ تغییری در /etc/resolv.conf کار میکند؛ برای انجام این کار، فقط نام نمادین منبع VPN را در مرورگر وارد کنید، بلکه آدرس IP آن را وارد کنید.
در نتیجه دو مشکل وجود دارد
- هنگام اتصال به VPN، dns آن برداشت نمی شود
- تمام ترافیک از طریق VPN انجام می شود که اجازه دسترسی به اینترنت را نمی دهد
اکنون به شما خواهم گفت که چه کاری انجام دهید، اما ابتدا کمی اتوماسیون.
ورود خودکار قسمت ثابت رمز عبور
تا به حال، به احتمال زیاد حداقل پنج بار رمز عبور خود را وارد کرده اید و این روش قبلاً شما را خسته کرده است. اولاً به این دلیل که رمز عبور طولانی است و ثانیاً به این دلیل که هنگام وارد کردن باید در یک بازه زمانی ثابت قرار بگیرید
راه حل نهایی مشکل در مقاله ذکر نشده است، اما می توانید مطمئن شوید که قسمت ثابت رمز عبور لازم نیست بارها وارد شود.
بیایید فرض کنیم که قسمت ثابت رمز عبور fixedPassword است و بخشی از Google Authenticator 567 است. کل رمز عبور را می توان از طریق ورودی استاندارد با استفاده از آرگومان --passwd-on-stdin به openconnect ارسال کرد.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdin
اکنون می توانید دائماً به آخرین دستور وارد شده برگردید و تنها بخشی از Google Authenticator را در آنجا تغییر دهید.
VPN شرکتی به شما امکان گشت و گذار در اینترنت را نمی دهد.
به طور کلی، زمانی که برای رفتن به Habr مجبور به استفاده از یک کامپیوتر جداگانه هستید، خیلی ناراحت کننده نیست. ناتوانی در کپی پیست از stackoverfow به طور کلی می تواند کار را فلج کند، بنابراین باید کاری انجام شود.
باید به نحوی آن را سازماندهی کنیم تا زمانی که نیاز به دسترسی به منبعی از شبکه داخلی دارید، لینوکس به VPN و زمانی که نیاز به رفتن به Habr دارید، به اینترنت برود.
openconnect پس از راه اندازی و برقراری ارتباط با vpn، اسکریپت خاصی را اجرا می کند که در /usr/share/vpnc-scripts/vpnc-script قرار دارد. برخی از متغیرها به عنوان ورودی به اسکریپت ارسال می شوند و VPN را پیکربندی می کند. متأسفانه، من نتوانستم بفهمم که چگونه با استفاده از یک اسکریپت بومی، جریان ترافیک را بین VPN شرکت و بقیه اینترنت تقسیم کنم.
ظاهراً ابزار vpn-slice مخصوصاً برای افرادی مثل من ساخته شده است که به شما امکان می دهد بدون رقص با تنبور ترافیک را از طریق دو کانال ارسال کنید. خوب، یعنی شما باید برقصید، اما لازم نیست شمن باشید.
جداسازی ترافیک با استفاده از vpn-slice
ابتدا باید vpn-slice را نصب کنید، باید خودتان متوجه این موضوع شوید. اگر سوالی در کامنت ها وجود داشته باشد، یک پست جداگانه در این مورد می نویسم. اما این یک برنامه معمولی پایتون است، بنابراین نباید هیچ مشکلی وجود داشته باشد. من با استفاده از virtualenv نصب کردم.
و سپس ابزار باید با استفاده از سوئیچ -script اعمال شود، که نشان می دهد به جای اسکریپت استاندارد، باید از vpn-slice استفاده کنید.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com
--script یک رشته با دستوری ارسال می شود که باید به جای اسکریپت فراخوانی شود. ./bin/vpn-slice - مسیر فایل اجرایی vpn-slice 192.168.430.0/24 - ماسک آدرس هایی که باید در vpn به آنها بروید. در اینجا منظور ما این است که اگر آدرس با 192.168.430 شروع شود، منبع با این آدرس باید در داخل VPN جستجو شود.
اکنون وضعیت باید تقریباً عادی باشد. تقریبا. اکنون می توانید به Habr بروید و با IP می توانید به منبع درون سازمانی بروید، اما با نام نمادین نمی توانید به منبع درون سازمانی بروید. اگر یک تطابق بین نام نمادین و آدرس در هاست مشخص کنید، همه چیز باید کار کند. و تا زمانی که ip تغییر کند کار کنید. اکنون لینوکس بسته به IP می تواند به اینترنت یا اینترانت دسترسی داشته باشد. اما DNS غیر شرکتی هنوز برای تعیین آدرس استفاده می شود.
مشکل همچنین می تواند خود را به این شکل نشان دهد - در محل کار همه چیز خوب است، اما در خانه فقط می توانید از طریق IP به منابع داخلی شرکت دسترسی داشته باشید. به این دلیل که وقتی به وای فای شرکتی وصل میشوید، از DNS شرکت نیز استفاده میشود و آدرسهای نمادین VPN در آن حل میشود، علیرغم اینکه هنوز امکان رفتن به چنین آدرسی بدون استفاده از VPN وجود ندارد.
تغییر خودکار فایل هاست
اگر مودبانه از vpn-slice پرسیده شود، پس از بالا بردن VPN، می تواند به DNS خود رفته، آدرس IP منابع لازم را با نام نمادین آنها پیدا کرده و آنها را در هاست وارد کند. پس از خاموش کردن VPN، این آدرس ها از هاست حذف می شوند. برای این کار باید اسامی نمادین را به عنوان آرگومان به vpn-slice منتقل کنید. مثل این.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
اکنون همه چیز باید هم در دفتر و هم در ساحل کار کند.
آدرس تمام زیر دامنه ها را در DNS ارائه شده توسط VPN جستجو کنید
اگر آدرسهای کمی در شبکه وجود داشته باشد، روش تغییر خودکار فایل میزبان به خوبی کار میکند. اما اگر منابع زیادی در شبکه وجود داشته باشد، باید دائماً خطوطی مانند zoidberg.test.evilcorp.com را به اسکریپت اضافه کنید. zoidberg نام یکی از میزهای تست است.
اما اکنون که کمی درک می کنیم که چرا می توان این نیاز را برطرف کرد.
اگر پس از بالا بردن VPN، به /etc/hosts نگاه کنید، می توانید این خط را ببینید
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUOCREATED
و یک خط جدید به resolv.conf اضافه شد. به طور خلاصه، vpn-slice به نوعی تعیین می کند که سرور dns برای vpn در کجا قرار دارد.
اکنون باید مطمئن شویم که برای یافتن آدرس IP نام دامنه ای که به evilcorp.com ختم می شود، لینوکس به DNS شرکتی می رود و اگر چیز دیگری نیاز است، به DNS پیش فرض می رود.
من مدت زیادی در گوگل جستجو کردم و متوجه شدم که چنین قابلیتی در اوبونتو در دسترس است. این به معنای توانایی استفاده از سرور DNS محلی dnsmasq برای حل نام ها است.
یعنی میتوانید مطمئن شوید که لینوکس همیشه برای آدرسهای IP به سرور DNS محلی میرود، که به نوبه خود، بسته به نام دامنه، به دنبال IP در سرور DNS خارجی مربوطه میگردد.
اوبونتو برای مدیریت همه چیز مربوط به شبکه ها و اتصالات شبکه از NetworkManager استفاده می کند و رابط گرافیکی برای انتخاب مثلاً اتصالات Wi-Fi فقط یک قسمت جلویی برای آن است.
ما باید در پیکربندی آن صعود کنیم.
- یک فایل در /etc/NetworkManager/dnsmasq.d/evilcorp ایجاد کنید
آدرس=/.evilcorp.com/192.168.430.534
به نقطه مقابل evilcorp توجه کنید. این سیگنال به dnsmasq می دهد که همه زیر دامنه های evilcorp.com باید در dns شرکت جستجو شوند.
- به NetworkManager بگویید از dnsmasq برای تفکیک نام استفاده کند
پیکربندی مدیر شبکه در /etc/NetworkManager/NetworkManager.conf قرار دارد شما باید در آنجا اضافه کنید:
[اصلی] dns=dnsmasq
- NetworkManager را مجددا راه اندازی کنید
service network-manager restart
حال، پس از اتصال به VPN با استفاده از openconnect و vpn-slice، ip به طور معمول مشخص می شود، حتی اگر آدرس های نمادین را به آرگومان های vpnslice اضافه نکنید.
نحوه دسترسی به خدمات فردی از طریق VPN
بعد از اینکه موفق شدم به VPN وصل شوم، دو روز خیلی خوشحال شدم و بعد معلوم شد که اگر از خارج از شبکه اداری به VPN وصل شوم، ایمیل کار نمی کند. این علامت آشناست، اینطور نیست؟
نامه ما در mail.publicevilcorp.com قرار دارد، به این معنی که تحت قانون در dnsmasq قرار نمی گیرد و آدرس سرور ایمیل از طریق DNS عمومی جستجو می شود.
خب، آفیس هنوز از DNS استفاده می کند که حاوی این آدرس است. این چیزی است که من فکر می کردم. در واقع پس از افزودن خط به dnsmasq
آدرس=/mail.publicevilcorp.com/192.168.430.534
وضعیت به هیچ وجه تغییر نکرده است. ip ثابت ماند مجبور شدم برم سر کار
و فقط بعداً، وقتی عمیقتر به این موقعیت پرداختم و کمی مشکل را درک کردم، یک فرد باهوش به من گفت که چگونه آن را حل کنم. اتصال به سرور پست الکترونیکی نه فقط به این صورت، بلکه از طریق VPN ضروری بود
من از vpn-slice برای رفتن از طریق VPN به آدرس هایی که با 192.168.430 شروع می شوند استفاده می کنم. و سرور ایمیل نه تنها دارای یک آدرس نمادین است که زیر دامنه ای از evilcorp نیست، بلکه یک آدرس IP که با 192.168.430 شروع می شود نیز ندارد. و البته او اجازه نمی دهد کسی از شبکه عمومی به او بیاید.
برای اینکه لینوکس از طریق VPN و سرور پست الکترونیکی عبور کند، باید آن را به vpn-slice نیز اضافه کنید. فرض کنید آدرس پست کننده 555.555.555.555 باشد.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 555.555.555.555 192.168.430.0/24" vpn.evilcorp.com
اسکریپتی برای افزایش VPN با یک آرگومان
همه اینها، البته، خیلی راحت نیست. بله، میتوانید متن را در یک فایل ذخیره کنید و به جای تایپ دستی، آن را در کنسول کپی کنید، اما هنوز خیلی خوشایند نیست. برای آسانتر کردن فرآیند، میتوانید دستور را در یک اسکریپت قرار دهید که در PATH قرار دارد. و سپس فقط باید کد دریافت شده از Google Authenticator را وارد کنید
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
اگر اسکریپت را در connect~evilcorp~ قرار دهید، می توانید به سادگی در کنسول بنویسید
connect_evil_corp 567987
اما اکنون باید کنسولی را که openconnect در آن در حال اجراست به دلایلی باز نگه دارید
اجرای openconnect در پسزمینه
خوشبختانه، نویسندگان openconnect از ما مراقبت کردند و یک کلید ویژه به پس زمینه برنامه اضافه کردند، که باعث می شود برنامه پس از راه اندازی در پس زمینه کار کند. اگر به این صورت اجرا کنید، می توانید پس از راه اندازی کنسول را ببندید
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
اکنون مشخص نیست که لاگ ها کجا می روند. به طور کلی، ما واقعاً نیازی به گزارش نداریم، اما شما هرگز نمی دانید. openconnect میتواند آنها را به syslog هدایت کند، جایی که امن و ایمن نگه داشته میشوند. باید سوئیچ –syslog را به دستور اضافه کنید
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--syslog
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
و بنابراین، معلوم میشود که openconnect در جایی در پسزمینه کار میکند و کسی را آزار نمیدهد، اما روشن نیست که چگونه آن را متوقف کنیم. یعنی می توانید خروجی ps را با استفاده از grep فیلتر کنید و به دنبال فرآیندی بگردید که نام آن حاوی openconnect باشد، اما این کار به نوعی خسته کننده است. با تشکر از نویسندگانی که به این موضوع فکر کردند. Openconnect یک کلید -pid-file دارد که با آن می توانید به openconnect دستور دهید شناسه فرآیند خود را در یک فایل بنویسد.
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--syslog
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
--pid-file ~/vpn-pid
حالا شما همیشه می توانید یک فرآیند را با دستور بکشید
kill $(cat ~/vpn-pid)
اگر روندی وجود نداشته باشد، kill نفرین می کند، اما خطا نمی کند. اگر فایل وجود نداشته باشد، هیچ اتفاق بدی نیز نمی افتد، بنابراین می توانید با خیال راحت روند را در خط اول اسکریپت از بین ببرید.
kill $(cat ~/vpn-pid)
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--syslog
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
--pid-file ~/vpn-pid
اکنون می توانید رایانه خود را روشن کنید، کنسول را باز کرده و فرمان را اجرا کنید و کد آن را از Google Authenticator ارسال کنید. سپس می توان کنسول را میخ کرد.
بدون VPN-slice. به جای حرف آخر
معلوم شد که درک نحوه زندگی بدون VPN-slice بسیار دشوار است. مجبور شدم زیاد بخونم و گوگل کنم. خوشبختانه، پس از گذراندن زمان زیادی با یک مشکل، کتابچه راهنمای فنی و حتی انسان openconnect مانند رمان های هیجان انگیز خواندند.
در نتیجه، متوجه شدم که vpn-slice، مانند اسکریپت اصلی، جدول مسیریابی را به شبکه های جداگانه تغییر می دهد.
جدول مسیریابی
به بیان ساده، این یک جدول در ستون اول است که حاوی آدرسی است که لینوکس میخواهد از آن عبور کند و در ستون دوم از کدام آداپتور شبکه در این آدرس عبور کند. در واقع اسپیکرهای بیشتری وجود دارد، اما این تغییری در ماهیت ایجاد نمی کند.
برای مشاهده جدول مسیریابی، باید دستور ip route را اجرا کنید
default via 192.168.1.1 dev wlp3s0 proto dhcp metric 600
192.168.430.0/24 dev tun0 scope link
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.534 metric 600
192.168.430.534 dev tun0 scope link
در اینجا، هر خط مسئول جایی است که باید برای ارسال پیام به آدرسی بروید. اولین توضیحی است که نشانی باید از کجا شروع شود. برای اینکه بفهمید چگونه می توان تعیین کرد که 192.168.0.0/16 به این معنی است که آدرس باید با 192.168 شروع شود، باید در گوگل جستجو کنید که ماسک آدرس IP چیست. بعد از dev نام آداپتوری است که پیام باید به آن ارسال شود.
برای VPN، لینوکس یک آداپتور مجازی ساخت - tun0. این خط تضمین میکند که ترافیک همه آدرسهایی که با 192.168 شروع میشوند از آن عبور میکند
192.168.0.0/16 dev tun0 scope link
همچنین می توانید با استفاده از دستور به وضعیت فعلی جدول مسیریابی نگاه کنید مسیر -n (آدرس های IP هوشمندانه ناشناس هستند) این دستور نتایج را به شکل دیگری تولید می کند و به طور کلی منسوخ شده است، اما خروجی آن اغلب در کتابچه های راهنما در اینترنت یافت می شود و شما باید بتوانید آن را بخوانید.
از ترکیب ستون های Destination و Genmask می توان آدرس IP یک مسیر را از کجا شروع کرد. آن قسمتهایی از آدرس IP که با اعداد 255 در Genmask مطابقت دارند در نظر گرفته میشوند، اما آنهایی که 0 وجود دارد، در نظر گرفته نمیشوند. یعنی ترکیب Destination 192.168.0.0 و Genmask 255.255.255.0 به این معنی است که اگر آدرس با 192.168.0 شروع شود، درخواست به آن در این مسیر خواهد رفت. و اگر Destination 192.168.0.0 اما Genmask 255.255.0.0 باشد، در این صورت درخواستهایی به آدرسهایی که با 192.168 شروع میشوند در این مسیر خواهند رفت.
برای اینکه بفهمم vpn-slice واقعا چه کاری انجام می دهد، تصمیم گرفتم به وضعیت جداول قبل و بعد نگاه کنم.
قبل از روشن کردن VPN به این صورت بود
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0
بعد از فراخوانی openconnect بدون vpn-slice اینطور شد
route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0
192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
و بعد از فراخوانی openconnect در ترکیب با vpn-slice به این صورت
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0
192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
مشاهده می شود که اگر از vpn-slice استفاده نمی کنید، openconnect به صراحت می نویسد که به همه آدرس ها، به جز آنهایی که مشخصاً نشان داده شده اند، باید از طریق vpn دسترسی داشته باشید.
درست همین جا:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
در آنجا، در کنار آن، بلافاصله مسیر دیگری نشان داده شده است، که اگر آدرسی که لینوکس می خواهد از آن عبور کند، با هیچ ماسکی از جدول مطابقت نداشته باشد، باید از آن استفاده شود.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
قبلاً در اینجا نوشته شده است که در این مورد باید از یک آداپتور استاندارد Wi-Fi استفاده کنید.
من معتقدم که از مسیر VPN استفاده می شود زیرا اولین مسیر در جدول مسیریابی است.
و از نظر تئوری، اگر این مسیر پیش فرض را از جدول مسیریابی حذف کنید، در ارتباط با dnsmasq openconnect باید از عملکرد عادی اطمینان حاصل شود.
من سعی کردم
route del default
و همه چیز کار کرد.
مسیریابی درخواست ها به سرور ایمیل بدون vpn-slice
اما من یک میل سرور با آدرس 555.555.555.555 هم دارم که باید از طریق VPN نیز به آن دسترسی پیدا کرد. مسیر رسیدن به آن نیز باید به صورت دستی اضافه شود.
ip route add 555.555.555.555 via dev tun0
و اکنون همه چیز خوب است. بنابراین شما می توانید بدون vpn-slice انجام دهید، اما باید به خوبی بدانید که چه کاری انجام می دهید. اکنون به این فکر می کنم که حذف مسیر پیش فرض را به آخرین خط اسکریپت openconnect داخلی اضافه کنم و پس از اتصال به vpn یک مسیر برای میلر اضافه کنم، فقط برای اینکه قطعات متحرک کمتری در دوچرخه من وجود داشته باشد.
احتمالاً این پسورد برای کسی کافی باشد تا بفهمد چگونه یک VPN راه اندازی کند. اما در حالی که سعی می کردم بفهمم چه کاری و چگونه انجام دهم، تعداد زیادی از چنین راهنماهایی را خواندم که برای نویسنده کار می کنند، اما به دلایلی برای من کار نمی کنند و تصمیم گرفتم تمام قطعاتی را که پیدا کردم در اینجا اضافه کنم. من برای چنین چیزی بسیار خوشحال خواهم شد.
منبع: www.habr.com