Ronny Seffner <ro...@seffner.de> (Sa 03 Mär 2018 00:04:27 CET): > Die /etc/network/interfaces führt den SDSL wie folgt > > iface eth0 inet static > address 5.6.7.8 > netmask 255.255.255.0 > gateway 5.6.7.254 > > und den ADSL so > > iface eth3 inet static > address 1.2.3.4 > netmask 255.255.255.0 > post-up ip route add default via 1.2.3.254 dev eth3 table adsl > post-up ip rule add fwmark 2 table adsl > post up ip rule add from 1.2.3.4 table adsl > > Dazu muss nun die /etc/iproute2/rt_tables folgendes enthalten > > 2 adsl > > Ich habe der mangle Tabelle von iptables (noch?) nichts hinzugefügt. > In der nat Tabelle hingegen gibt es: > > -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE #mask für LAN2WAN am > SDSL-Interface > -A PREROUTING -d 5.6.7.8 -i eth0 -p tcp --dport 443 -j DNAT --to-destination > 192.168.0.11:443 #https SDSL WAN2GW ins LAN > -A PREROUTING -d 1.2.3.4 -i eth3 -p tcp --dport 443 -j DNAT --to-destination > 192.168.0.11:443 #https ADSL WAN2GW ins LAN > > Nun funktioniert (iptables Policy DROP, paar mehr Regeln, logging an, hoffe … > > Was mir nicht einleuchtet: > - WAN to ADSL https ist mit tcpdump noch an eth3 eingehen zu beobachten aber > ... > - das DNAT müsste dazu führen, dass ich am LAN interface den traffic sehe, > tue ich im Gegensatz zum SDSL aber nicht > - meine letzten iptables Regelen sind Logeregeln, die zeichnen davon nix auf > > Dass ich mit tcpdump vom DNAT nichts am LAN interface sehe, wenn ich ADSL > anspreche, kann doch erstmal nur am Routing liegen oder? Was verdammt > nochmal übersehe ich gerade?
Hast du *.rp_filter an?
sysctl -ar '*.rp_filter'
Wenn ja, dann wäre es vielleicht erklärbar. Bin mir aber nicht sicher,
ob dann nicht sogar schon der eingehende Traffic auf eth3 nicht zu sehen
wäre. Unabhängig davon, probiere mal
sysctl net.ipv4.conf.all.log_martians=1
Denn, das, was da über eth3 reinkommt, erzeugt doch Antwort-Pakete, die
über eth0 wieder raus wöllten, oder?
--
Heiko
signature.asc
Description: PGP signature
