תוכן העניינים

שלמי-תודה

הגרסה המקורית של המדריך התבססה בחלקה על ניסיוני וניסיונותי, ובחלקה על שני מדריכים קודמים:

  1. מדריך ה-Cables-DHCP-PPTP HOWTO מאת אמיר טל (Whatsup) ומאיר קריהלי (MKsoft מערכות).
  2. מדריך החיבור לאינטרנט בכבלים של L3ECH עבור משתמשי לינוקס ישראליים.

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

מבוא

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

"לקוח יקר,

(בלה בלה בלה) בקרוב יועברו כל לקוחות אינטרנט זהב המחוברים דרך 'מתב' לשימוש בחייגן (קרי: חיבור באמצעות VPN) מעבר זה מבוצע מסיבות של (החזיקי חזק, כן כן זה עומד לבוא אלייך!) אבטחת מידע ושימוש אתי באינטרנט. החייגן יאפשר לך ליהנות מרמה גבוהה יותר של שירות ותמיכה, ושירותי אינטרנט מתקדמים. החל ב-12 בינואר 2003, לא יהיה עוד אפשרי להתחבר לאינטרנט בלא שימוש בחייגן (קרי: בלא שתגלה באורח קסום כיצד להתחבר ל-VPN/ים שלנו) בלה בלה בלה, בכבוד רב וכו' וכו'.

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

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

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

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

ובכן, ספקי הגישה החליטו שהם לא אוהבים את השיטה הזו, משלוש סיבות:

  1. ספק הגישה לא יכול לדעת האם את מחוברת באופן פעיל אם לאו, אלא באמצעות רחרוח של החבילות שאת שולחת - פעולה אשר מסיבה כלשהיא אנשי התמיכה הטכנית לא מסוגלים לבצע היטב.
  2. ספק הגישה 'מאבד' את נתח הכתובות שהקצה למשתמשות כבלים, ואינו יכול לנצל את אותן כתובות אשר אינן בשימוש ברגע נתון ללקוחות או לשימושים אחרים.
  3. משום שספק הגישה אינו הגורם המבצע את שירות ה-DHCP, הוא אינו מסוגל לקשר את תעבורת-הרשת שלך, איתך עצמך - כן ילדודס, החיבור האל-VPNי שלכם מקנה לכם אנונימיות חלקית (לפחות עד שספק הגישה מקבל את הרישומות מספק הכבלים, מה שהינו אפשרי, אך אולי לא מיידי כל-כך; אולי אפילו יידרש לשם כך צו בית משפט, אם כי מניסיון יחסה של מערכת המשפט הישראלית בעבר לא הייתי מפתח ציפיות)

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

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

PPTP‏, L2TP ו-PPPoE

