לקוחות PPTP ב-DD-WRT לא מגיעים זה לזה: חמש בדיקות

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

בדיקה ראשונה: ה-/32 אינו הבאג

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

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

בדיקה שנייה: קראו את הערכים בעמוד שרת ה-PPTP

כל ההגדרות החשובות נמצאות בשירותים, VPN, שרת PPTP. הפעילו את השרת, קבעו את כתובת השרת לכתובת ה-LAN של הנתב, והשאירו את טווח הלקוחות מחוץ למאגר ה-DHCP כדי שלקוח מחייג ומחשב קווי לא יקבלו את אותה כתובת. תחת CHAP-Secrets הוסיפו שורה אחת לכל חשבון בצורה username * password *, בלי רווחים בתוך השם. החילו, ואז התחברו עם פרופיל שמציין את הנתב ואחד מהחשבונות האלה.

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

בדיקה שלישית: חפשו מסלול בין שני העמיתים

כל מנהרה שמסתיימת בנתב היא ממשק משל עצמה, בדרך כלל ppp0, ppp1 וכן הלאה. תעבורה מלקוח אחד לשני חייבת להיות מנותבת בין הממשקים האלה, והנתב חייב להיות מוכן להעביר אותה הלאה. הריצו ip route בנתב וחפשו מסלול מארח לכל עמית מחובר שמצביע על ממשק ה-PPP המתאים. אם חסר מסלול לעמית, המנהרה לא לגמרי למעלה, יהיה אשר יאמר מסך המצב של הלקוח.

שני מסלולי מארח לשני ממשקי ppp נפרדים הוא הצורה הרצויה לפני שממשיכים.

בדיקה רביעית: הסתכלו על שרשרת FORWARD, לא על INPUT

תעבורה בין לקוחות מועברת הלאה ולא מתקבלת מקומית, ולכן שרשרת INPUT היא המקום הלא נכון. הריצו iptables -L FORWARD -v -n וחפשו כלל השלכה שתופס את ממשקי ה-PPP, יחד עם מוני החבילות שמראים אם בכלל משהו מגיע לשרשרת. מדיניות השלכה כברירת מחדל בלי כלל קבלה לתעבורת מנהרה מייצרת בדיוק את התסמין שאיתו התחלתם: כל לקוח לבדו בסדר, וביחד הם בלתי נראים זה לזה.

אם פינגים קטנים עובדים והעברות גדולות נתקעות, המנהרה עוברת פיצול ולא חסימה. PPTP מעל PPP רוצה בדרך כלל MTU ו-MRU בסביבות 1450, והשארתם על 1500 נותנת קישור שעובר לחיצות ידיים ונכשל בעומסים אמיתיים.

בדיקה חמישית: החליטו מה גישת האינטרנט אמורה לעשות

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

הערה אחרונה, לא קשורה לתיקון: PPTP מיושן והאימות שלו שבור כבר שנים. הרשימה למעלה עדיין מסבירה מה קישור PPP עושה, ואותו היגיון תקף אם תעבירו את הלקוחות מאוחר יותר למנהרה מודרנית.