Tường lửa hotspot của bạn chặn DHCP trước khi cấp thuê

Một điện thoại mới kết nối vào hotspot của bạn, không hiển thị địa chỉ và không bao giờ nhận được. Điểm truy cập vẫn ổn, tiến trình DHCP đang chạy, và quy tắc tường lửa bạn viết có vẻ khớp với kế hoạch địa chỉ. Nhưng điều nó thực sự làm là yêu cầu máy khách đã có sẵn địa chỉ mà nó đang xin. Gói DHCP đầu tiên không có địa chỉ nào cả, nên quy tắc không bao giờ kích hoạt.

Theo dõi một máy khách kết nối

Theo dõi một liên kết từ phía máy khách. Radio liên kết, máy khách gửi khám phá DHCP, máy chủ đề nghị, máy khách yêu cầu, máy chủ xác nhận, và chỉ khi đó máy khách mới có địa chỉ dùng được cho việc khác.

Mọi thứ trước xác nhận cuối cùng đó diễn ra trong khi máy khách không thể dùng cổng cho lưu lượng thông thường. Đó chính là khoảng thời gian mà quy tắc subnet quên mất.

Gói đầu tiên thực sự chứa gì

RFC 2131 quy định rằng các gói quảng bá DHCP của máy khách trước khi có địa chỉ dùng địa chỉ nguồn bằng không. Thông điệp từ máy khách đến máy chủ đi tới cổng UDP 67, và từ máy chủ đến máy khách tới cổng UDP 68. Vì vậy gói khám phá đến với 0.0.0.0 là nguồn, và quy tắc yêu cầu nguồn nằm trong subnet máy khách của bạn đơn giản là không khớp với nó.

Đây không phải là cấu hình sai từ phía máy khách. Đây là giao thức hoạt động đúng như thiết kế, trong khoảng thời gian duy nhất mà nó có thể.

Đường dẫn nào thực sự xử lý việc này

Nếu điểm truy cập tự cấp thuê, đây là cuộc trò chuyện dịch vụ cục bộ, và trên đường dẫn cục bộ được lọc theo IP thì nó liên quan đến chính sách vào và ra. Lưu lượng máy khách được chuyển tiếp qua VPN là một quyết định khác, và NAT cho lưu lượng đó lại là chuyện khác nữa. Gộp ba thứ này lại chính là cách một ngoại lệ hẹp trở thành rộng.

Nơi gói được xử lý phụ thuộc vào tiến trình và họ tường lửa đang dùng. Các triển khai socket thô, cấu hình cầu nối và các móc lọc trước đó có thể chuyển hoặc chặn nó ở một nơi hoàn toàn khác. Hãy xác nhận ràng buộc giao diện của tiến trình và các móc đang hoạt động trước khi thêm quy tắc.

Một công thức vào và ra chung chép từ diễn đàn không phải bằng chứng rằng triển khai của bạn đi qua các chuỗi đó theo cùng cách.

Phản hồi không phải lúc nào cũng là quảng bá

Một ngoại lệ chỉ cho phép phản hồi quảng bá cũng sai. Đích của phản hồi DHCP phụ thuộc vào trạng thái máy khách và các trường của thông điệp, và giao thức quy định cả trường hợp quảng bá lẫn đơn hướng. Nếu máy chủ của bạn phản hồi đơn hướng tới một địa chỉ mà nó sắp cấp, quy tắc chỉ dành cho quảng bá sẽ chặn bước hoàn tất công việc. Hãy viết quy tắc theo đúng trao đổi mà máy chủ đã cấu hình thực sự thực hiện.

Các lần gia hạn thuê sau này lặp lại trao đổi ở trạng thái khác, nên hãy chừa chỗ cho chúng chứ không chỉ cho lần kết nối đầu tiên.

Sửa hẹp, rồi kiểm tra phần còn lại

Giữ chính sách hiện có, tìm quyền DHCP còn thiếu và giới hạn nó ở giao diện hướng tới máy khách, giao thức và hai cổng. Chứng minh yêu cầu đến được dịch vụ, rồi chứng minh dịch vụ phản hồi. Đó là hai quan sát khác nhau, và cấu hình dịch vụ hoặc nhóm địa chỉ vẫn có thể sai sau lớp lọc hoàn hảo.

Xóa bảng không phải là bước cấu hình DHCP. Trong iptables, flush xóa các quy tắc khỏi chuỗi hoặc bảng đã chọn, và xóa bảng NAT không tạo ra quy tắc dịch địa chỉ. Đặt chính sách ACCEPT rộng sẽ bỏ đi lớp bảo vệ không liên quan đến việc cấp thuê, nên cả hai đều không thuộc về một bản sửa hotspot dùng lại được.

Khi máy khách đã có thuê, hãy kiểm tra DNS, chuyển tiếp và lối ra VPN như những nhiệm vụ riêng. Thuê chỉ thiết lập địa chỉ cục bộ và không hơn thế.