Frage iptables protokolliert den WAN-Verkehr nicht?


Lassen Sie mich zunächst mein endgültiges Ziel nennen: Wenn der Datenverkehr über eine bestimmte IP-Adresse erfolgt, schalten Sie ihn mit Wake On Lan ein, wenn der Server nicht eingeschaltet ist. Ich benutze einen TP-Link Archer C7 v2 Router mit DD-WRT installiert mit Build r30709.

  • WOL arbeitet
  • Protokollieren des LAN-Datenverkehrs über den Port funktioniert (über die iptables-Regel)
  • Ping-Server vom Skript, um festzustellen, ob nach dem Analysieren für benutzerdefinierte Protokolleintrag aktiviert ist
  • Senden von WOL funktioniert von Skript
  • Protokollierung des WAN-Datenverkehrs NICHT arbeiten (über iptables-Regel)

Nach dem, was ich über DD-WRT gesehen habe, scheinen viele Leute VLANs zu erstellen, wenn sie so etwas tun. Mein Router basiert auf Atheros, und DD-WRT unterstützt angeblich kein VLAN für Atheros-Router, obwohl viele Leute es anscheinend auf diesem Router funktionieren ließen (sie stellen keine Anweisungen online).

Also suche ich gerade nach einer Möglichkeit, den Port auf dem Router einzurichten, an den der Server in seinem eigenen VLAN angeschlossen ist, aber bisher kein Glück.

Hier sind meine zwei iptables Regeln:

#this works
iptables -I FORWARD -i br0 -p tcp --dport 32400 -m state --state NEW -j LOG --log-prefix "PLEX LAN Connection "

# this does not work 
iptables -I FORWARD -i eth0 -p tcp --dport 32400 -m state --state NEW -j LOG --log-prefix "PLEX WAN Connection "

# this does not work either (dd-wrt.com says vlan2 is the WAN interface)
iptables -I FORWARD -i vlan2 -p tcp --dport 32400 -m state --state NEW -j LOG --log-prefix "PLEX WAN Connection "

Ist das etwas, das mit nur iptables korrigiert werden kann? Weil ich Iptables nicht bekommen kann, um eingehende WAN-Verbindungen auf diesem Port zu / var / log / messages zu protokollieren. Ich nahm an, dass es nicht in das Protokoll geschrieben hat, weil es nicht auf seinem eigenen VLAN sitzt.

Update 1

Bitte beachte, ich habe es versucht eth0 Anstatt von vlan2, aber das gleiche Ergebnis: Nada im Protokoll. Ich habe sogar entfernt -i <interface> alle zusammen in beiden Regeln, aber nie etwas im WAN-Verkehr.

root@DD-WRT:~# ip a
root@DD-WRT:~# ip ro
default via pu.bl.ic.1 dev eth0
pu.bl.ic.0/24 dev eth0  proto kernel  scope link  src pu.bl.ic.ip
127.0.0.0/8 dev lo  scope link
169.254.0.0/16 dev br0  proto kernel  scope link  src 169.254.255.1
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1

Laut DD-WRT Website, vlan2 soll die logische Schnittstelle für das WAN darstellen.

Update 2

Ich habe festgestellt, dass die Ziel-IP falsch ist. Sollte zu 192.168.1.2 gehen, aber es geht zu 192.168.0.10. Das ist kein gültiges LAN überhaupt:

Oct  4 20:47:35 DD-WRT kern.warn kernel: [114429.460000] PLEX LAN Connection IN=br0 OUT=eth0 MAC=XXXXXXXXXXXXXXXXXXX SRC=192.168.1.133 DST=192.168.0.10 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=45163 DF PROTO=TCP SPT=4644

Versucht dies als einzige Regel pro Vorschlag unten:

iptables -A FORWARD -p tcp --dport 32400 -m limit --limit 50/min -j LOG --log-prefix "CHECK INTERFACES"

Immer noch nichts im Logbuch; hörte auch auf, LAN-Verbindungen zu protokollieren.

Update 3

root@DD-WRT:/tmp/var/log# iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 2742 packets, 395K bytes)
 pkts bytes target     prot opt in     out     source               destination
   13   764 DNAT       tcp  --  *      *       0.0.0.0/0            pu.bl.ic.ip       tcp dpt:14619 to:192.168.1.2:32400
    0     0 DNAT       icmp --  *      *       0.0.0.0/0            pu.bl.ic.ip       to:192.168.1.1
    4   232 DNAT       tcp  --  *      *       0.0.0.0/0            pu.bl.ic.ip       tcp dpt:22709 to:192.168.1.2:32400
  220 19942 TRIGGER    0    --  *      *       0.0.0.0/0            pu.bl.ic.ip       TRIGGER type:dnat match:0 relate:0

