eth0:0 הוא תווית, לא התקן: תקן את התאמת SNAT

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

בדוק איך הקרנל קורא להתקן

קרא את שתי התצוגות בנפרד לפני שאתה משנה משהו:

ip link show
ip address show dev eth0
ip route get 203.0.113.20

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

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

בדוק למה הכלל באמת התאים

קרא את המונים יחד עם רשימת הכללים ולא מהזיכרון:

iptables -t nat -L POSTROUTING -v -n --line-numbers

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

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

בדוק את הניתוב שבחר את ההתקן

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

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

בחר את המקור המתורגם בכוונה

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

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.20

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

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

אמת עם חיבור שזה עתה פתחת

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

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