חומת האש של ההוטספוט שלך חוסמת DHCP לפני ההקצאה

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

צפו בלקוח שמצטרף

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

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

מה באמת מכילה החבילה הראשונה

RFC 2131 קובע ששידורי ה-DHCP של לקוח לפני קבלת כתובת משתמשים בכתובת מקור אפס. הודעות מהלקוח לשרת נשלחות לפורט UDP 67, והודעות מהשרת ללקוח לפורט UDP 68. לכן הגילוי מגיע עם 0.0.0.0 כמקור, וכלל שדורש מקור בתוך תת-הרשת של הלקוחות שלך פשוט לא תואם לו.

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

איזה נתיב באמת מטפל בזה

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

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

מתכון כללי לקלט ופלט שהועתק מפורום אינו הוכחה שהמימוש שלך עובר את השרשראות האלה באותו אופן.

התשובה היא לא תמיד שידור

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

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

תקנו בצורה צרה ואז בדקו את השאר

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

ריקון טבלה אינו שלב בתצורת DHCP. ב-iptables הפקודה flush מוחקת כללים מהשרשרת או מהטבלה שנבחרה, וריקון טבלת ה-NAT לא יוצר כלל תרגום. הגדרת מדיניות ACCEPT רחבה מסירה הגנה שאינה קשורה להקצאה, ולכן אף אחת מהן אינה שייכת לתיקון הוטספוט לשימוש חוזר.

לאחר שלקוח מחזיק הקצאה, בדקו DNS, העברה ויציאה דרך ה-VPN כמשימות נפרדות. הקצאה קובעת כתובות מקומיות ולא יותר מזה.