Chain INPUT (policy ACCEPT 30145 packets, 2802K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 253 packets, 21491 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 260 packets, 21863 bytes)
 pkts bytes target     prot opt in     out     source               destination
 1065 67674 SNAT       0    --  *      eth0    192.168.1.0/24       0.0.0.0/0           to:pu.bl.ic.ip
   10   624 MASQUERADE  0    --  *      *       0.0.0.0/0            0.0.0.0/0           mark match 0x80000000/0x80000000

1
2017-10-04 17:23


Ursprung


Können Sie bitte die Ausgabe von hinzufügen ip a und ip ro ? - Sanael
Sie haben keine Schnittstelle namens vlan2, Sie haben nur 3 Schnittstellen, eth0, lo und br0. Das Flag -i auf iptables funktioniert nur mit diesen 3, es sei denn, Sie erstellen mehr. Ihre öffentliche Schnittstelle ist eth0, wie Sie den aktualisierten Routing-Informationen entnehmen können. - Andrew Domaszek
Einverstanden. Deshalb habe ich angefangen mit eth0 auf der -i Flagge. Aber das hat nichts getan. Lesen der dd-wrt Website, erwähnen sie mehrmals vlan2 ist die logische WAN-Schnittstelle. Also habe ich es versucht. Aber wieder war / war meine ursprüngliche Regel -i eth0. Ich werde den Beitrag aktualisieren, um das zu reflektieren. - Nathan
Ich würde es versuchen iptables - A FORWARD -p tcp --dport 32000 -m limit --limit 50/min -j LOG --log-prefix "CHECK INTERFACES"  um zu sehen, welche Schnittstelle als WAN verwendet wird. Sie brauchen den neuen Status nicht zu diagnostizieren. Dann tail -f -n 50 /var/log/messages oder so. - Sanael
Das Problem liegt also im Routing-Teil. Könnten Sie die Ausgabe von iptables -t nat -L -n -v und verifizieren, dass der Client das Paket nicht an die falsche IP sendet? Obwohl das Ziel im Subnetz 192.168.1.0/24 liegt, wird der Verkehr nicht über eth0, sondern über br0 geführt. - Sanael


Antworten:


Ich kann keinen Kommentar zum Superuser hinzufügen, also ist es eine Antwort. Können Sie bestätigen, dass der Dienst funktioniert, unabhängig davon, auf welches LAN oder WAN Sie zugreifen?

Verwenden Sie ein iptables-Skript oder führen Sie Ihren Befehl einfach in bash aus? Wenn Sie kein iptables-Skript haben, wie Cybernard gesagt hat, müssen Sie sicherstellen, dass Ihre LOG-Zeile vor der ACCEPT-Zeile steht.

Sobald ein Paket ACCEPTED oder DROPPED ist, verlässt es die Kette und wird daher niemals mit der Protokollregel übereinstimmen, die später in der Kette liegt.

Um beispielsweise Ihre LOG-Regel als erste in die FORWARD-Kette einzufügen:

iptables -I FORWARD 1 -p tcp --dport 32400 -m limit --limit 50/min -j LOG --log-prefix "CHECK INTERFACES"

1
2017-10-05 08:31



Ja, der Service funktioniert einwandfrei. Es ist ein Plex Medienserver. Ich habe einen manuellen Port auf meinem Router eingerichtet und aktiviert uPNP, so dass es automatisch konfiguriert wird. Der Service funktioniert super. Soweit die Iptables-Regel. Ich habe es über das DD-WRT admin -> commands Fenster hinzugefügt und auf save firewall geklickt. Die einzige Firewall-Regel dort ist die, die in dieser Antwort gepostet wird. Wenn ich in meinem LAN WLAN verbunden bin, loggt sich Ihre Regel perfekt. Wenn ich WLAN deaktiviere und meinen Handy-Service nutze. Plex funktioniert immer noch gut, aber ich bekomme keine Protokollierung. Ich denke, dass DD-WRT schuld ist und ich muss wechseln. - Nathan
Aus welchem ​​Grund auch immer, der Wechsel zu OpenWRT von DD-WRT hat dies funktioniert. Die Regeln waren korrekt, nur etwas mit DD-WRT. - Nathan


Bitte beachten Sie, dass die IP auf der WAN-Schnittstelle sein wird vor dem nat der Router könnte also das Ziel sein, selbst wenn das Paket weitergeleitet wird. Das würde ich tun:

iptables -I INPUT -p any -i <wan interface> -j LOG --log-prefix "FIREWALL-WAN"
iptables -I FORWARD -p any -i <wan interface> -j LOG --log-prefix "FIREWALL-WAN"

wo ist die Schnittstelle mit der Wan IP. Normalerweise trage ich einfach einen Wan-Traffic und erlaube dann, was ich will, also würde ich das eigentlich nicht tun.


0
2018-04-25 09:17