PPTP פירושו Point-to-Point Tunneling Protocol - פרוטוקול מנהור נקודה-לנקודה (נל"נ). זהו פרוטוקול בבעלות פרטית שפותח בידי מיקרוסופט. הנה כמה קישורי PPTP:‏
http://pptpclient.sourceforge.net/
קבצי הרצה של לקוח ה-PPTP ללינוקס, כמו גם תיעוד רב על לקוח זה; חלק ממנו הוא די מבלבל, כמו למשל החלק העוסק ב-MPPE ומה בדיוק אמורים לעשות כדי שזה יעבוד. למעשה אני לא חושב שעניין ה-MPPE הזה צריך לעניין אותך בכלל.
http://pptpclient.sourceforge.net/diagrams.phtml
תיאור גרפי נחמד של איך 'נראה' חיבור PPTP.

L2TP פירושו Layer 2 Tunneling Protocol - פרוטוקול מנהור ברמה 2. פרוטוקול זה הינו פתוח, אך יישומו בלינוקס נמצא עדיין בשלב מוקדם. זהו מדריך PPTP, לא L2TP, אבל אם את מוכנה להסתכן ולנסות לכונן חיבור VPN באמצעות L2TP, הנה עצה עבורך (הדברים מכוונים לבעלות הידע הרחב יותר):

שלא כמו לקוח ה-PPTP הזמין, עבורו ניתן לגרום לתהליך-הרקע (daemon) של הנל"נ להריץ את לקוח ה-PPTP כמסייע, לא ניתן לעשות כן עם l2tpd, לכן תצטרכי לגרום לתהליך-הרקע של L2TP להריץ את תהליך-הרקע של הנל"נ. עדיין תזדקקי לקובץ אפשרויות נל"נ וקובץ pap-secrets, עליהם תמצאי מידע מועיל להלן, אך ישנו קובץ הגדרות אחר, נפרד, עבור l2tpd. זאת ועוד, l2tpd הוא מוכוון-ריבוי-חיבורים, וכך לא תוכלי להתחבר סתם באמצעות ההגדרות הסטאטיות - l2tpd נשלט באמצעות צינור בעל-שם (named pipe): /var/run/l2tpd-control (תוכלי למצוא זאת בתיעוד, למרות שהוא מאוד קריפטי). פירוש הדבר הוא שכנראה תרצי להפעיל את l2tpd בעליית המחשב, באופן בלתי-תלוי בכוונתך או אי-כוונתך להתחבר, ואז לשנות את תסריטי ה-pon וה-poff לבדוק האם החיבור שמועבר להם הוא חיבור L2TP, כאשר במקרה זה במקום לנסות להריץ את pppd הם יהדהדו (יעשו echo) את הודעת הבקרה המתאימה לצינור הבקרה של תהליך-הרקע של L2TP. תצטרכי לבדוק גם האם ה-pppd אותו מריץ l2tpd מבצע גם את תסריטי ip-up.d/ עם התחברותו (שוב, ראי פרטים להלן).

כמה קישורי L2TP:

http://www.l2tpd.org/
דף-הבית של לקוח L2TP על לינוקס
http://sourceforge.net/projects/l2tpd
דף SourceForce עבור אותו לקוח/תהליך-רקע
ftp://ftp.isi.edu/in-notes/rfc2661.txt
ה-RFC של L2TP (הגדרה רשמית של הפרוטוקול)
http://mia.ece.uic.edu/~papers/volans/l2tpd.html
סקירה מפורטת של כינון רשת VPN (לא חיבור VPN לרשת קיימת) המבוססת על L2TP
http://www.l3ech.net/~l3ech/cables_linux_l2tp.php
המדריך של l3ech לכינון חיבור VPN באמצעות L2TP לספק שלך; בלתי-אלגנטי, בשל התכנון הנוכחי הלוקה-בחסר של לקוח ה-L2TP
PPPoE פירושו Point to Point Protocol over Ethernet - נל"נ על-גבי אתרנט. זהו עוד סוג של VPN המשלב שני פרוטוקולים/מערכי-פרוטוקולים ידועים-היטב, נל"נ ואתרנט. כמה קישורי PPPoE:
http://www.suse.de/~bk/PPPoE-project.html
'כל העולם' של PPPoE על לינוקס
http://www.carricksolutions.com/pppoe.php
קובץ שאלות נפוצות על PPPoE
www.roaringpenguin.com/pppoe/
לקוח ה-PPPoE 'הפינגוין השואג'
http://www.penguin.org.il/guides/linux-pppoe-rh
מדריך בעברית לשימוש ב-PPPoE באמצעות הממשק הגרפי של RedHat, מאת יריב גראף

VPNים אצל ספקי הגישה הישראליים

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

http://www.mulix.org/adsl-howto.txt
מדריך HOWTO מאיר-עיניים על נושאי ADSL, הן בחומרה הן בתוכנה, ובו מככב נושא ה-PPTP
http://www.adsl.org.il/
אתר מוכוון-חלונות למשתמשי ADSL בישראל

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

http://www.cables.org.il/
אתר מוכוון-חלונות עבור משתמשי אינטרנט בכבלים בישראל
http://www.matav.co.il/
מתב, ספקית תשתית גישת כבלים
http://www.aztv.co.il/
ערוצי זהב, ספקית תשתית גישת כבלים
http://www.tevel.co.il/
תבל, ספקית תשתית גישת כבלים
http://www.whatsup.org.il/doc/CABLES-DHCP-PPTP-HOWTO.html
ה-HOWTO של אמיר טל, הבסיס החלקי למסמך זה

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

הערה: בעבר, לקוח ה-PPTP הרשמי לא תמך בכמה מוזרויות של ציוד התקשורת של 'בזק', וגרסה מותאמת ל-'בזק' נוצרה ע"י מולי בן-יהודה מ-mulix.org; עתה אין עוד צורך להשתמש בה, אפילו ל-ADSL (ראי ה-ADSL-HOWTO), וכנראה שאף פעם לא היה בכך צורך עבור ממשק הכבלים. רק למקרה שתהית במה מדובר.

"אז מה אנחנו רוצות, PPTP‏, L2TP או PPPoE?"

תשובה קצרה: בכל הנוגע למשתמשות לינוקס אשר אינן חשות צורך לעבור על קוד המקור של l2tpd בניסיון לגרוק tap'ים של חיבורים לשער-תקשורת-L2TP, האפשרות המועדפת היא PPTP.

תשובה ארוכה: חלק מספקי הגישה משתמשים הן ב-L2TP הן ב-PPTP; אנשי תמיכה טכנית רומזים כי הם תומכים ב-PPTP רק כדי לאפשר לאנשים בעלי מערכות הפעלה ישנות יותר (כמו חלונות 95 או 98) להתחבר. הנה כי כן משתמשים חייגניהם עבור חלונות 95/98 ב-PPTP, והחייגנים עבור חלונות 2000/XP משתמשים ב-L2TP. ניסיתי מספר ניסיונות לא מוצלחים לכונן חיבור L2TP; אם את מעוניינת לעבוד על הבעייה הזו - נהדר! פרסמי את תוצאותיך במקום בו נוכל כולנו לראותן.

דרישות-קדם לכינון חיבור PPTP מעל כבלים

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

היכרות בסיסית עם לינוקס

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

מערכת לינוקס פועלת ומאולפת

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

חבילת iproute (הנקראת לעיתים גם iproute2)

התסריטים במדריך זה מניחים כי /bin/ip מותקן אצלך. זהו אחד מכלי השליטה בתחום התקשורת ברשתות, אשר הינם חלק מחבילה ששמה iproute (ומכונה גם iproute2 בהפצות מסויימות; בדקי זאת). אין היא תמיד מותקנת כברירת-מחדל, אך היא תמיד מגיעה עם ההפצה. אם כן, התקיני אותה. אם /bin/ip נמצא עובד, הצלחת.

לקוח PPTP

עשוי להופיע בחלק מן ההפצות, ולא באחרות. אם אין לך לקוח כזה מותקן (בדקי במערכת החבילות של ההפצה שלך), השיגי לך לקוח כחבילה של ההפצה שלך (בהפצת דביאן, שם החבילה הוא pptp-linux; היא אינה בהכרח מותקנת כברירת מחדל ואז יש להתקינה במפורש); לחילופין, השתמשי באחד הקישורים שצוינו לעיל. שימי לב כי נניח להלן שקובץ ההרצה של לקוח ה-PPTP הוא /usr/sbin/pptp.

חיבור פעיל לרשת הכבלים

עליך להיות מחוברת חיבור אתרנט למודם הכבלים, אם באמצעות כרטיס אתרנט, אם באמצעות כבל USB וחיבור ethernet וירטואלי מעל חיבור ה-USB. כינון חיבור ethernet כזה אינו מוסבר במדריך זה.

ודאי שאת מקבלת כתובת באמצעות DHCP (נתקלת בבעיות? קראי את ה-DHCP-HOWTO), שיש לך טבלת ניתוב תקינה, שיש לך את כתובות שרת ה-DNS של ספק הכבלים וכי את מסוגלת לתקשר (למשל לבצע ping) עם השרתים הללו. אם את מבצעת אוטומציה של חיבור הנל"נ, שימי לב לנקודה בה מורצת פקודות ifup ethX, ifconfig ethX, ip link ethX up או משהו דומה לכך (עבור חיבור לרשת הכבלים על המשק ethX). ב-HOWTO של אמיר טל, התסריט בו נעשה שימוש מרחיק עד כדי הפלת הממשק, ואז הקמתו מחדש (הווה אומר ifup eth0 ; ifdown eth0) לפני הקמת חיבור ה-PPTP; אך אל תעשי זאת אלא אם כאן נראה שאת חייבת.

הכתובת ו/או שם ה-domain של שרת ה-PPTP של ספק הגישה שלך

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

שם הספק קוד PPTP שם שרת PPTP
אינטרנט זהבInzahavpns.inter.net.il
אקוונט?cable.aquanet.co.il
אקטקוםActcompns4.actcom.net.il
בזק בינלאומיBezintcables.bezeqint.net
ברק 013Barakpns.barak.net.il
הטכניוןN/Accdis3.technion.ac.il
ישראסרבIsraServsurf.israserv.net.il192.117.195.250
נטויז'ןNetvisioncable.netvision.net.il
קוי זהב (012.net)Kzahavaztv.012.net.il

הערות:

כינון החיבור

תיאור כללי

להלן הוראות לכינון חיבור PPTP אחד; הקוד וההצעות עלולים שלא להתאים למצב של ריבוי בו-זמני של חיבורים, למרות שאיני רואה בעייה מיוחדת בכך (להוציא הצורך בכתיבת תסריטים מסובכים יותר משלך להסדרת ניתוב) נניח כי שמו של ספק הגישה אליו אנו מתחברים הוא 'Yosefcom Internet Services' (משיקולי נוחות מתן שמות).

התוכנית שעושה את רוב העבודה השחורה תהיה pppd.‏ pppd הוא תהליך-הרקע של PPP (Point-to-Point Protocol - פרוטוקול נקודה-לנקודה); הוא מספק ממשק רשת באמצעות תקשור מעל 'קו' סדרתי; במקרה שלנו ה-'קו' יהיה החיבור (מעל ממשק רשת הכבלים) לשרת ה-PPTP.

מה שקורה כאשר את מבקשת להתחבר לספק הגישה שלך הוא שאת (או תהליך אוטומטי כלשהוא על המערכת שלך) מבצע/ת את הפקודה pon yosefcom; כך מורץ תסריט ה-pon. תסריט זה מריץ את pppd. pppd ישתמש בקבוצת האפשרויות 'yosefcom', ויריץ את הפקודה הרשומה עבור אפשרות ה-pty לכינון ה-'קו'. pppd יערוך אז משא-ומתן שישיג חיבור נל"נ על אותו 'קו', באמצעות יתר אפשרויות ה-'yosefcom' כמו גם סיסמה עבור המשתמש שלך ב-Yosefcom Internet Services, אשר שמורה בנפרד מיתר האפשרויות. לאחר כינון החיבור, pppd יגורם לכל התסריטים בספריית ip-up.d/ של הפצת הלינוקס שלך לרוץ. חלק מהם עשויים להיות תסריטים לשימוש כללי בכל חיבור, בעוד חלק מהם עשויים להיות מיועדים לחיבור המסויים ל-Yosefcom.

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

נתיבים סטאטיים במקטע הרשת של הכבלים

משימתנו הראשונה הינה לוודא כי – בכל מקרה שהוא – חבילות ה-IP שאת שולחת לשרת ה-PPTP של הספק שלך (ולשרת ה-DHCP של הכבלים) לא יישלחו בטעות דרך ממשק ה-PPP במקום דרך ממשק האתרנט שמתחתיו. כדי לוודא זאת נקבע רשומות מיוחדות בטבלת הניתוב עבור שני השרתים הללו בכל פעם בה מעלים את ממשק האתרנט למקטע הרשת של הכבלים. בדביאן 3.0/3.1, ערכי את הקובץ /etc/network/interfaces. לממשק האתרנט של הכבלים (למשל: eth0) צריך להיות גוש שורות המתחיל בשורה הבאה: 
iface ממשק האתרנט של הכבלים‎ inet dhcp
ואחריה מספר כלשהוא של אפשרויות מסוימות לממשק זה. נוסיף לגוש השורות הללו את שתי השורות הבאות: 
        up ip route replace ‎כתובת ה-IP של שרת ה-PPTP של הספק‎ dev ממשק האתרנט של הכבלים‎
        up ip route replace כתובת ה-IP של שרת ה-DHCP של הכבלים dev ממשק האתרנט של הכבלים

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

ip route replace כתובת ה-IP של שרת ה-PPTP של הספק שלך dev ממשק האתרנט של הכבלים
ip route replace כתובת ה-IP של שרת ה-DHCP של הכבלים dev ממשק האתרנט של הכבלים
כתובת שרת ה-PPTP של הספק הינה הכתובת הנמצאת בטבלה שהוצגה לעיל; לעומת זאת, כתובת שרת ה-DHCP של הכבלים היא עניין מעט יותר מורכב. הנה תסריט בשם dhcp-server-of-if, אשר מורץ עם שם ממשק האתרנט המקונפג באמצעות DHCP (למשל: eth0) ומחזיר את כתובתו של שרת ה-DHCP:

#!/usr/bin/perl

#for Debian 3.1:
$lease_file = "/var/run/dhclient.$ARGV[0].leases";
#for Debian 3.0:
#$lease_file = "/var/lib/dhcp/dhclient.leases";

exit 1 unless ( $#ARGV == 0 );
$/ = '}'; # lease records are of the form "lease { etc. etc. }", but with line breaks
open( LEASES, '<', $lease_file ) || exit 1;
while (  ) {
        if ( /$ARGV[0]/ ) {
                # this is a lease for our interface, locate
                # the DHCP server address within it
                /(.|\n)*dhcp-server-identifier (.*);(.|\n)*/;
                $dhcp_server = $2;
        }
}
# we assume the last lease for our interface is the valid one
print "$dhcp_server\n";

תסריט זה פועל במערכות דביאן 3.1; אם נחליף את שם קובץ רישיונות ה-DHCP, הוא יפעל בכל מערכת המשתמשת בלקוח ה-DHCP dhclient. אם המערכת שלך משתמשת דווקא ב-pump , שני את תסריט dhcp-server-of-if הבא: 

#!/bin/sh
pump -i "$1" -s | grep "Boot server" | cut -d ' ' -f 3

הרעיון הוא למצוא היכן מאוכסנת הכתובת – על-פי-רוב בתוך רשומת רישיון ה-DHCP הנוכחי – ולברר איזה מן השדות ברישיון מתייחס לכתובות של שרת ה-DHCP.

הערה למשתמשת המתקדמת: אולי שאלת את עצמך "למה לנו כל הצרות האלה? הלא נוכל לבצע את כל קביעת-הנתיבים הזו בתסריטי ה-ip-up.d של pppd?" אכן, בגרסאות קודמות של מדריך זה כך בחרתי לעשות, אך מישהו הפנה את תשומת ליבי לכך, שבמקרים מסויימים כתובת ה-IP של העמית בחיבור ה-PPP הינה זהה לכתובת שרת ה-PPTP; ומשום ש-pppd מוסיף נתיב לכתובת ה-IP של העמית דרך ממשק ה-PPP, במשך-הזמן שבין הוספת נתיב זה והרצת תסריטי ה-ip-up.d לא יהיה נתיב תקף לשרת ה-PPTP, והחיבור עלול להתמוטט. למצער, pppd כולל תמיכה בתסריטי 'pre-up' רק החל בגרסה 2.4.4. אמנם נכון, כי ניתן להשתמש בתסריט-מעטפת סביב קובץ-ההרצה של pptp, לכינון הנתיבים הללו; בכל-זאת סביר יותר שיתקיימו כל הזמן – שהרי הם תמיד תקפים.

קובץ ה- pap-secrets של תהליך-הרקע pppd

pppd תומך בשני סוגי אימות, המכונים 'PAP' ו-'CHAP'. ספקי הגישה הישראליים משתמשים ב-PAP.

קובץ ה-'סודות' של pppd עבור אימות PAP, הקרוי /etc/ppp/pap-secrets, צריך להכיל (אולי בנוסף לרשומות אחרות) את השורה: 

‎שם המשתמש שקיבלת מן הספק‎@Cקוד הספק שלך‎  ‎כתובת שרת ה-PPTP של הספק‎  "‎הסיסמה שקיבלת מן הספק‎"

או השורה: 

‎שם המשתמש שקיבלת מן הספק‎  ‎כתובת ה-IP של שרת ה-PPTP של הספק‎  "‎הסיסמה שקיבלת מן הספק‎"

הערות:

קובץ האפשרויות המסויים-לספק של תהליך-הרקע לנל"נ

אפשרויות ברירת-המחדל של pppd ממוקמות בקובץ /etc/ppp/options. אך אנו לא נשתמש בהן! ל-pppd גם ספריית אפשרויות - /etc/ppp/peers - ובה קבצי אפשרויות מסויימים לכל עמית (ה-'עמית', peer באנגלית, הוא היישות אליה מבצעים את חיבור הנל"נ).

קובץ אפשרויות בסיסי מומלץ, אשר תוכלי ליצור כ-/etc/ppp/peers/yosefcom יהיה: 

# Yosefcom Internet Services connection options

linkname yosefcom

user ‎שם המשתמש שלך‎
                # you authenticate to the server as this user; this should be
                # the same name as in the pap-secrets file entry (i.e. if
                # you added the ISP code there, add it here also)

pty "/usr/sbin/pptp ‎כתובת ה-IP של שרת ה-PPTP של הספק‎ --nolaunchpppd"

nobsdcomp       # 'BSD-compress' will not be used, so let's disable it
nodeflate       # 'Deflate' will not be used, so let's disable it

hide-password   # does not show the password when logging

noauth          # does not require the remote server to authenticate itself
persist         # if link is broken, try to reestablish it rather
                # than exit immediately

usepeerdns      # eventually, cause a modification of /etc/resolv.conf to use 2
                # DNS server whose addresses are provided by the peer.
                # This may or may not be what you want to do, so be careful.

defaultroute
replacedefaultroute
                # Use this PPP connection as the default route,
                # i.e. by default, outgoing packets will be routed through it;
                # also, restore the previous default route when the PPP
                # connection comes down


#debug          # enable this for more verbose logging by pppd
#kdebug 4       # enable this for _yet_more_ verbose logging by pppd

כמה הערות:

תסרוט תלוי-ספק ב-ip-up.d ו-ip-down.d

ישנן מספר מטלות אשר ייתכן שיהיה צורך לבצען לאחר הקמת החיבור או הורדתו, ואלו תלויות בהגדרות המסויימות של המערכת שלך. עם זאת, רובן אינן מסויימות לספק-גישה כזה או אחר, (כך, למשל: טעינה-מחדש של ה-MTA (סוכן תעבורת דואר), אתחול או הפסקת sniffer עבור החיבור, וכו'); אלה מבוצעות באמצעות התסריטים הנמצאים כבר בספריות /etc/ppp/ip-up.d/ (תסריטים לאחר כינון חיבור) ו-/etc/ppp/ip-down.d/ (תסריטים לאחר הורדת חיבור).

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

תסריטי ההרחבה עבור מנגנוני ה-ip-up.d ו-ip-down.d

להלן מופיעים שני התסריטים אשר מרחיבים את מנגנוני ip-up.d ו-ip-down.d כך שיריצו תסריטים מסויימים-לעמית מתת-הספרייה linkname, באשר linkname נקבע כאפשרות של pppd. בהתייחסי למקומות קבצים, אשתמש במוסכמות של דביאן (Debian), בה שתי ספריות התסריטים הן /etc/ppp/ip-up.d/ ו-/etc/ppp/ip-down.d/; בהפצות אחרות יש סבירות רבה שיימצאו במקום אחר בתת-העץ של /etc.

תני ליבך גם לכך שמוסכמת מתן השמות לקבצים ב-/etc/ppp/ip-up.d/ ו-/etc/ppp/ip-down.d/ היא XXsomething, באשר XX הינו מספר בתחום 00...99 המציין סדר ביצוע (00 ראשון, 99 אחרון). במערכת דביאן 3.0/3.1 טיפוסית, הייתי משנה את שם תסריט קיר-האש (ששמו ipmasq או 0ipmasq) ל- 10ipmasq, ומשתמש בקידומת 05 עבור המרחיבים. ראי דיון נוסף בענייני קיר-אש בהמשך.

תוכן הקובץ /etc/ppp/ip-up.d/05peer-specific :

#!/bin/bash
#
# run peer-specific (or, rather, linkname-specific) scripts

if [ -n "$LINKNAME" ] ; then
        run-parts /etc/ppp/ip-up.d/$LINKNAME
fi

exit 0

תוכן הקובץ /etc/ppp/ip-down.d/05peer-specific :

#!/bin/bash
#
# run peer-specific (or, rather, linkname-specific) scripts

if [ -n "$LINKNAME" ] ; then
        run-parts /etc/ppp/ip-down.d/$LINKNAME
fi

exit 0

אם, מסיבה כלשהיא, ההפצה שלך אינה משתמשת במנגנון ה-ip-up.d/ip-down.d, אלא בתסריטי ip-up ו-ip-down פשוטים בלבד, תוכלי לטפל בבעייה זו: הורידי את חבילת ה-ppp של דביאן, חלצי מתוכה את הקבצים הדרושים לך, הביאי אותם לכדי תואם עם תוכן 2 התסריטים הנוכחיים שלך, והתקיני אותם במקומם. תצטרכי גם run-parts פעיל.

כאשר התסריטים המסויימים-לעמית שלך מורצים (ובעצם, כאשר כל תסריט ip-up / ip-down מורץ), זמינים לו מספר משתני סביבה הנוגעים לחיבור שהתכונן. הנה הם:

שם ערך
PPPD_PIDמזהה תהליך במערכת זו של ה-pppd המטפל בחיבור הנוכחי
PPPLOGNAMEשם-המשתמש תחתיו הורץ ה-pppd המנהל את החיבור הנוכחי
PPP_IPPARAMערך אופציונלי, חסר חשיבות רבה
IPLOCALכתובת ה-IP שהתקבלה במשא-ומתן עבור מערכת זו על חיבור זה בידי pppd
PPP_LOCALכנ"ל
IPREMOTEכתובת ה-IP של מערכת העמית על חיבור זה
PPP_REMOTEכנ"ל
IFNAMEשם ממשק הרשת עבור חיבור הנל"נ, כמו למשל ppp1 או ppp3
PPP_IFACEכנ"ל
LINKNAMEערך ה-linkname בקובץ האפשרויות של pppd עבור חיבור זה
PPP_TTYNAMEבלתי-רלבנטי לחיבורי PPTP
SPEEDבלתי-רלבנטי לחיבורי PPTP
PPP_SPEEDכנ"ל
DNS1כתובת שרת ה-DNS הראשונה שציין העמית, אם אפשרות usepeerdns נבחרה
DNS2כתובת שרת ה-DNS השנייה שציין העמית, אם אפשרות usepeerdns נבחרה

הסיבה לכפילויות היא שחלק מן המשתנים נקבעים על-ידי pppd עצמו, ואחרים נקבעים על-ידי התסריט ip-up או ip-down.

בירור שמות

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

ניתוב

בעת כינון החיבור, רוב המשתמשות יכולות לנצל את יכולתו של pppd להחליף את נתיב ברירת-המחדל: בקובץ האפשרויות עבור הספק אשר פירטנו לעיל, כללנו את defaultroute ו-replacedefaultroute, אשר עושות זאת. לעומת זאת, אם ברצונך לבצע משהו מסובך יותר, בטלי את שתי האפשרויות הללו, והוסיפי תסריט מתאים לספריית ip-up.d/yosefcom/. הנה, למשל, תסריט המבצע מה ש-replacedefaultroute היה עושה:

#!/bin/sh
#

# Route through the PPP connection by default
#
ip route replace default via $IPREMOTE dev $PPP_IFACE

אם את מחליפה את נתיב ברירת-המחדל בעת כינון חיבור ה-PPP, שלא באמצעות defaultroute + replacedefaultroute אלא בתסריט משלך , את זקוקה גם לתסריט ip-down.d/yosefcom/ לשחזור שער-הרשת הקיים ללא חיבור ה-PPP:

#!/bin/sh
#

# The PPTP server IP
#
PPTP_SERVER=‎כתובת ה-IP של שרת ה-PPTP של הספק‎

# The underlying interface, on which we connect
# to the PPTP server
#
UNDERLYING_INTERFACE=`ip -o route get to $PPTP_SERVER | cut -d\  -f5`

# The default gateway of the underlying cable connection,
# determined using a helper script. Note: This assumes
# the only entry in the ARP table for the cable connection
# is that of your gateway; this holds AFAIK
#
UNDERLYING_GATEWAY=`ip neighbour show dev $UNDERLYING_INTERFACE | sed "s/^\([0-9\.]\+\).*/\1/"`

# restore the non-PPP default gateway
ip route replace default via $UNDERLYING_GATEWAY dev $UNDERLYING_INTEFFACE

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

ענייני קיר-אש

אחת הבעיות אשר עלולה למנוע בעדך מהשלמת כינון חיבור ה-PPTP הינו קיר-אש. קיר-אש עלול, מסיבות שונות, למנוע מחלק מן התקשורת בין לקוח ושרת ה-PPTP להגיע ליעדה (מה שיביא לרישום SIGHUPים מסתוריים על-ידי pppd). לעת עתה איני בטוח אילו סוגי כללי קיר-אש עלולים להפריע לכינון חיבור PPTP, לכן ניתן לאמץ גישה גסה: הורדה מוחלטת של קיר-האש לפני ביצוע החיבור, והרמתו-מחדש לאחר-מכן (למעשה, יש להרים-מחדש את קיר-האש לאחר חיבור גם אם לא הורד קודם-לכן), בהתחשב בחיבור ה-PPTP החדש כחיבור חיצוני חדש. ההרמה וההקמה של קיר-אש הינה גם היא די מסויימת-הפצה. בדביאן 3.0/3.1 (וכנראה גם 2.2), הקמה-מחדש נקראת אוטומטית באמצעות תסריט בספריה ip-up.d (עייני בדקדוק בסדר ריצת התסריטים, שכן את עלולה להצטרך לבצע כמה שינויי-שמות; ראי לעיל), אך קיר האש אינו מורד לפני הרצת לקוח ה-PPTP.

הפלת קיר-האש

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

#!/bin/sh

IPFWADM=/sbin/ipfwadm
IPCHAINS=/sbin/ipchains
IPTABLES=/sbin/iptables

# determine rule method
if [ -e /proc/net/ip_tables_names ]; then
   test -x $IPTABLES || exit 1
       MASQMETHOD=netfilter
elif [ -e /proc/net/ip_fwchains ]; then
   test -x $IPCHAINS || exit 1
       MASQMETHOD=ipchains
else
    test -x $IPFWADM || exit 1
        MASQMETHOD=ipfwadm
fi

#: Flush all and set default policy of allow.
case $MASQMETHOD in
ipfwadm)
    $IPFWADM -I -p allow
    $IPFWADM -O -p allow
    $IPFWADM -F -p allow
    $IPFWADM -I -f
    $IPFWADM -O -f
    $IPFWADM -F -f
    ;;
ipchains)
    $IPCHAINS -P input ALLOW
    $IPCHAINS -P output ALLOW
    $IPCHAINS --no-warnings -P forward ALLOW
    $IPCHAINS -F input
    $IPCHAINS -F output
    $IPCHAINS --no-warnings -F forward
    ;;
netfilter)
    $IPTABLES -P INPUT ACCEPT
    $IPTABLES -P OUTPUT ACCEPT
    $IPTABLES -P FORWARD ACCEPT
    $IPTABLES -F INPUT
    $IPTABLES -F OUTPUT
    $IPTABLES -F FORWARD
    $IPTABLES -t mangle -P PREROUTING ACCEPT
    $IPTABLES -t mangle -P OUTPUT ACCEPT
    $IPTABLES -t mangle -F PREROUTING
    $IPTABLES -t mangle -F OUTPUT
    $IPTABLES -t nat -P PREROUTING ACCEPT
    $IPTABLES -t nat -P POSTROUTING ACCEPT
    $IPTABLES -t nat -P OUTPUT ACCEPT
    $IPTABLES -t nat -F PREROUTING
    $IPTABLES -t nat -F POSTROUTING
    $IPTABLES -t nat -F OUTPUT
    ;;
esac

כיצד ניתן להשתמש בתסריט זה? במקום לקרוא מייד ללקוח ה-PPTP בהגדרת ה-pty בקובץ האפשרויות המיוחד לספק-הגישה, תוכלי להשתמש ב: "/usr/local/sbin/drop-firewall ; /usr/sbin/pptp my_isp_pptp_server --nolaunchpppd".

שינוי בייצור קיר-האש

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

משום ש-ipmasq, בו משתמשת הפצת Debian, הינה המערכת היחידה אותה אני מכיר, אתי ואתאר מה עלול להשתבש (ואכן משתבש) כאשר נעשה בה שימוש יחד עם PPTP:

כל זאת ניתן לתיקון באמצעות התעסקות עם התסריטים (ראי התיעוד של ipmasq, bash, ו-ipfwadm/ipchains/iptables, תלוי בגרסת הגרעין שלך) - אך להתעסקות כזו יש השלכות על אבטחה, אשר על המשתמשת ומנהלנית המערכת הזהירות להביא בחשבון.

הפתרון הוא אחד משניים: לגרום לתהליך לקוח ה-PPTP או תהליך ה-pppd להיות מתירניים יותר לגבי פקיעות-זמן (timeouts), (אם החבילות האבודות הן אכן מן העבר הקרוב), או לשנות את מנגנון יצירת קיר-האש ipmasq, שהיא האפשרות אותה בחרתי אני.

השינויים שביצעתי הינם הוספת קבצי החוקים A01interfaces.rul, A02unkernelforward.rul, A03flush.rul (בהם נעשה שימוש במקום קבצי ה-.def המתאימים) ו-ZZZresetpolicy.rul לו אין קובץ .def . יצרתי גם את הקובץ החדש /etc/ipmasq/internal_ifs.

תוכן הקובץ A01interfaces.rul : 

# find interface names
INTERNAL=`egrep -v '^[:space:]*#' /etc/ipmasq/internal_ifs`
EXTERNAL=$(enumerate-if | sort -u | grep -v lo)
if [ -n "$INTERNAL" ]; then
    for i in $INTERNAL; do
        EXTERNAL=$(echo $EXTERNAL | sed -e "s/\(  *\|^\)$i\(  *\|$\)/\1/")
    done
fi

# remove interfaces that don't have networks attached to them
if [ -n "$INTERNAL" ]; then
    for i in $INTERNAL; do
        nm=$(nmofif $i)
        if [ -z "${nm}" ]; then
            INTERNAL=$(echo $INTERNAL | sed -e "s/\(  *\|^\)$i\(  *\|$\)/\1/")
        fi
    done
fi
if [ -n "$EXTERNAL" ]; then
    for i in $EXTERNAL; do
        if [ -z "`enumerate-if | grep $i`" ]; then
            EXTERNAL=$(echo $EXTERNAL | sed -e "s/\(  *\|^\)$i\(  *\|$\)/\1/")
            continue
        fi
        nm=$(nmofif $i)
        if [ -z "${nm}" ]; then
            EXTERNAL=$(echo $EXTERNAL | sed -e "s/\(  *\|^\)$i\(  *\|$\)/\1/")
        fi
    done
fi

תוכן הקובץ A02unkernelforward.rul : 

#: DO NOT Turn off forwarding for 2.1 kernels!
#: DO NOT Turn off IP defragmentation

תוכן הקובץ A03flush.rul : 

#: Set a default policy of 'accept' and flush all
case $MASQMETHOD in
ipfwadm)
    $IPFWADM -I -p accept
    $IPFWADM -O -p accept
    $IPFWADM -F -p accept
    $IPFWADM -I -f
    $IPFWADM -O -f
    $IPFWADM -F -f
    ;;
