מכונה וירטואלית לשם התחברות ל sonicwall

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

הנתב איפשר שני אפשרויות חיבור חיבור באמצעות l2tp וחיבור באמצעות לקוח קנייני מסוג sslvpn שנקרא netExtender.

בדקתי את הגדרות ההתחברות של השרת ע"י sudo ike-scan vpn.domain.net וניסתי להשתמש בתוצאות שקיבלתי בשביל להתחבר לVPN. לאחר כחצי שעה של ניסונות התחברות שכשלו (גם לאחר שינויים של שרון במערכת) וההבנה שלי שבוינדוס זה עובד חלק הרמתי ידיי מ l2tp והלכתי על הפתרון הקנייני. הפתרון הקנייני הוא תוכנה מיוחדת למערכת הSonicWall. 

ממה שאני הצלחתי להבין זוהיא מעטפת שמשתמשת בppp וממשת מערכת הצפנה (TLS) ב java.

 

תוכנת הלקוח שאיתה היה צריך להתחבר נקראת NetExtender ואת ההתקנה שלה ניתן להוריד מהנתב עליו מותקן SonicWall עצמו. התוכנה איננה תוכנה חופשית ואפילו לא קוד פתוח. ניתן להוריד גרסאות חדשות/ ישנות יותר מאתר SonicWall עצמו.

המסלול להורדה אצלי היה https://vpn.domain.net:4433/NetExtender64.tgz הפורט אצלכם יכול להיות שיהיה שונה. הייתרון בלמשוך את הלקוח ישר מהנתב הוא שיש סיכויי גבוהה יותר שלא יהיו בעיות של אי התאמת גרסת לקוח לגרסת השרת אבל אם אין ברירה אפשר ללכת לאתר sonicwall ולהוריד משם.

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

 

התקנה תחת docker או התקנה תחת qemu. אני בחרתי להשתמש ב qemu שיפעיל debian תקני.

את הVM אני מנהל על ידי libvirtd (שזה סביבת הוירטואליזציה ברירת המחדל בהפצה שלי).

 

בשביל להפעיל את המכונה הוירטואלית אני משתמש בvirsh למכונה קראתי workvpn: 

virsh  -c qemu:///system start vpn

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

לאחר פריסת קבצי ההתקנה , יצרתי קובץ הגדרות עבור systemd שייבצע התחברות לאחר הפעלה : 

cat /etc/systemd/system/netextender.service 
[Unit]
Description=netExtender SSL VPN
After=network-online.target
Wants=network-online.target
StartLimitIntervalSec=5s
StartLimitBurst=10

[Service]
RemainAfterExit=yes
ExecStart= screen -Dm /bin/bash -c \
      "echo Y |  /home/user/netExtender -u myvpnusername -p verylongandstrongpassword -s vpn.domain.net:vpnport -d domain.net -M 500"
User=user
Group=user
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

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

 

אני גם לא התקנתי את netExtender כרוט על המכונה ולכן אני מעביר את שם המשתמש איתו לפתוח את את הבינארי ולהפעיל.

 

השימוש שלי בscreen נועד לא "לתקוע" את עליית systemd אלא לתת לו לפתוח תהליך בן שיעשה את העבודה ושיאפשר לי להתחבר ללקוח הvpn במקרה של תקלה.

 

השימוש  שלי ב restart נועד שבמקרה נפילה הוא ייתחבר מחדש.

 

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

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

את החיבור אני עשה באמצעות שימוש ב brdige מכיוון שזה נוח יותר לצורת העבודה במקרה שלי.

מתארח באתר בו יש נתב מספק האינטרנט ? תחזיק שרת DNS משלך

יש לך נתב/ מודם המסופק ע"י ספק האינטרנט ולא החלפת סיסמאות - צא מנקודת ההנחה שיש לך maleware על הנתב.

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

אם לא פיספסתם היתה מתקפה על נתבי D-Link לפני מספר שבועות ( DnsChanger ), זה ביחד עם זה שנתבים המסופקים ע"י ספקי האינטרנט מכילים הגדרות ברירת מחדל להתחברות, יכול לעשות 1+1 ולהבין שככל הנראה נראה בקרוב מתקפות מתוך הנתבים האלה. אני לא מאמין שמרבית הלקוחות יחסמו את כל המשתמשים שהוגדרו בנתבים שסופקו להם.

היום אני אישית מחזיק שרת DNS משלי, שלדאבוני אינו מוגדר לעבודה אל מול dnscrypt עדיין, הסיבה העיקרית שלא הגדרתי dnscrypt + bind9 היא עצלנות נטו.

מה שצריך לעשות זה:

להתקין dnssec resolver 
להתקין dnscrypt ולהגדיר את proxy_resolver_name למשהוא שיהיה נגיש (תחת /etc/default/dnscrypt-proxy)

ולחכות ליום בו הספקים המקומיים יתחילו לתמוך ב dnssec.

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

צרות עם openvpn כאשר יש מכשיר אנדרויד ללא רוט

אחד המכשירים שמתחבר לענני הוא מכשיר שלא עבר rooting מה שאומר כי אני נאלץ להשתמש בלקוח openvpn ללא יכולת tap.

אז ישבתי והגדרתי במשך כ 5 דקות שלמות שרת openvpn כמו בדר"כ רק ע"י החלפה לשימוש ב tun במקום tap וההגדרה הראשונית נראתה כך :

port 1194
proto tcp
dev tun
ca   /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
crl-verify /etc/openvpn/easy-rsa/keys/crl.pem
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

server 192.168.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 192.168.0.1"

client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 4
mute 20
script-security 2

