האם אתה רוצה להשתמש בלינוקס בעבודה, אבל ה-VPN הארגוני שלך לא מאפשר לך? אז מאמר זה עשוי לעזור, למרות שזה לא בטוח. אני רוצה להזהיר אותך מראש שאני לא מבין היטב את בעיות ניהול הרשת, אז יכול להיות שעשיתי הכל לא נכון. מצד שני, יתכן שאוכל לכתוב מדריך בצורה כזו שיהיה מובן לאנשים רגילים, אז אני ממליץ לך לנסות אותו.

המאמר מכיל הרבה מידע מיותר, אך ללא הידע הזה לא הייתי מצליח לפתור את הבעיות שצצו לי במפתיע בהקמת VPN. אני חושב שלכל מי שינסה להשתמש במדריך הזה יהיו בעיות שלא היו לי, ואני מקווה שהמידע הנוסף הזה יעזור לפתור את הבעיות הללו בעצמו.

רוב הפקודות המשמשות במדריך זה צריכות להיות מופעלות באמצעות sudo, אשר הוסר לקיצור. זכור.

רוב כתובות ה-IP הוטשו מאוד, כך שאם אתה רואה כתובת כמו 435.435.435.435, חייב להיות שם IP רגיל, ספציפי למקרה שלך.

יש לי אובונטו 18.04, אבל אני חושב שעם שינויים קלים ניתן להחיל את המדריך על הפצות אחרות. עם זאת, בטקסט הזה לינוקס == אובונטו.

Cisco Connect

מי שנמצא ב-Windows או MacOS יכול להתחבר ל-VPN הארגוני שלנו דרך Cisco Connect, שצריך לציין את כתובת השער ובכל פעם שאתה מתחבר, להזין סיסמה המורכבת מחלק קבוע וקוד שנוצר על ידי Google Authenticator.

במקרה של לינוקס, לא הצלחתי להפעיל את Cisco Connect, אבל הצלחתי לחפש בגוגל המלצה להשתמש ב-openconnect, שנעשתה במיוחד כדי להחליף את Cisco Connect.

Openconnect

בתיאוריה, לאובנטו יש ממשק גרפי מיוחד ל-openconnect, אבל זה לא עבד בשבילי. אולי זה לטובה.

באובונטו, openconnect מותקן ממנהל החבילות.

apt install openconnect

מיד לאחר ההתקנה, אתה יכול לנסות להתחבר ל-VPN

openconnect --user poxvuibr vpn.evilcorp.com

vpn.evilcorp.com היא הכתובת של VPN פיקטיבי
poxvuibr - שם משתמש פיקטיבי

openconnect יבקש ממך להזין סיסמה, אשר, להזכירך, מורכבת מחלק קבוע וקוד מ-Google Authenticator, ואז היא תנסה להתחבר ל-vpn. אם זה עובד, כל הכבוד, אפשר לדלג בבטחה על האמצע, שזה כאב רב, ולהמשיך לנקודה של ריצה פתוחה ברקע. אם זה לא עובד, אתה יכול להמשיך. למרות שאם זה עבד בעת חיבור, למשל, מ-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 שלו לא נקלט
• כל התעבורה עוברת דרך VPN, שאינו מאפשר גישה לאינטרנט

אני אגיד לך מה לעשות עכשיו, אבל קודם קצת אוטומציה.

הזנה אוטומטית של החלק הקבוע של הסיסמה

עד עכשיו, סביר להניח שכבר הזנת את הסיסמה שלך לפחות חמש פעמים וההליך הזה כבר עייף אותך. ראשית, כי הסיסמה ארוכה, ושנית, כי בעת הכניסה צריך להתאים לפרק זמן קבוע

הפתרון הסופי לבעיה לא נכלל במאמר, אך ניתן לוודא שאין צורך להזין את החלק הקבוע של הסיסמה פעמים רבות.

נניח שהחלק הקבוע של הסיסמה הוא fixedPassword, והחלק מ-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 ארגוני לא מאפשר לך לגלוש באינטרנט.

באופן כללי, זה לא מאוד לא נוח כשאתה צריך להשתמש במחשב נפרד כדי לעבור אל Habr. חוסר היכולת להעתיק-הדבק מ-stackoverfow יכול בדרך כלל לשתק את העבודה, אז צריך לעשות משהו.

אנחנו צריכים איכשהו לארגן את זה כך שכאשר אתה צריך לגשת למשאב מהרשת הפנימית, לינוקס עוברת ל-VPN, וכאשר אתה צריך ללכת להאבר, היא עוברת לאינטרנט.

openconnect, לאחר הפעלה ויצירת חיבור עם vpn, מבצע סקריפט מיוחד, שנמצא ב- /usr/share/vpnc-scripts/vpnc-script. משתנים מסוימים מועברים לסקריפט כקלט, והוא מגדיר את ה-VPN. לרוע המזל, לא הצלחתי להבין כיצד לפצל את זרימות התעבורה בין VPN ארגוני לשאר האינטרנט באמצעות סקריפט מקורי.

ככל הנראה, כלי השירות vpn-slice פותח במיוחד עבור אנשים כמוני, המאפשר לשלוח תנועה בשני ערוצים מבלי לרקוד עם טמבורין. ובכן, כלומר, אתה תצטרך לרקוד, אבל אתה לא צריך להיות שמאן.

הפרדת תנועה באמצעות vpn-slice