ipchains)
    $IPCHAINS -P input ACCEPT
    $IPCHAINS -P output ACCEPT
    $IPCHAINS --no-warnings -P forward ACCEPT
    $IPCHAINS -F input
    $IPCHAINS -F output
    $IPCHAINS --no-warnings -F forward
    ;;
netfilter)
    $IPTABLES -P INPUT ACCEPT
    $IPTABLES -P OUTPUT ACCEPT
    $IPTABLES -P FORWARD ACCEPT
    $IPTABLES -F INPUT
    $IPTABLES -F OUTPUT
    $IPTABLES -F FORWARD
    $IPTABLES -t mangle -P PREROUTING ACCEPT
    $IPTABLES -t mangle -P OUTPUT ACCEPT
    $IPTABLES -t mangle -F PREROUTING
    $IPTABLES -t mangle -F OUTPUT
    $IPTABLES -t nat -P PREROUTING ACCEPT
    $IPTABLES -t nat -P POSTROUTING ACCEPT
    $IPTABLES -t nat -P OUTPUT ACCEPT
    $IPTABLES -t nat -F PREROUTING
    $IPTABLES -t nat -F POSTROUTING
    $IPTABLES -t nat -F OUTPUT
    ;;
esac

תוכן הקובץ ZZZresetpolicy.rul : 

