אחרי שינוי כתובת ה-IP של השרת, כלל ה-SNAT עדיין מציין את הישנה

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

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

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

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

קרא את הכלל ואת המונים שלו לפני עריכה

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

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

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

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

החלף את המקור, או הפסק לציין אחד

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

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

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

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

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

שתי דרכים לעשות את ההחלפה לא נכון

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

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

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

שירותים נכנסים צריכים את התרגום ההפוך

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

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

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