PPTP של MikroTik נופל? תקנו את המסלול לשרת

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

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

התסמין: מתחבר, מעביר תעבורה, מת

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

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

למה המנהרה בולעת את המנות של עצמה

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

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

הצמידו את כתובת השרת ל-WAN

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

/ip route add dst-address=198.51.100.10/32 gateway=192.0.2.1 distance=10

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

או מנעו מהמנהרה לתבוע את ברירת המחדל

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

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

אמתו בשכבות, ואז סגרו את חור הניהול

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

/ip firewall nat add chain=srcnat out-interface=pptp-out1 action=masquerade

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

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