Blockieren Sie mit DD-WRT sämtliche WAN-Zugriffe auf die Wi-Fi-Schnittstelle

Blockieren Sie mit DD-WRT sämtliche WAN-Zugriffe auf die Wi-Fi-Schnittstelle

Ich habe einen DD-WRT-Router mit zwei WLAN-Schnittstellen ( ath0, ath1). Ich möchte, dass alles, was eingeschaltet ist, ath0keinerlei WAN-Zugriff hat. Nur LAN (zum und vom Gerät).

Wie mache ich das am einfachsten und stabilsten?

Zuvor habe ich dies auch mit ath1 versucht, indem ich einen virtuellen AP, eine neue Bridge für den AP und einige erweiterte Routing- und Firewall-Einstellungen hinzugefügt habe. Das war jedoch zu kompliziert und ich dachte, es sollte viel einfacher sein, einfach meine ohnehin unbenutzte ath0(5 GHz) Schnittstelle für diesen Zweck zu verwenden.

Ich verwende OpenVPN als Client, was die Sache etwas komplizierter macht. Wenn ich die iptables-Firewall mit dem alten Ansatz verwende, muss ich die Firewall-Einstellungen immer manuell zurücksetzen, da eine Datei in /etc/ meine Regeln ( -Iganz oben) wegen des VPN überschreibt und allem WAN-Zugriff erlaubt, solange es über das VPN geht. Wegen SquashFS konnte ich keine Möglichkeit finden, das zu verhindern, und es ist nicht so schön, es nach dem Speichern der Einstellungen/Neustart des Routers immer manuell überschreiben zu müssen. Außerdem bin ich mir nicht sicher, ob es die Datei nicht später erneut überschreibt.

Ich möchte ath0auch keinen VPN-Zugriff haben. Ich kann iptables nicht mit einer Quell-IP verwenden, da dies für alle Clients auf dieser SSID/Schnittstelle gelten sollte, sobald sie eine Verbindung herstellen. Daher kenne ich eine IP nicht wirklich im Voraus.

Ich habe versucht, dies nachzuschlagen, konnte aber außer der übermäßig fortgeschrittenen virtuellen AP/Bridge-Lösung nichts finden, was in meinem Fall funktionieren würde.

Antwort1

Angenommen, Sie haben zusätzlich zu auf dem Router auch ebtables(oder ) und alle (W)LAN-Schnittstellen sind Bridge-Slaves zum selben Master (sagen wir mit dem Namen ):ebtables-nftiptablesbridge0

ebtables -I INPUT -i ath0 -j mark --set-mark 0xabcd
iptables -I FORWARD -i bridge0 -m mark --mark 0xabcd -j DROP

(Beachten Sie, dass der Markierungswert 0xabcdbeliebig ist.)

Dies führt dazu, dass der gesamte Datenverkehr, der von der „LAN-Seite“ in den Router gelangt, „innerhalb“ der Broadcast-Domäne „bleibt“. Der Grund dafür ist, dass ebtablesINPUTDatenverkehr, der von einem Bridge-Slave/Port zu einem anderen geht (d. h. L2-Weiterleitung), nicht eingeschlossen ist. Und was den Router selbst anvisiert (was von dort kommt ath0und daher markiert ist), möchten wir nicht auf L3 weiterleiten (d. h., um von „LAN“ zu „WAN“/VPN/... gehen zu können).

Alternativ können Sie es auch tun, ohne sich auf iptables oder Paketmarkierung zu verlassen:

ebtables -I INPUT -i ath0 -d Unicast -p ip ! --ip-dst $ROUTER_LAN_IP -j DROP

Obwohl nicht getestet, -d Unicastsoll DHCP beibehalten werden und somit funktionieren. Wenn Sie auch IPv6 benötigen (Verkehrfür den Router auf L3), damit es funktioniert, brauchen/möchten Sie wahrscheinlich eine zusätzliche Kette für weitere Ausnahmen (die es Ihnen ermöglicht, DHCP auch mit einem anderen Ansatz zuzulassen), wie etwa:

ebtables -N ATH0
ebtables -A ATH0 -p ip --ip-dst $ROUTER_LAN_IP -j ACCEPT # unicast
ebtables -A ATH0 -p ip --ip-dport 67 -j ACCEPT # broadcast
ebtables -A ATH0 -p ip ... -j ACCEPT
...
ebtables -A ATH0 -p ip6 ... -j ACCEPT
...
ebtables -A ATH0 -j DROP
ebtables -I INPUT -i ath0 -j ATH0

Aber wie Sie sehen, ist der letztere Ansatz viel umständlicher.

PS: Ich habe keinerlei Erfahrung mit WRTs oder ähnlichem, daher habe ich keine Ahnung, wie man Xtables-Regeln auf ihnen dauerhaft machen soll. (Um fair zu sein, meines Wissens ist es jedoch sowieso distributionsspezifisch, sogar bei „typischen“ Linux-Distributionen.)

verwandte Informationen