iptables: לתת ללקוחות VPN להגיע רק למארח אחד

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

איזו שרשרת עונה על השאלה שלכם

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

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

קודם המצב, אחר כך ההיתר, ואז הדחייה

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

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

שני פרטים מכריעים אם זה ישרוד מפגש עם תעבורה אמיתית. בלי כלל המצב, התשובות לחיבורים שהרגע התרתם מוערכות בעצמן מול הדחייה ומושלכות. כלל LOG בלי הגבלה יכול למלא מחיצה קטנה בפעם הראשונה שסריקה פוגעת בה, לכן הוסיפו -m limit --limit 10/min לפני שתמשיכו לתעד. REJECT מחזיר שגיאה מיד, מה שידידותי יותר בזמן כיוונון הרשימה; DROP משליך בשקט, ולכן כל טעות מוצגת כפסק זמן. בחרו אחד בכוונה וכתבו את הבחירה ברשומת השינוי.

העברה ו-NAT חייבים כבר לעבוד

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

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

חסימת הדואר שייכת שרשרת אחת הלאה

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

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

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

קראו אותו בחזרה, ואז הוכיחו אותו מלקוח

קראו את מערכת הכללים כפי שהגרעין מדווח עליה, לא כפי שהסקריפט שלכם כתב אותה. התחילו עם iptables -S FORWARD, אחר כך טבלת ה-NAT עם iptables -t nat -L POSTROUTING -n -v, ואז רשומת ה-conntrack של הזרימה שאתם בודקים. החזיקו פקודת שחזור או ניקוי מתוזמן כל עוד העבודה נמשכת. כל קריאה צריכה -w, אחרת שני מנהלים יתנגשו במנעול של xtables. שום דבר מזה אינו רשות בחלון שינוי.

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