ראשית, תצטרך להתקין vpn-slice, תצטרך להבין זאת בעצמך. אם יש שאלות בתגובות, אכתוב על זה פוסט נפרד. אבל זו תוכנית Python רגילה, אז לא אמורים להיות קשיים. התקנתי באמצעות 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 ישתנה. לינוקס יכולה כעת לגשת לאינטרנט או לאינטראנט, בהתאם ל-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, לינוקס עוברת ל-DNS הארגוני, ואם יש צורך במשהו אחר, אז לברירת המחדל.

חיפשתי בגוגל די הרבה זמן וגיליתי שפונקציונליות כזו זמינה באובונטו מהקופסה. משמעות הדבר היא היכולת להשתמש בשרת ה-DNS המקומי dnsmasq כדי לפתור שמות.

כלומר, אתה יכול לוודא שלינוקס הולך תמיד לשרת ה-DNS המקומי עבור כתובות IP, אשר בתורו, בהתאם לשם הדומיין, יחפש את ה-IP בשרת ה-DNS החיצוני המתאים.

כדי לנהל את כל מה שקשור לרשתות וחיבורי רשת, אובונטו משתמשת ב-NetworkManager, והממשק הגרפי לבחירת, למשל, חיבורי Wi-Fi הוא רק קצה קצה שלו.

נצטרך לטפס בתצורה שלו.

1. צור קובץ ב- /etc/NetworkManager/dnsmasq.d/evilcorp

address=/.evilcorp.com/192.168.430.534

שימו לב לנקודה מול evilcorp. זה מסמן ל-dnsmasq שיש לחפש בכל תת-הדומיינים של evilcorp.com ב-dns הארגוני.

1. אמור ל-NetworkManager להשתמש ב-dnsmasq לפתרון שם

תצורת מנהל הרשת ממוקמת ב- /etc/NetworkManager/NetworkManager.conf אתה צריך להוסיף שם:

[ראשי] dns=dnsmasq

1. הפעל מחדש את NetworkManager

service network-manager restart

כעת, לאחר התחברות ל-VPN באמצעות openconnect ו-vpn-slice, ה-ip ייקבע כרגיל, גם אם לא תוסיף כתובות סמליות לארגומנטים ל-vpnslice.

כיצד לגשת לשירותים בודדים באמצעות VPN

אחרי שהצלחתי להתחבר ל-VPN, שמחתי מאוד במשך יומיים, ואז התברר שאם אני מתחבר ל-VPN מחוץ לרשת המשרדית, אז הדואר לא עובד. הסימפטום מוכר, לא?

הדואר שלנו ממוקם ב-mail.publicevilcorp.com, מה שאומר שהוא לא נופל תחת הכלל ב-dnsmasq וכתובת שרת הדואר מתבצעת באמצעות DNS ציבורי.

ובכן, המשרד עדיין משתמש ב-DNS, שמכיל את הכתובת הזו. זה מה שחשבתי. למעשה, לאחר הוספת השורה ל-dnsmasq

address=/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 דאגו לנו והוסיפו מפתח מיוחד לתוכנית -background, שגורם לתוכנית לעבוד ברקע לאחר ההשקה. אם תפעיל אותו כך, תוכל לסגור את הקונסולה לאחר ההשקה

#!/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 $(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, כמו הסקריפט המקורי, משנה את טבלת הניתוב לרשתות נפרדות.

טבלת ניתוב

במילים פשוטות, זו טבלה בעמודה הראשונה שמכילה מה הכתובת שלינוקס רוצה לעבור בה צריכה להתחיל, ובעמודה השנייה על איזה מתאם רשת לעבור בכתובת הזו. למעשה, יש יותר דוברים, אבל זה לא משנה את המהות.

על מנת לצפות בטבלת הניתוב, עליך להפעיל את הפקודה 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 

אתה יכול גם להסתכל על המצב הנוכחי של טבלת הניתוב באמצעות הפקודה מסלול -נ (כתובות IP עוברות אנונימיות בצורה חכמה) פקודה זו מפיקה תוצאות בצורה שונה ובדרך כלל מבוטלת, אך הפלט שלה נמצא לעתים קרובות במדריכים באינטרנט ואתה צריך להיות מסוגל לקרוא אותו.

היכן אמורה להתחיל כתובת ה-IP של מסלול ניתן להבין מהשילוב של העמודות Destination ו- Genmask. אותם חלקים של כתובת ה-IP התואמים את המספרים 255 ב-Genmask נלקחים בחשבון, אבל אלה שבהם יש 0 לא. כלומר, השילוב של יעד 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-slice

אבל יש לי גם שרת דואר עם הכתובת 555.555.555.555, שגם אליו צריך לגשת דרך VPN. יש להוסיף גם את המסלול אליו באופן ידני.

ip route add 555.555.555.555 via dev tun0

ועכשיו הכל בסדר. אז אתה יכול להסתדר בלי vpn-slice, אבל אתה צריך לדעת היטב מה אתה עושה. עכשיו אני חושב להוסיף לשורה האחרונה של הסקריפט המקורי של openconnect את הסרת מסלול ברירת המחדל ולהוסיף מסלול עבור הדואר לאחר התחברות ל-vpn, רק כדי שיהיו פחות חלקים נעים באופניים שלי.

ככל הנראה, המאמר הבא הזה יספיק כדי שמישהו יבין כיצד להגדיר VPN. אבל בזמן שניסיתי להבין מה ואיך לעשות, קראתי די הרבה מדריכים כאלה שעובדים עבור המחבר, אבל משום מה לא עובדים בשבילי, והחלטתי להוסיף כאן את כל הקטעים שמצאתי. הייתי מאוד שמח על דבר כזה.

מקור: www.habr.com