هل تريد استخدام Linux في العمل ، لكن VPN لشركتك لا؟ ثم قد تساعد هذه المقالة ، على الرغم من أنها ليست دقيقة. أريد أن أحذرك مقدمًا من أنني لا أفهم مشكلات إدارة الشبكة جيدًا ، لذلك من المحتمل أنني ارتكبت كل شيء بشكل خاطئ. من ناحية أخرى ، من الممكن أن أكون قادرًا على كتابة دليل بطريقة تجعله مفهومًا للناس العاديين ، لذلك أنصحك بتجربته.
هناك الكثير من المعلومات غير الضرورية في المقالة ، لكن بدون هذه المعرفة لم أكن لأتمكن من حل المشكلات التي واجهتها فجأة مع إعداد VPN. أعتقد أن أي شخص يحاول استخدام هذا الدليل سيواجه مشاكل لم أواجهها ، وآمل أن تساعدك هذه المعلومات الإضافية في حل هذه المشكلات بنفسك.
يجب تشغيل معظم الأوامر المستخدمة في الدليل عبر sudo ، الذي تمت إزالته للإيجاز. تذكر.
خضعت معظم عناوين IP للتعتيم الشديد ، لذلك إذا رأيت عنوانًا مثل 435.435.435.435 ، فيجب أن يكون هناك عنوان IP عادي خاص بحالتك.
لدي Ubuntu 18.04 ، لكنني أعتقد أنه مع بعض التغييرات ، يمكن تطبيق الدليل على التوزيعات الأخرى. ومع ذلك ، في هذا النص ، Linux == Ubuntu.
سيسكو كونيكت
يمكن لأولئك الذين يستخدمون Windows أو MacOS الاتصال بشركة VPN الخاصة بشركتنا عبر Cisco Connect ، والتي تحتاج إلى تحديد عنوان البوابة وإدخال كلمة مرور في كل مرة تتصل فيها ، وتتكون من جزء ثابت ورمز تم إنشاؤه بواسطة Google Authenticator.
في حالة Linux ، لم يكن من الممكن بدء Cisco Connect ، ولكن اتضح لجوجل التوصية باستخدام openconnect ، المصممة خصيصًا لاستبدال Cisco Connect.
فتح الاتصال
من الناحية النظرية ، تمتلك Ubuntu واجهة رسومية خاصة لـ openconnect ، لكنها لم تنجح معي. ربما يكون للأفضل.
في Ubuntu ، يتم تثبيت openconnect من مدير الحزم.
apt install openconnectبعد التثبيت مباشرة ، يمكنك محاولة الاتصال بشبكة VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com هو عنوان VPN وهمي
poxvuibr - اسم مستخدم وهمي
سيطلب منك openconnect إدخال كلمة مرور ، والتي ، كما أذكرك ، تتكون من جزء ثابت ورمز من Google Authenticator ، ثم سيحاول الاتصال بـ vpn. إذا نجحت ، تهانينا ، يمكنك تخطي الوسط الذي يوجد فيه الكثير من الألم بأمان والانتقال إلى النقطة المتعلقة بعمل openconnect في الخلفية. إذا لم ينجح الأمر ، فيمكنك المتابعة. على الرغم من أنه إذا نجح الأمر عند الاتصال ، على سبيل المثال ، من ضيف شبكة Wi-Fi في العمل ، فمن الممكن أن تبتهج ، ولا يزال الوقت مبكرًا ، يجب أن تحاول تكرار الإجراء من المنزل.
شهادة
مع وجود احتمال كبير ، لن يبدأ شيء ، وسيبدو ناتج فتح الاتصال كما يلي:
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 ، ولكن من ناحية أخرى ، فإن كيفية حل هذه المشكلة واضحة بشكل أساسي.
هنا أرسل لنا الخادم شهادة ، يمكننا من خلالها تحديد أن الاتصال بخادم الشركة الأصلية ، وليس مخادعًا شريرًا ، وهذه الشهادة غير معروفة للنظام. وبالتالي لا يمكنها التحقق مما إذا كان الخادم حقيقيًا أم لا. وهكذا ، فقط في حالة توقفها عن العمل.
من أجل استمرار الاتصال بالخادم ، تحتاج إلى إخباره صراحةً بالشهادة التي يجب أن تأتي من خادم VPN باستخدام مفتاح --servercert
ويمكنك معرفة الشهادة التي أرسلها لنا الخادم مباشرة من خلال الطباعة المفتوحة. من هذه القطعة:
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ربما تعمل الآن ، ثم يمكنك الذهاب إلى النهاية. لكن شخصيًا ، أظهر لي Ubuntu تينًا بهذا الشكل
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/ الخ / 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 ، لا يتم التقاط نظام أسماء النطاقات الخاص بها
- تمر كل حركة المرور عبر vpn ، مما لا يسمح لك بالانتقال إلى الإنترنت
سأخبرك بما يجب فعله الآن ، ولكن أولاً ، القليل من الأتمتة.
الإدخال التلقائي للجزء الثابت من كلمة المرور
الآن ، من المرجح أنك أدخلت كلمة مرورك بالفعل خمس مرات على الأقل ، وقد أتعبك هذا الإجراء كثيرًا بالفعل. أولاً ، لأن كلمة المرور طويلة ، وثانياً ، لأنه عند إدخالها ، يجب أن تلتقي بفترة زمنية محددة
لم يتم تضمين الحل النهائي للمشكلة في المقالة ، ولكن يمكنك التأكد من عدم الحاجة إلى إدخال الجزء الثابت من كلمة المرور عدة مرات.
لنفترض أن الجزء الثابت من كلمة المرور هو fixPassword والجزء من Google Authenticator 567 987. يمكن تمرير كلمة مرور openconnect بالكامل عبر الإدخال القياسي باستخدام الوسيطة --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinيمكنك الآن العودة باستمرار إلى آخر أمر تم إدخاله وتغيير جزء فقط من أداة مصادقة Google هناك.
لا تسمح لك VPN الخاصة بالشركات بالانتقال إلى الإنترنت.
بشكل عام ، ليس من المزعج جدًا أن تضطر إلى استخدام جهاز كمبيوتر منفصل للذهاب إلى habr. يمكن أن يؤدي عدم القدرة على النسخ واللصق باستخدام stackoverfow إلى شل العمل بشكل عام ، لذلك يجب القيام بشيء ما.
تحتاج إلى تنظيمه بطريقة ما بحيث عندما تحتاج إلى الوصول إلى مورد من الشبكة الداخلية ، ينتقل Linux إلى vpn ، وعندما تحتاج إلى الانتقال إلى Habr ، تذهب إلى الإنترنت.
قم بفتح اتصال بعد بدء الاتصال بـ vpn وتأسيسه ، ويقوم بتنفيذ برنامج نصي خاص موجود في / usr / share / vpnc-scripts / vpnc-script. يتم تمرير بعض المتغيرات إلى نص الإدخال ، ويقوم بإعداد vpn. لسوء الحظ ، لم أتمكن من معرفة كيفية فصل تدفقات حركة المرور بين شبكات vpn للشركات وبقية الإنترنت باستخدام برنامج نصي أصلي.
على ما يبدو ، تم تطوير الأداة المساعدة vpn-slice خصيصًا للأشخاص مثلي ، والتي تتيح لك توجيه حركة المرور عبر قناتين دون الرقص باستخدام الدف. حسنًا ، هذا هو ، يجب أن ترقص ، لكن ليس عليك أن تكون شامانًا.
تقطيع حركة المرور باستخدام شريحة vpn
أولاً ، يجب تثبيت vpn-slice ، وسيتعين عليك اكتشافه بنفسك. إذا كانت هناك أسئلة في التعليقات ، فسأكتب منشورًا منفصلاً حول هذا الموضوع. لكن هذا برنامج بيثون عادي ، لذا لا ينبغي أن تكون هناك أية صعوبات. لقد قمت بتثبيت باستخدام virtualenv.
وبعد ذلك ، يجب تطبيق الأداة ، باستخدام مفتاح --script ، مع تحديد openconnect التي تحتاجها لاستخدام 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. أصبح بإمكان Linux الآن الانتقال إلى الإنترنت أو الإنترانت ، اعتمادًا على IP. ولكن لا يزال يتم استخدام DNS غير الخاص بالشركات لحل العنوان.
لا يزال من الممكن أن تظهر المشكلة في هذا النموذج - كل شيء على ما يرام في العمل ، ولكن في المنزل لا يمكنك الوصول إلى موارد الشركة الداخلية إلا عن طريق IP. هذا لأنه عندما تكون متصلاً بشبكة Wi-Fi للشركات ، يتم استخدام 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 تلقائي
وأضيف سطر جديد إلى resolv.conf. باختصار ، تحدد vpn-slice بطريقة ما مكان وجود خادم DNS لشبكة vpn.
نحتاج الآن إلى التأكد من أنه من أجل معرفة عنوان IP لاسم المجال المنتهي بـ evilcorp.com ، ينتقل Linux إلى نظام أسماء النطاقات الخاص بالشركة ، وإذا كان هناك حاجة إلى شيء آخر ، فانتقل إلى العنوان الافتراضي.
لقد بحثت في Google لبعض الوقت واكتشفت أن هذه الوظيفة موجودة في أوبونتو خارج الصندوق. يشير هذا إلى القدرة على استخدام خادم DNS المحلي dnsmasq لحل الأسماء.
بمعنى ، يمكنك التأكد من أن Linux ينتقل دائمًا إلى خادم DNS المحلي لعناوين IP ، والتي بدورها ، بناءً على اسم المجال ، ستبحث عن IP على خادم DNS الخارجي المقابل.
لإدارة كل ما يتعلق بالشبكات واتصالات الشبكة ، يستخدم Ubuntu NetworkManager ، وواجهة المستخدم الرسومية لاختيار ، على سبيل المثال ، اتصالات wifi هي مجرد واجهة لها.
سنحتاج إلى الصعود في تكوينه.
- قم بإنشاء ملف في /etc/NetworkManager/dnsmasq.d/evilcorp
العنوان = /. evilcorp.com/192.168.430.534
لاحظ النقطة قبل evilcorp. يشير إلى dnsmasq أنه يجب البحث عن جميع النطاقات الفرعية لـ evilcorp.com في نظام أسماء النطاقات للشركات.
- أخبر NetworkManager باستخدام dnsmasq لحل الأسماء
يوجد تكوين مدير الشبكة في /etc/NetworkManager/NetworkManager.conf ، وتحتاج إلى إضافة:
[رئيسي] dns = dnsmasq
- أعد تشغيل مدير الشبكة
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. وبالطبع لا يسمح بدخول أي شخص من الشبكة العامة.
لكي يمر Linux عبر 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 إلى الأمر
#!/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 $(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. بدلا من خاتمة
اتضح أنه من الصعب جدًا فهم كيفية العيش بدون شريحة vpn. كان علي أن أقرأ وأستخدم جوجل كثيرًا. لحسن الحظ ، بعد قضاء الكثير من الوقت مع مشكلة ما ، تقرأ الكتيبات الفنية وحتى الرجل مثل الروايات المثيرة.
نتيجة لذلك ، اكتشفت أن vpn-slice ، مثل البرنامج النصي الأصلي ، يعدل جدول التوجيه لفصل الشبكات.
جدول التوجيه
هذا ، ببساطة ، جدول في العمود الأول يحتوي على العنوان الذي يريد Linux الانتقال إليه ، وفي العمود الثاني من خلاله ينتقل محول الشبكة إلى هذا العنوان. في الواقع ، هناك المزيد من الأعمدة ، لكن هذا لا يغير الجوهر.
لعرض جدول التوجيه ، تحتاج إلى تشغيل الأمر 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 ، فأنت بحاجة إلى google ما هو قناع عنوان IP. بعد dev هو اسم المحول لإرسال الرسالة إليه.
صنع Linux محولًا افتراضيًا لـ VPN - tun0. بالنسبة لحركة المرور لجميع العناوين التي تبدأ بـ 192.168 للمرور خلالها ، يكون الخط مسؤولاً
192.168.0.0/16 dev tun0 scope link يمكنك أيضًا إلقاء نظرة على الحالة الحالية لجدول التوجيه باستخدام الأمر الطريق - ن (عناوين IP مجهولة الهوية بذكاء) ينتج عن هذا الأمر شكل مختلف ويتم إهماله عمومًا ، ولكن غالبًا ما يتم العثور على مخرجاته في كتيبات على الإنترنت وتحتاج إلى أن تكون قادرًا على قراءته.
يمكن فهم عنوان IP الخاص بالمسار الذي يجب أن يبدأ به من الجمع بين عمودي الوجهة وجينماس. يتم أخذ تلك الأجزاء من عنوان IP التي تتوافق مع الأرقام 255 في Genmask في الاعتبار ، وتلك التي يوجد بها 0 ليست كذلك. وهذا يعني أن الجمع بين Destination 192.168.0.0 و Genmask 255.255.255.0 يعني أنه إذا كان العنوان يبدأ بـ 192.168.0 ، فسيتم إرسال الطلب إليه على طول هذا المسار. وإذا كانت الوجهة هي 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هناك ، بجانبه ، يتم الإشارة إلى مسار آخر على الفور ، والذي يجب استخدامه إذا كان العنوان الذي يحاول Linux الانتقال إليه لا يتطابق مع أي من الأقنعة الموجودة في الجدول.
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
ولكن لدي أيضًا خادم بريد بالعنوان 555.555.555.555 ، والذي يحتاج أيضًا إلى الوصول إليه عبر vpn. يجب أيضًا إضافة الطريق إليها يدويًا.
ip route add 555.555.555.555 via dev tun0والآن كل شيء طبيعي. لذلك لا يزال بإمكانك الاستغناء عن vpn-slice ، لكنك تحتاج بالفعل إلى معرفة ما تفعله جيدًا. الآن أفكر في الإضافة إلى السطر الأخير من البرنامج النصي الأصلي openconnect لحذف المسار الافتراضي وإضافة مسار لمرسل الإرسال بعد الاتصال بـ vpn ، فقط بحيث يكون هناك عدد أقل من الأجزاء المتحركة في دراجتي.
ربما ، من أجل فهم كيفية إعداد VPN ، ستكون هذه النتيجة النهائية كافية لشخص ما. لكن بينما كنت أحاول فهم ماذا وكيف أفعل ، قرأت الكثير من هذه الكتيبات التي تناسب المؤلف ، ولكن لسبب ما لا تعمل معي وقررت أن أضيف هنا كل القطع التي وجدتها. سأكون سعيدا جدا بشيء من هذا القبيل.
المصدر: www.habr.com