#: Reset policies to 'deny' where necessary
case $MASQMETHOD in
ipfwadm)
    $IPFWADM -I -p deny
    $IPFWADM -O -p deny
    $IPFWADM -F -p deny
    ;;
ipchains)
    $IPCHAINS -P input DENY
    $IPCHAINS -P output DENY
    $IPCHAINS --no-warnings -P forward DENY
    $IPCHAINS --no-warnings -F forward
    ;;
netfilter)
    $IPTABLES -P INPUT DROP
    $IPTABLES -P OUTPUT DROP
    $IPTABLES -P FORWARD DROP
    ;;
esac

תוכן הקובץ /etc/ipmasq/internal_ifs (הממשקים הרשומים הם סתם דוגמאות; החליפי אותם):

# /etc/ipmasq/internal_ifs
#
# in this file are listed all intefaces which, if they exist,
# are considered to be internal; all other interfaces will be
# considered external.
#
# each word in a non-comment line should be a name of one of
# these interfaces.
#
eth1
eth3

כמה הערות נוספות בעניין קיר-האש

מה עוד אפשר להריץ מ-ip-up.d?

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

http://www.technopagan.org/dynamic/
DNS דינאמי - מבוא ורשימת ספקי DDNS
http://kem.p.lodz.pl/~peter/qnet/
קובץ-הטלאים QNET: טלאי איכות-שירות ו-NetFilter לגלעין הלינוקס
http://lartc.org/
ניתוב ועיצוב תעבורה מתקדמים בלינוקס
http://lartc.org/wondershaper/
WonderShaper - אוטומציית 'עיצוב תעבורה' פשוטה (יחסית)
http://www.digriz.org.uk/jdg-qos-script/
תסריט איכות-השירות של Jim diGriz's - אחיו הגדול של WonderShaper

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