צורת העבודה הזאת מאפשרת dhcp ע"ג tun ועובדת בדביאן ווינדוס, כאשר ניסיתי להשתמש בהגדרות צד לקוח קיבלתי הודעה קריפטית לגבי dresses are not in the same /30 subnet (topology net30 מה שלכעצמו מוזר כי הכתובת שצריכה אמורה לעבור דרך dhcp. כמה שחיפשתי לא הצלחתי למצוא פתרון פרט ללספק כתובת (מאותו המרחב באמצעות שימוש בcient-config-dir ושם הגדרה של כתובת קבועה עבורו).

port 1194
proto tcp
dev tun
ca   /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
crl-verify /etc/openvpn/easy-rsa/keys/crl.pem
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

server 192.168.0.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 192.168.0.1"

client-config-dir ccd
route 192.168.0.0 255.255.255.252

client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 4
mute 20
script-security 2

לאחר מכאן יש ליצור תיקיית ccd ובתוכה שם כמו שהשתמשת בעת ייצרת certificate עבור הלקוח.

ענני

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

המערכת בנוייה בצורה הבאה :

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

שירותי ה DNS שבתוך שרת ה openvpn ניתנים ע"י bind9, שירותי הדואל מסופקים ע"י dovecot ו exim4 היומן ואנשי הקשר מסופקים ע"י ownloud.

בשביל ה SSL יצרתי לעצמי CA אישי וחתמתי על האישורים ע"י ה CA הזה , לאחר מכן התקנתי את האישור בכל אחד מהמכשירים שצריכים להתחבר (הנה מדריך מצויין).

שירותי ההזדהות של exim משתמשים ב SASL (בחרתי ב SASL כי אני רוצה לחבר גם ejabbered לסביבה וזה יקל עלי את החיים לאחר מכאן) (מדריך כאן).

בגלל שבחרתי לעבוד עם משתמשים אמיתיים (ולא וירטואליים) נכון לרגע זה , הדבר מאפשר שכל משתמש מכיל את האפשרות לקבל את כל המיילים שלו מגימייל לשירות המייל הפנימי ע"י הגדרה אישית מולו.

פעולה זו מתבצעת ע"י fetchmail + cron , יש ליצור הגדרה עבור כל משתמש שרוצה את העבודה בצורה הבאה :

usera@sinta:~$ cat .fetchmailrc

poll pop.gmail.com with proto POP3 and options no dns port 995 user gmailuser@gmail.com there with password gmailpassword is usera here options ssl

לאחר מכאן ביצוע crontab -e מתוך המשתמש בשביל להוסיף את fetchmail -vk.

לאחר מכן לקוח אנדרויד יכול למשוך את ההודעות ע"י שימוש ב K9 ולגשת לממשק המשתמש ע"י הדפדפן האוהב עליו.

להפתעתי גיליתי של firefox 35 שמסופק ע"י f-droid יש בעייה בעבודה עם שירות ה dns שנדחף ע"י openvpn בגלל באג פתוח עד 35 כולל, בגירסה 36 זה קורה פחות אבל זה היה פשוט מטמטם הבטיחו לתקן ב 37 נחייה ונראה.

עבור המערכת שתספק אנשי הקשר והיומן בחרתי ב owncloud במקום ב kolab או citadel ללא שום סיבה מיוחדת.בדרך גיליתי עד כמה ממשק המשתמש של owncloud איטי ועקום לטעמי, אבל שאר המערכות נראות כמתפקדות ללא שום בעייה ייתכן וזה קשור לעובדה שכל זה רץ מתוך רסבריי פי.

לדוגמה ייבוא יומנים מ ICS  - הדרך לייבא היא העלאה של הקובץ ולאחר מכאן (דרך ממשק משתמש) ללחוץ עליו ורק אז תשאל לאן תרצה לייבא את היומן.

עיגון תיקיות ה webdav ככונן משותף עבד חלק בדביאן, בוינדוס 7 ובאנדרואיד השתמשתי באפליקציה (הצולעת לטעמי) owncloud.

השלב הבא בבנייה (שאותה לא עשיתי עדיין) הוא הרמה של slapd וכיוון של כלל המערכות לעבוד מולו, אני חושב שזה עדיף בשביל הזיהוי מאשר עבודה מול טבלאות בשרת דואל (כך גם אין לי vendor lock מעצבן כמו שיש ב KDE). בניית סביבת ejabbered ועוד.

רכיב הtap ב OpenVpn מקבל כתובת MAC חדשה בכל חיבור

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

התיקון הוא ביצוע בקשות release מהמחשב שלך ושמירה על כתובת mac זהה עבור כל חיבור חדש.

dhclient -r tap0 ישחרר את הכתובת הנוכחית, לצערי לא מצאתי איך אני שולח DHCP Release באמצעות nc (או כל חבר אחר) לביצוע שיחרור מסיבי של כתובות שהיו בשימוש (הבעיה היא שצריך גם לנחש את כתובת הmac שהיתה בשימוש בחיבור ישן).

בקובץ שמגדיר את החיבור בopenvpn הוסיפו קישור לתסריט שישנה את ה mac למשהוא קבוע:

user@pc:~$diff old.ovpn new.ovpn 

24a25,26                                                                                                                                                                            
> up "changemac.sh"                                                                                                                > script-security 2
> script-security 2

user@pc:~$cat changemac.sh

#!/bin/bash
ifconfig $1 hw ether 11:11:11:11:11:11 

פעולה זו תגדיר את הmac בכל עלייה עבור כל ממשק רשת חדש שיווצר ע"י חיבור  ה ovpn.