În primul rând, sunt conștient că întrebări similare cu ale mele au fost puse în altă parte (am citit multe dintre aceste postări!), dar nu am reușit să găsesc o soluție la problema mea, așa că cer ajutor.
Configurația mea
Am două rețele pe LAN, 192.168.0.0/24 și 10.11.12.0/24. Primul are DHCP care rulează pe routerul meu WAN, cel de-al doilea rulează dnsmasq pe Ubuntu Server 20.04 pe o cutie care servește și ca router între cele două subrețele. Am configurat dnsmasq să servească numai DHCP în rețeaua 10.11.12.0/24 cu opțiunea no-dhcp-interface=wlp3s0, wlp3s0 fiind interfața pe partea 192.168.0.0/24.
A sumariza:
Routerul WAN (gateway la WAN) este 192.168.0.1/24
Rulează DHCP pentru clienți pe 192.168.0.0/24
Router (subrețele alb/n):
Ubuntu Server 20.04 cu două interfețe
wlp3s0: 192.168.0.2/24 (IP static)
eno1: 10.11.12.1/24 (IP static)
Am configurat iptables la FWD și NAT așa.
iptables -t nat -A POSTROUTING -o wlp3s0 -j MASQUERADE
iptables -A FORWARD -i wlp3s0 -o eno1 -m stat --state RELATED,STABLISHED -j ACCEPT
iptables -A FORWARD -i eno1 -o wlp3s0 -j ACCEPT
Am permis DHCP prin firewall-ul meu cu ufw permit 67/udp:
La Acțiune De la
-- ------ ----
67/udp PERMITERE PENTRU Oriunde
Totul pare să funcționeze bine. Cu toate acestea, din experiență știu că rularea a două servere DHCP ca acesta poate provoca conflicte dacă nu sunt păstrate strict separate. (Clienții destinați rețelei 192.168.0.0/24 nu ar fi prea încântați dacă DHCP le-ar da o adresă IP în rețeaua 10.11.12.0/24!)
Descoperirea problemei
Așa că am făcut următoarele pentru a-l testa.Am configurat o ascultare tcpdump pe interfața wlp3s0 (192.168.0.2) și am folosit nmap pentru a simula o solicitare DHCP Discover care provine de pe interfața eno1 (10.11.12.1/24), așa:
sudo tcpdump -i wlp3s0 -n udp portul 67 sau portul 68
sudo nmap --script broadcast-dhcp-discover -e eno1
După cum era de așteptat, primesc o ofertă DHCP de la dnsmasq care rulează pe 10.11.12.1. Până acum, bine!
Unele detalii au fost omise din rezultat pentru concizie (a spus el)
Începând cu Nmap 7.80 ( https://nmap.org ) la 22/12/2021 16:19 UTC
Rezultatele scriptului pre-scanare:
| broadcast-dhcp-discover:
| Răspunsul 1 din 1:
| IP oferit: 10.11.12.53
| Tip mesaj DHCP: DHCPOFFER
| Identificator de server: 10.11.12.1
| Adresa de difuzare: 10.11.12.255
| Mască de subrețea: 255.255.255.0
| Server de nume de domeniu: 10.11.12.1
|_ Router: 10.11.12.1
Cu toate acestea, tcpdump arată că ambele servere DHCP răspund la cererea de descoperire. (De fapt, routerul meu WAN trimite 2 răspunsuri!)
16:19:43.517029 IP 10.11.12.1.68 > 255.255.255.255.67: BOOTP/DHCP, Solicitare de la de:ad:c0:de:ca:fe, lungime 316
16:19:46.486227 IP 10.11.12.1.67 > 255.255.255.255.68: BOOTP/DHCP, Răspuns, lungime 321
16:19:46.794207 IP 192.168.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Răspuns, lungime 323
16:19:46.794207 IP 192.168.0.1.67 > 255.255.255.255.68: BOOTP/DHCP, Răspuns, lungime 323
Se pare că cererea de descoperire DHCP este redirecționată către rețeaua 192.168.0.0/24 prin interfața wlp3s0. Privind la iptables și la regulile mele de firewall, nu văd niciun motiv să fiu surprins de asta. Cu toate acestea, ceea ce mă lupt cu adevărat este să îmi dau seama cum să o prevenim.
Ceea ce am incercat
Am încercat diverse permutări ale regulilor atât în ufw, cât și în iptables, dar fără rezultat, probabil pentru că nu înțeleg pe deplin nici iptables, nici ufw. Câteva exemple din ceea ce am încercat:
(Toate regulile ufw/iptables au fost adăugate în partea de sus a setului de reguli/lanțului respectiv pentru a se asigura că au fost atinse.)
ufw:
# Limitați 67/udp la o singură interfață
ufw permite accesul pe eno1 proto udp de la 0.0.0.0/0 la 0.0.0.0/0 portul 67
# Respinge rutarea
ufw route deny in on eno1 out on wlp3s0 to 0.0.0.0/0 port 67 proto udp
iptables:
# Preveniți redirecționarea portului UDP 67/68
iptables -I FORWARD 1 -p udp --match multiport --dports 67,68 -j DROP
# Renunțați la portul UDP 67 de ieșire
iptables -I OUTPUT 1 -p udp --match multiport --dports 67,68 -o wlp3s0 -j DROP
Trebuie să lipsesc o înțelegere fundamentală a modului în care funcționează acest lucru, deoarece niciuna dintre cele de mai sus nu împiedică routerul WAN DHCP să primească descoperirea și să ofere un IP pe subrețeaua 192.168.0.0/24.
Am citit undeva că serverele DHCP pot asculta pe un socket brut (sau pachet?), care nu este supus iptables. Acesta nu este cazul cu dnsmasq, așa cum este documentat aici https://github.com/imp/dnsmasq/blob/master/FAQ#L195. De asemenea, am demonstrat că ștergând regula allow 67/udp în ufw, după care dnsmasq nu mai răspunde la descoperirea DHCP. Poate în mod surprinzător (sau nu), chiar și cu regula de autorizare ștearsă în ufw, routerul meu WAN continuă să primească și să răspundă la descoperirea DHCP. Probabil pentru că am reguli iptables configurate pentru a redirecționa tot traficul, dar nicio regulă INPUT echivalentă (până când adaug una folosind ufw).
Ce aș dori să obțin
De preferință, aș dori să împiedic ca difuzarea de descoperire DHCP în rețeaua 10.11.12.0/24 să ajungă chiar și la rețeaua 192.168.0.0/24.
Dacă acest lucru se dovedește dificil, aș fi bucuros să împiedic doar ofertele DHCP de la routerul meu WAN să ajungă în rețeaua 10.11.12.0/24.
Rețineți că nu am nicio problemă în rețeaua 192.168.0.0/24, deoarece am configurat dnsmasq să nu ofere DHCP pe interfața wlp3s0 (192.168.0.2). Se pare că funcționează și DHCP Discover pe wlp3s0 (192.168.0.2/24) nu primește un răspuns de la dnsmasq.
Deci ce îmi lipsește? Merg cu totul greșit sau pur și simplu nu înțeleg bine? Orice ajutor este mult apreciat.
Sărbători fericite!
Actualizați
Ca răspuns la o întrebare din comentariile de la @sleepyhead, iată configurarea mea pentru iptables nat.
PRERUUTARE în lanț (politica ACCEPTĂ 13452 pachete, 4312K octeți)
pkts bytes target prot opt in out source destination
INTRARE în lanț (politica ACCEPTĂ 48 de pachete, 12715 octeți)
pkts bytes target prot opt in out source destination
IEȘIRE în lanț (politica ACCEPTĂ 87 pachete, 10884 octeți)
pkts bytes target prot opt in out source destination
POSTROUTING în lanț (politica ACCEPTĂ 55 de pachete, 8622 de octeți)
pkts bytes target prot opt in out source destination
32 2262 MASQUERADE toate -- * wlp3s0 0.0.0.0/0 0.0.0.0/0
Actualizare 2
Este posibil ca acesta să fie un artefact al modului în care îmi conduc testul? Ceea ce mă face suspect este IP-ul sursă al ieșirii tcpdump. Ar putea fi faptul că rularea DHCP Discover pe o interfață care are deja un IP să producă un rezultat diferit decât dacă nu ar avea-o? Oricum, dacă pot reutiliza unul dintre Raspberry Pis-ul meu, voi rula acest test cu el ca client DHCP și voi vedea dacă obțin aceeași ieșire, deși bănuiesc că o voi face.
