פרסם פורט לקוח VPN מאחורי CGNAT: רשימת בדיקה

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

אמת שהשרת יעביר בכלל

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

להגדיר אותו בליבה פועלת אינו אותו דבר כמו להגדיר אותו לאורך אתחול. כתוב net.ipv4.ip_forward=1 לקובץ תחת /etc/sysctl.d/, הרץ sysctl --system, ואז קרא את הערך חזרה במקום להאמין שהקובץ נקלט. קונטיינר שמנהל מרחב שמות רשת משלו זקוק לאותו ערך בתוך אותו מרחב, לא רק במארח.

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

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

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

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

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

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

תרגם לשני הכיוונים

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

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

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

קרא את שני הכללים חזרה עם iptables -t nat -S ואמת ששם הממשק הוא זה שנושא את הכתובת הציבורית. במארח שכבר מסנן עם nftables, כתוב את התרגום בשרשרת NAT של nftables של משפחת הכתובות המתאימה במקום לערבב כלים.

תן לטבלת הסינון לעבור

טבלאות NAT כותבות מחדש כותרות; הן לא נותנות הרשאה. עם מדיניות DROP ברירת מחדל הזרימה המועברת זקוקה לאישור משלה, בנוסף לכיוון החזרה שרוב המדיניות כבר מכסה בכלל established,related.

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

בדוק את המדיניות של שרשרת FORWARD לפני שאתה מוסיף משהו, כי הסדר של DROP מוקדם קובע אם בכלל יתייעצו בכלל שלך. במארח שהסינון שלו חי ב-nftables, הוסף את הכלל המקביל ל-hook של forward בטבלת inet ואמת שהשרשרת הבסיסית באמת רואה תעבורה מועברת ולא רק קלט מקומי. אם מונה מנות בכלל החדש נשאר באפס בזמן שמוני NAT עולים, המנה נזרקת לפני הכלל שלך. זה האות לקרוא את סדר השרשראות, לא להוסיף עותק שני של אותו כלל.

הוכח זאת מרשת חיצונית

בדוק מרשת לא קשורה. בדיקה ממכונה אחרת באותה LAN יכולה לעבור דרך תמיכת hairpin NAT ולעולם לא לתרגל את הנתיב שלקוח מרוחק משתמש בו, כך שתוצאה ירוקה שם מוכיחה את הדבר הלא נכון.

tcpdump -ni any port 29443
conntrack -L | grep 29443

הרץ את הלכידה בשרת ובלקוח באותו זמן. הלכידה בשרת מראה אם המנה המתורגמת יוצאת לכיוון המנהרה; הלכידה בלקוח מראה אם הבקשה מגיעה ולאן התגובה ממוענת. רשומת תרגום ב-conntrack -L מוכיחה שהכלל תאם, והיעדרה מוכיח שהמנה מעולם לא הגיעה לשרשרת NAT.

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