ביצוע החיבור

ממצוב בו חיבור הכבלים שלך פועל, בצעי pon yosefcom והמתיני מספר שניות. בצעי ip link לבדיקת קיומו של חיבור הנל"נ. פלט טיפוסי ייראה בערך כך: 

1: eth0:  mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether כתובת ה-MAC של כרטיס הרשת שלך brd ff:ff:ff:ff:ff:ff
2: lo:  mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: ppp0:  mtu 1400 qdisc pfifo_fast qlen 3
    link/ppp

עתה השתמשי ב-ip route list לבדוק את טבלת הניתוב. פלט טיפוסי:

PPTP_SERVER via UNDERLYING_GATEWAY dev UNDERLYING_INTERFACE src הכתובת שלך במקטע הרשת של הכבלים
DHCP_SERVER via UNDERLYING_GATEWAY dev UNDERLYING_INTERFACE  src הכתובת שלך במקטע הרשת של הכבלים
מקטע הרשת של הכבלים dev UNDERLYING_INTERFACE proto kernel  scope link  src הכתובת שלך במקטע הרשת של הכבלים
default via PPP_LOCAL dev PPP_IFACE

הערות:

עתה, בצעי ping למכונה כלשהיא הידועה לך, או traceroute או lynx לאתר נפוץ כלשהוא, כדי לוודא שהחיבור אכן פועל. אם אחת הבדיקות הללו אינה פועלת כמצופה, בדקי את הרישומות (/var/log/messages , /var/log/syslog), או בצעי plog אשר מראה לך את החלקים האחרונים הקשורים ל-pppd ברישומות. תוכלי גם לנסות איפשור של אפשרויות הדיבוג בקובץ האפשרויות המסויים-לספק של pppd. בפרט, ודאי כי אין לך שני שערי-רשת של-ברירת-מחדל בטבלת הניתוב; אם יש לך שניים כאלה, שני את תסריט תצורת הניתוב שלך. זכרי כי גם את יכולה לחולל פלט למטרות דיבוג מתוך תסריטי ip-up.d/, הן לתוך רישומות המערכת הן לתוך רישומת משלך; כך, למשל, הפקודה 

