Đầu tiên, tôi biết rằng những câu hỏi tương tự như câu hỏi của tôi đã được hỏi ở nơi khác (tôi đã đọc nhiều bài đăng đó!) nhưng tôi không thể tìm ra giải pháp cho vấn đề của mình, vì vậy tôi đang nhờ trợ giúp.
thiết lập của tôi
Tôi có hai mạng trên mạng LAN của mình, 192.168.0.0/24 và 10.11.12.0/24. Cái trước có DHCP chạy trên bộ định tuyến WAN của tôi, cái sau chạy dnsmasq trên Ubuntu Server 20.04 trên một hộp cũng đóng vai trò là bộ định tuyến giữa hai mạng con. Tôi đã định cấu hình dnsmasq để chỉ phục vụ DHCP trên mạng 10.11.12.0/24 với tùy chọn no-dhcp-interface=wlp3s0, wlp3s0 là giao diện ở phía 192.168.0.0/24.
Để tóm tắt:
Bộ định tuyến WAN (cổng vào WAN) là 192.168.0.1/24
Chạy DHCP cho máy khách trên 192.168.0.0/24
Bộ định tuyến (b/w mạng con):
Ubuntu Server 20.04 với hai giao diện
wlp3s0: 192.168.0.2/24 (IP tĩnh)
eno1: 10.11.12.1/24 (IP tĩnh)
Tôi đã định cấu hình iptables thành FWD và NAT như vậy.
iptables -t nat -A POSTROUTING -o wlp3s0 -j MASQUERADE
iptables -A FORWARD -i wlp3s0 -o eno1 -m state --state LIÊN QUAN, THÀNH LẬP -j CHẤP NHẬN
iptables -A FORWARD -i eno1 -o wlp3s0 -j CHẤP NHẬN
Tôi đã cho phép DHCP thông qua tường lửa của mình với ufw cho phép 67/udp:
Đến hành động từ
-- ------ ----
67/udp CHO PHÉP Ở Mọi Nơi
Mọi thứ dường như đang hoạt động tốt. Tuy nhiên, từ kinh nghiệm, tôi biết rằng việc chạy hai máy chủ DHCP như thế này có thể gây ra xung đột trừ khi chúng được tách biệt hoàn toàn. (Các máy khách dành cho mạng 192.168.0.0/24 sẽ không hài lòng lắm nếu DHCP cấp cho họ một địa chỉ IP trên mạng 10.11.12.0/24!)
Phát hiện vấn đề
Vì vậy, tôi đã làm như sau để kiểm tra nó.Tôi đã thiết lập trình nghe tcpdump trên giao diện wlp3s0 (192.168.0.2) và sử dụng nmap để mô phỏng yêu cầu Khám phá DHCP bắt nguồn từ giao diện eno1 (10.11.12.1/24), như sau:
sudo tcpdump -i wlp3s0 -n udp cổng 67 hoặc cổng 68
sudo nmap --script Broadcast-dhcp-Discover -e eno1
Đúng như dự đoán, tôi nhận được ưu đãi DHCP từ dnsmasq chạy trên 10.11.12.1. Càng xa càng tốt!
Một số chi tiết bị bỏ qua khỏi đầu ra cho ngắn gọn (anh ấy nói)
Bắt đầu từ Nmap 7.80 ( https://nmap.org ) lúc 22-12-2021 16:19 UTC
Kết quả tập lệnh quét trước:
| phát sóng-dhcp-khám phá:
| Trả lời 1 trên 1:
| IP được cung cấp: 10.11.12.53
| Loại tin nhắn DHCP: DHCPOFFER
| Mã định danh máy chủ: 10.11.12.1
| Địa chỉ phát sóng: 10.11.12.255
| Mặt nạ mạng con: 255.255.255.0
| Máy chủ tên miền: 10.11.12.1
|_ Bộ định tuyến: 10.11.12.1
Tuy nhiên, tcpdump cho thấy rằng cả hai máy chủ DHCP đều phản hồi yêu cầu khám phá. (Thực tế, bộ định tuyến WAN của tôi gửi 2 phản hồi!)
16:19:43.517029 IP 10.11.12.1.68 > 255.255.255.255.67: BOOTP/DHCP, Yêu cầu từ de:ad:c0:de:ca:fe, độ dài 316
16:19:46.486227 IP 10.11.12.1.67 > 255.255.255.255.68: BOOTP/DHCP, Trả lời, độ dài 321
16:19:46.794207 IP 192.168.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Trả lời, độ dài 323
16:19:46.794207 IP 192.168.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Trả lời, độ dài 323
Có vẻ như yêu cầu khám phá DHCP được chuyển tiếp tới mạng 192.168.0.0/24 thông qua giao diện wlp3s0. Nhìn vào các quy tắc tường lửa và iptables của tôi, tôi thấy không có lý do gì để ngạc nhiên về điều này. Tuy nhiên, điều tôi thực sự gặp khó khăn là tìm ra cách ngăn chặn nó.
Những gì tôi đã thử
Tôi đã thử nhiều hoán vị quy tắc khác nhau trong cả ufw và iptables nhưng không có kết quả, có thể là do tôi không hiểu hết về iptables hoặc ufw. Một vài ví dụ về những gì tôi đã thử:
(Tất cả các quy tắc ufw/iptables đã được thêm vào đầu bộ quy tắc/chuỗi tương ứng để đảm bảo chúng bị tấn công.)
ừm:
# Hạn chế 67/udp cho một giao diện
ufw cho phép trên eno1 proto udp từ 0.0.0.0/0 đến 0.0.0.0/0 cổng 67
# Từ chối định tuyến
tuyến đường ufw từ chối trên eno1 trên wlp3s0 đến 0.0.0.0/0 cổng 67 proto udp
iptables:
# Ngăn chuyển tiếp cổng UDP 67/68
iptables -I FORWARD 1 -p udp --match multiport --dports 67,68 -j DROP
# Hủy cổng UDP gửi đi 67
iptables -I OUTPUT 1 -p udp --match multiport --dports 67,68 -o wlp3s0 -j DROP
Tôi phải thiếu một số hiểu biết cơ bản về cách thức hoạt động của nó vì không có điều nào ở trên ngăn DHCP của bộ định tuyến WAN nhận khám phá và cung cấp IP trên mạng con 192.168.0.0/24.
Tôi đã đọc ở đâu đó rằng các máy chủ DHCP có thể lắng nghe trên ổ cắm thô (hoặc gói?), Ổ cắm này không tuân theo iptables. Đó không phải là trường hợp của dnsmasq như được ghi lại ở đây https://github.com/imp/dnsmasq/blob/master/FAQ#L195. Tôi cũng đã chứng minh điều đó bằng cách xóa quy tắc cho phép 67/udp trong ufw, sau đó dnsmasq ngừng phản hồi DHCP phát hiện. Có lẽ đáng ngạc nhiên (hoặc không), ngay cả khi quy tắc cho phép bị xóa trong ufw, bộ định tuyến WAN của tôi vẫn tiếp tục nhận và phản hồi khám phá DHCP. Có lẽ vì tôi đã định cấu hình quy tắc iptables để chuyển tiếp tất cả lưu lượng truy cập, nhưng không có quy tắc INPUT tương đương (cho đến khi tôi thêm một quy tắc bằng cách sử dụng ufw).
Những gì tôi muốn đạt được
Tốt nhất là tôi muốn ngăn phát hiện DHCP trên mạng 10.11.12.0/24 thậm chí không đến được mạng 192.168.0.0/24.
Nếu điều đó tỏ ra khó khăn, tôi rất sẵn lòng ngăn các ưu đãi DHCP từ bộ định tuyến WAN của tôi tiếp cận mạng 10.11.12.0/24.
Lưu ý rằng tôi không gặp sự cố trên mạng 192.168.0.0/24 vì tôi đã định cấu hình dnsmasq để không cung cấp DHCP trên giao diện wlp3s0 (192.168.0.2). Điều đó dường như đang hoạt động và DHCP khám phá trên wlp3s0 (192.168.0.2/24) không nhận được phản hồi từ dnsmasq.
Vì vậy, những gì tôi đang thiếu? Tôi đang nói về điều này hoàn toàn sai hay tôi chỉ không hiểu nó hoàn toàn đúng? Bất kỳ sự giúp đỡ nào cũng được đánh giá cao.
Chúc ngày lễ vui vẻ!
Cập nhật
Để trả lời câu hỏi trong nhận xét từ @sleepyhead, đây là thiết lập tự nhiên iptables của tôi.
PREROUTING chuỗi (chính sách CHẤP NHẬN 13452 gói, 4312K byte)
pkts byte đích prot chọn không tham gia đích nguồn
Chuỗi INPUT (chính sách CHẤP NHẬN 48 gói, 12715 byte)
pkts byte đích prot chọn không tham gia đích nguồn
ĐẦU RA chuỗi (chính sách CHẤP NHẬN 87 gói, 10884 byte)
pkts byte đích prot chọn không tham gia đích nguồn
Chuỗi POSTROUTING (chính sách CHẤP NHẬN 55 gói, 8622 byte)
pkts byte đích prot chọn không tham gia đích nguồn
32 2262 MẶT MẠO tất cả -- * wlp3s0 0.0.0.0/0 0.0.0.0/0
cập nhật 2
Có thể đây là một vật phẩm về cách tôi tiến hành thử nghiệm của mình không? Điều khiến tôi nghi ngờ là IP nguồn của đầu ra tcpdump. Có thể chạy DHCP Discover trên giao diện đã có IP tạo ra kết quả khác so với khi không có? Dù sao, nếu tôi có thể tái sử dụng một trong những chiếc Raspberry Pi của mình, tôi sẽ chạy thử nghiệm này với nó dưới dạng ứng dụng khách DHCP và xem liệu tôi có nhận được kết quả tương tự hay không, mặc dù tôi nghi ngờ là mình sẽ làm được.
