هل تريد استخدام Linux في العمل ، لكن VPN للشركات لا؟ ثم قد تساعد هذه المقالة ، على الرغم من أن هذه ليست دقيقة. أريد أن أحذر مقدمًا من أنني أفهم مشكلات إدارة الشبكة بشكل سيء ، لذلك من الممكن أن أفعل كل شيء خطأ. من ناحية أخرى ، من الممكن أن أتمكن من كتابة الدليل بطريقة تكون مفهومة للناس العاديين ، لذلك أنصحك بتجربته.
تحتوي المقالة على الكثير من المعلومات الإضافية ، لكن بدون هذه المعرفة لن أتمكن من حل المشكلات التي واجهتها فجأة في إعداد VPN. أعتقد أن أي شخص يحاول تطبيق هذا الدليل سيواجه مشاكل لم أواجهها ، وآمل أن تساعد هذه المعلومات الإضافية في حل هذه المشكلات بمفردي.
معظم الأوامر المستخدمة في الدليل تحتاج إلى تشغيلها من خلال sudo ، والتي تتم إزالتها من أجل الإيجاز. ضع في اعتبارك
تم تشويه معظم عناوين IP بشدة ، لذا إذا رأيت عنوانًا مثل 435.435.435.435 ، فيجب أن يكون هناك بعض عناوين IP العادية الخاصة بحالتك.
لدي أوبونتو 18.04 ، لكنني أعتقد أنه مع بعض التغييرات ، يمكن تطبيق الدليل على توزيعات أخرى. ومع ذلك ، في هذا النص ، لينكس == أوبونتو.
سيسكو الاتصال
يمكن لأولئك الذين يجلسون على نظام Windows أو MacOS الاتصال بشبكة VPN الخاصة بشركتنا من خلال Cisco Connect ، والتي تحتاج إلى تحديد عنوان بوابة وإدخال كلمة مرور في كل مرة يتصلون بها ، والتي تتكون من جزء ثابت ورمز تم إنشاؤه بواسطة Google Authenticator.
في حالة نظام Linux ، لم يكن من الممكن الحصول على Cisco Connect ، ولكن اتضح لـ google التوصية باستخدام openconnect ، المصممة خصيصًا ليحل محل Cisco Connect.
Openconnect
من الناحية النظرية ، يوجد في ubunt واجهة رسومية خاصة بـ openconnect لكنها لم تنجح بالنسبة لي. ربما يكون للأفضل.
في ubunt ، يتم تثبيت openconnect من مدير الحزم.
apt install openconnect
مباشرة بعد التثبيت ، يمكنك محاولة الاتصال بشبكة VPN
openconnect --user poxvuibr vpn.evilcorp.com
vpn.evilcorp.com هو عنوان VPN الوهمي \
poxvuibr - اسم المستخدم الوهمي
سيطلب منك openconnect إدخال كلمة مرور ، والتي ، على ما أذكر ، تتكون من جزء ثابت ورمز من Google Authenticator ، ثم يحاول الاتصال بـ vpn. إذا ظهر الأمر ، تهانينا ، فيمكنك تخطي الوسط بأمان ، وهو ما يسبب الكثير من الألم والانتقال إلى نقطة اتصال openconnect في الخلفية. إذا لم ينجح ذلك ، فيمكنك المتابعة. على الرغم من أنه قد تم إيقافه عند الاتصال ، على سبيل المثال ، من ضيف شبكة Wi-Fi في العمل ، فمن الممكن أن نفرح مبكراً ، يجب عليك محاولة تكرار الإجراء من المنزل.
شهادة
مع احتمال كبير ، لن يبدأ أي شيء ، وسيظهر عادم 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 بالخادم ، يجب أن تخبره صراحةً بالشهادة التي يجب أن تأتي من خادم VPN باستخدام مفتاح --servercert
ويمكنك معرفة الشهادة التي أرسلها الخادم إلينا مباشرةً من خلال ما طبعه 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 الخاص به
- تمر كل حركة المرور عبر الشبكات الافتراضية الخاصة ، والتي لا تسمح لك بالوصول إلى الإنترنت
ما سأفعله الآن سوف أخبركم به ، ولكنني أتمنى أولاً بعض الشيء.
الإدخال التلقائي للجزء الثابت من كلمة المرور
في الوقت الحالي ، من المحتمل أن تكون قد أدخلت كلمة المرور بالفعل خمس مرات على الأقل وأن هذا الإجراء قد أصابك بالتعب بالفعل. أولاً ، نظرًا لأن كلمة المرور طويلة ، وثانياً ، لأنه عند الدخول ، تحتاج إلى الاحتفاظ بها خلال فترة زمنية محددة
لم يتم تضمين الحل النهائي للمشكلة في المقالة ، ولكن يمكن القيام به بحيث لا يلزم إدخال الجزء الثابت من كلمة المرور عدة مرات.
افترض أن الجزء الثابت من كلمة المرور هو fixPassword ، وجزء من Google Authenticator 567 987. يمكن تمرير كلمة مرور openconnect بأكملها من خلال الإدخال القياسي باستخدام الوسيطة --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdin
يمكنك الآن الرجوع باستمرار إلى آخر أمر تم إدخاله وتغيير جزء فقط من Google Authenticator هناك.
VPN الشركات لا تسمح بالوصول إلى الإنترنت.
بشكل عام ، ليس من المريح جدًا عند استخدام جهاز كمبيوتر منفصل الانتقال إلى لوحة وصل. يمكن لنقص القدرة على النسخ واللصق باستخدام stackoverfow أن يشل العمل عمومًا ، لذلك يجب القيام بشيء ما.
من الضروري التنظيم بطريقة أو بأخرى ، لذلك عندما تحتاج إلى الانتقال إلى المورد من الشبكة الداخلية ، ينتقل Linux إلى vpn ، وعندما تحتاج إلى الانتقال إلى المحور ، فإنه ينتقل إلى الإنترنت.
يقوم openconnect بعد بدء وتأسيس اتصال بـ vpn ، بتنفيذ برنامج نصي خاص ، والذي يقع في / usr / share / vpnc-scripts / vpnc-script. يتم نقل بعض المتغيرات إلى البرنامج النصي للإدخال ، ويقوم بتكوين 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
في - البرنامج النصي ، يتم تمرير سطر بالأمر الذي يحتاج إلى استدعاء بدلاً من البرنامج النصي. ./bin/vpn-slice - المسار إلى الملف القابل للتنفيذ vpn-slice 192.168.430.0/24 - قناع العناوين التي يجب زيارتها في vpn. أعني هنا أنه إذا كان العنوان يبدأ بـ 192.168.430 ، فيجب البحث عن المورد بهذا العنوان داخل VPN
الآن يجب أن يكون الوضع طبيعيًا تقريبًا. تقريبا. يمكنك الآن تسجيل الدخول إلى لوحة الوصل ويمكنك تسجيل الدخول إلى مورد الشركة الداخلي عبر بروتوكول الإنترنت ، ولكن لا يمكنك تسجيل الدخول إلى مورد الشركة الداخلي بالاسم الرمزي. إذا قمت بتسجيل مراسلات الاسم والعنوان الرمزي في المضيفين ، فيجب أن يعمل كل شيء. والعمل حتى يتغير الملكية الفكرية. أصبح Linux الآن قادرًا على الانتقال إلى الإنترنت أو إلى شبكة الشركة ، اعتمادًا على ip. ولكن لا يزال يستخدم DNS غير الشركات لتحديد العنوان.
لا تزال المشكلة واضحة في هذا النموذج - كل شيء على ما يرام في العمل ، وفي المنزل لا يمكنك الوصول إلى موارد الشركة الداخلية إلا عن طريق بروتوكول الإنترنت. هذا لأنه عندما تكون متصلاً بشبكة Wi-Fi للشركات ، يتم أيضًا استخدام DNS الخاص بالشركات ، وفيه يتم تحديد العناوين الرمزية من VPN ، على الرغم من أنه لا يزال من المستحيل الانتقال إلى هذا العنوان دون استخدام VPN.
التعديل التلقائي لملف المضيفين
إذا كنت تطلب بأدب vpn-slice ، فبعد رفع VPN ، يمكنه الانتقال إلى DNS الخاص به ، والعثور على عناوين IP للموارد الضرورية هناك بأسمائها الرمزية وإدخالها في المضيفين. بعد إيقاف تشغيل VPN ، ستتم إزالة هذه العناوين من الأجهزة المضيفة. للقيام بذلك ، قم بتمرير الأسماء الرمزية إلى شريحة vpn كوسائط. ها أنت ذا.
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 ، وهذا هو اسم أحد حوامل الاختبار.
ولكن الآن بعد أن أصبح لدينا القليل من الفهم لماذا يمكن القضاء على هذه الحاجة.
إذا نظرت إلى / etc / hosts ، بعد رفع VPN ، يمكنك أن ترى ، هنا سطر
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
نعم ، وتمت إضافة سطر جديد إلى solutionv.conf. باختصار ، تم تحديد vpn-slice بطريقة ما حيث يوجد خادم dns لـ vpn.
نحتاج الآن إلى التأكد من أنه من أجل معرفة عنوان IP لاسم النطاق الذي ينتهي على evilcorp.com ، ذهب Linux إلى نظام أسماء نطاقات الشركات ، وإذا كان هناك حاجة إلى شيء آخر ، ثم الافتراضي.
لقد غوغل لفترة طويلة ووجدت أن هذه الوظيفة في أوبونت من خارج منطقة الجزاء. يشير هذا إلى القدرة على استخدام خادم dns dnsmasq المحلي لحل الأسماء.
وهذا يعني أنه يمكنك جعل Linux دائمًا يذهب إلى خادم نظام أسماء النطاقات المحلي لعناوين بروتوكول الإنترنت ، والذي بدوره ، بناءً على اسم المجال ، سيبحث عن عنوان IP على خادم نظام أسماء النطاقات الخارجي المقابل.
لإدارة كل ما يتعلق بالشبكات واتصالات الشبكة ، يستخدم Ubunt NetworkManager ، والواجهة الرسومية لاختيار ، على سبيل المثال ، اتصال Wi-Fi هو فقط الواجهة له.
سنحتاج إلى الصعود في التكوين الخاص به.
- قم بإنشاء ملف في /etc/NetworkManager/dnsmasq.d/evilcorp
العنوان = /. evilcorp.com/192.168.430.534
إيلاء الاهتمام لهذه النقطة قبل evilcorp. يشير dnsmasq إلى أنه يجب البحث عن كافة النطاقات الفرعية evilcorp.com في نظام أسماء النطاقات للشركات.
- أخبر NetworkManager لاستخدام dnsmasq لحل الأسماء
يوجد تكوين مدير الشبكة في /etc/NetworkManager/NetworkManager.conf تحتاج إلى إضافة هناك:
[الرئيسية]
dns = dnsmasq
- أعد تشغيل NetworkManager
service network-manager restart
الآن ، بعد الاتصال بشبكة VPN باستخدام مجموعة من openconnect و vpn-slice ، سيتم اكتشاف الملكية الفكرية بشكل طبيعي حتى إذا لم تقم بإضافة عناوين رمزية إلى الوسائط إلى vpnslice.
كيف تذهب من خلال VPN لفصل الخدمات
بعد أن اتضح لي أن أتصل بـ vpn ، كنت سعيدًا جدًا لمدة يومين ، ثم اتضح أنه إذا كنت تتصل بـ VPN وليس من شبكة المكتب ، فلن يعمل البريد. أعراض مألوفة ، أليس كذلك؟
البريد الخاص بنا موجود في mail.publicevilcorp.com ، مما يعني أنه لا يندرج تحت القاعدة في dnsmasq ويتم البحث في عنوان خادم البريد من خلال DNS العام.
حسنًا ، لا يزال المكتب يستخدم DNS الذي يوجد به هذا العنوان. هذا هو ، اعتقدت ذلك. في الواقع ، بعد إضافة خط إلى dnsmasq
العنوان = / mail.publicevilcorp.com / 192.168.430.534
الوضع لم يتغير. بقي IP نفسه. اضطررت للذهاب إلى العمل.
وعندها فقط ، عندما بحثت في الموقف وحللت المشكلة قليلاً ، أخبرني شخص ذكي كيف يمكنني حلها. كان من الضروري الاتصال بخادم البريد ليس فقط من هذا القبيل ، ولكن من خلال الشبكات الافتراضية الخاصة
أستخدم 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
إذا وضعت البرنامج النصي في الاتصال ~ 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 ، والذي يمكنك من خلاله إرشاد 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 ، مثل النص الأصلي ، تعدّل جدول التوجيه لفصل الشبكات.
جدول التوجيه
بعبارات بسيطة ، مثل هذا الجدول في العمود الأول الذي يحتوي على المكان الذي يجب أن يبدأ فيه العنوان الذي يجب أن يعمل عليه 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 هو اسم المحول الذي يجب إرسال الرسالة إليه.
بالنسبة إلى VPN ، قام Linux بعمل محول افتراضي - tun0. وللحصول على حركة مرور جميع العناوين التي تبدأ بـ 192.168 ، يجيب السطر
192.168.0.0/16 dev tun0 scope link
يمكنك أيضًا الاطلاع على الحالة الحالية لجدول التوجيه باستخدام الأمر route -n (عناوين بروتوكول الإنترنت هي موهوبة بشكل مجهول) ينتج هذا الأمر النتائج في شكل مختلف ويتم إهماله عمومًا ، لكن العادم الخاص به غالبًا ما يكون عبر أدلة الإنترنت ويحتاج إلى قراءته.
حيث يمكن فهم عنوان IP للمسار من خلال الجمع بين أعمدة الوجهة و Genmask. يتم أخذ تلك الأجزاء من عنوان IP التي تتطابق معها الأرقام 255 في Genmask في الاعتبار ، وتلك الأجزاء التي لا توجد فيها. أي أن الجمع بين 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 أصبح الأمر كذلك
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 مثل هذا
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 ، لكنك بحاجة بالفعل إلى معرفة ما تفعله جيدًا. أفكر الآن في إضافة إزالة المسار الافتراضي وإضافة المسار إلى مرسل البريد بعد الاتصال بـ vpn إلى السطر الأخير من البرنامج النصي الأصلي openconnect ، فقط لتقليل عدد الأجزاء المتحركة في دراجتي.
من المحتمل أن يكون لدى شخص ما لفهم كيفية تكوين VPN ما يكفي من هذه النتيجة النهائية. لكن بينما كنت أحاول أن أفهم ماذا وكيف أفعل ذلك ، قرأت الكثير من الأدلة التي تعمل لصالح المؤلف ، لكن لسبب ما لا تعمل من أجلي وقررت أن أضيف هنا جميع المقالات التي وجدتها. سأكون سعيدًا جدًا بشيء من هذا القبيل.