echo `date` [ `cat /proc/self/stat | cut "-d " -f 1` ] some text > /tmp/myppplog
יוסיף שורה האומרת "some text" לרישומת שבקובץ /tmp/myppplog, עם חותמת תאריך ומספר תהליך.

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

pptp[22731]: log[pptp_conn_close:pptp_ctrl.c:307]: Closing PPTP connection
pptp[22731]: log[call_callback:pptp_callmgr.c:88]: Closing connection
pppd[22745]: Hangup (SIGHUP)
pppd[22745]: Modem hangup
pppd[22745]: Script /etc/ppp/ip-down started (pid 24347)
pppd[22745]: Connection terminated.
pppd[22745]: Connect time 1342.6 minutes.
pppd[22745]: Sent 991866306 bytes, received 1231829177 bytes.
pppd[22745]: Waiting for 1 child processes...
pppd[22745]:   script /etc/ppp/ip-down, pid 24347
pppd[22745]: Script /etc/ppp/ip-down finished (pid 24347), status = 0x0

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

שתחול החיבור במקרה של כשל

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

הדרך הפשוטה ביותר לעשות זאת היא באמצעות שימוש במנגנון ה-cron לביצוע מטלות תקופתיות במערכת. הוסיפי את השורה הבאה לקובץ ה-/etc/crontab שלך: 

