თქვენი ჰოტსპოტის ფაირვოლი 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-ის გამოსავალი ცალკეულ ამოცანებად. იჯარა ამყარებს ლოკალურ მისამართებს და მეტს არაფერს.