Ձեր հոթսփոթի հրդեհային պատը արգելափակում է 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 ելքը որպես առանձին առաջադրանքներ։ Վարձակալությունը սահմանում է տեղական հասցեավորում և ոչ ավելին։