* * * * * root /usr/local/bin/check-ppp-connection yosefcom

כך ייבדק מצב החיבור כל דקה; תחת זאת תוכלי להשתמש ב:

*/5 * * * * root /usr/local/bin/check-ppp-connection yosefcom

עבור בדיקות כל חמש דקות, וכו'. תוכן תסריט הבדיקה, /usr/local/bin/check-ppp-connection, יהא: 

#!/bin/sh
#
# ensure specified PPP connection link is up; otherwise start it
#
# note: this script assumes the linkname is the same as the name of the options file in /etc/ppp/peers

LINKNAME=$1

if [ -z "$LINKNAME" ]; then
        echo "Usage: check-ppp-connection <linkname>"
        exit 1
fi

if [ -f /var/run/ppp-$LINKNAME.pid ]; then
        PPP_IFACE=`tail -1 /var/run/ppp-$LINKNAME.pid`
        if [ "$PPP_IFACE" ] && [ "`ip -o link show $PPP_IFACE`" ]; then
                exit 0
        fi
fi
exec pon $LINKNAME

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

ביצוע החיבור בעת אתחול המערכת

הפצות שונות צריכות שנאמר להן בדרכים שונות אילו ממשקים יש להעלות בעת אתחול המערכת, ואיך לעשות זאת. במקרה של דביאן 3.1 ואילך (אולי גם בדביאן 3.0), הוסיפי את השורות הבאות לקובץ ה-/etc/network/interfaces שלך:

iface ppp0 inet ppp
    provider yosefcom

(בהנחה שהחיבור ל-yosefcom הוא ממשק הנל"נ הראשון שאת מעלה; אחרת השתמשי באינדקס שאינו 0).

עתה, הוסיפי לשורת ה-auto של קובץ ה-interfaces את הממשק ppp0; כך, לדוגמה, תוחלף השורה

auto lo eth0

בשורה

auto lo eth0 ppp0

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

לגבי הפצות אחרות - כאן עליך להסתדר באופן עצמאי; אם אינך מצליחה למצוא חלופה פשוטה יותר, תמיד תוכלי להוסיף תסריט rc.d עבור ה-runlevel הנבחרת שלך.

מידע וסיוע נוסף

תוכלי לנסות את:

לענייני קיר-אש, כדאי לפעול לפי המלצתו של ה-ADSL-HOWTO, ולקרוא על מנגנוני סינון ה-IP (החדשים יותר) בלינוקס, iptables, ב- HOWTO תרגום-כתובות-רשת (NAT) וב-HOWTO סינון-חבילות (Packet-Filtering).

משתמשות בהפצת דביאן ירצו, יש להניח, להתעניין גם בחבילה resolvconf, אשר מסייעת לתיאום מידע אודות בירור שמות המגיע ממקורות שונים - קובץ ה-hosts, רישיון ה-DHCP ושרת ה-DNS המקומי.

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