iptables blockt Verkehr nicht

[monumentum]

Hallo zusammen,

ich richte derzeit ein kleines System bei mir zu Hause ein, welches darauf basiert, dass mehrere VLANs existent sind. Dazu findet auch ein managed Switch seine Anwendung.

Kurz und knapp: auf VLAN 10 hängt das WAN, und die Verteilung auf zwei Interfaces hängt einzig und allein mit Lastverteilung zusammen. Am besten erklärt das meine /etc/network/interfaces:

Code: Alles auswählen

root@srv01:~# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0.10
iface eth0.10 inet dhcp

auto eth0.11
iface eth0.11 inet static
        address 172.20.10.1
        netmask 255.255.255.0

auto eth1.1
iface eth1.1 inet static
        address 10.192.168.1
        netmask 255.255.255.0

auto eth1.20
iface eth1.20 inet static
        address 192.168.15.1
        netmask 255.255.255.0

Das funktioniert, so denke ich, auch wie erwartet - es ergibt sich daraus folgende Interface-Auflistung:

Code: Alles auswählen

root@srv01:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0a:e4:80:bd:5e brd ff:ff:ff:ff:ff:ff
    inet6 fe80::20a:e4ff:fe80:bd5e/64 scope link
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0a:e4:80:bd:5f brd ff:ff:ff:ff:ff:ff
    inet6 fe80::20a:e4ff:fe80:bd5f/64 scope link
       valid_lft forever preferred_lft forever
4: eth0.10@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 00:0a:e4:80:bd:5e brd ff:ff:ff:ff:ff:ff
    inet 10.0.14.200/16 brd 10.0.255.255 scope global eth0.10
       valid_lft forever preferred_lft forever
    inet6 fe80::20a:e4ff:fe80:bd5e/64 scope link
       valid_lft forever preferred_lft forever
5: eth0.11@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 00:0a:e4:80:bd:5e brd ff:ff:ff:ff:ff:ff
    inet 172.20.10.1/24 brd 172.20.10.255 scope global eth0.11
       valid_lft forever preferred_lft forever
    inet6 fe80::20a:e4ff:fe80:bd5e/64 scope link
       valid_lft forever preferred_lft forever
6: eth1.1@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 00:0a:e4:80:bd:5f brd ff:ff:ff:ff:ff:ff
    inet 10.192.168.1/24 brd 10.192.168.255 scope global eth1.1
       valid_lft forever preferred_lft forever
    inet6 fe80::20a:e4ff:fe80:bd5f/64 scope link
       valid_lft forever preferred_lft forever
7: eth1.20@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 00:0a:e4:80:bd:5f brd ff:ff:ff:ff:ff:ff
    inet 192.168.15.1/24 brd 192.168.15.255 scope global eth1.20
       valid_lft forever preferred_lft forever
    inet6 fe80::20a:e4ff:fe80:bd5f/64 scope link
       valid_lft forever preferred_lft forever

Soweit, so gut. Im nächsten Schritt wollte ich mich nun um Masquerading kümmern, allerdings hielt mich davon ab, dass meine Firewallkonfiguration nicht funktioniert. Wenn ich einen Ping auf 10.0.14.200 von "extern", also über das WAN starte, dann wird das erste Paket beantwortet, was sich auf dem pingenden, externen System und durch einen laufenden "tcpdump -i eth0.10 icmp" nachweisen lässt. Ab dann folgende Pings werden nicht beantwortet, sind aber dennoch im tcpdump sichtbar. Ich vermute, dass diese im tcpdump sichtbar sein sollen, und quasi nach tcpdump herausgefiltert werden, allerdings erschließt sich mir nicht, warum immer nur das erste Paket eines Pings beantwortet wird - theoretisch dürfte keines beantwortet werden.

Oder habe ich da einen Fehler in meiner Firewallkonfiguration, die folgt?

Code: Alles auswählen

root@srv01:~# iptables-save
# Generated by iptables-save v1.4.21 on Mon Oct 19 19:49:46 2015
*filter
:INPUT DROP [602:239512]
:FORWARD DROP [13:1128]
:OUTPUT ACCEPT [830:64472]
-A INPUT -i eth0.11 -j ACCEPT
-A INPUT -i eth1.20 -j ACCEPT
-A INPUT -i eth1.1 -j ACCEPT
COMMIT
# Completed on Mon Oct 19 19:49:46 2015

Wenn da jemand eine Idee hat, würde mich das freuen.

Viele Grüße,
monu

[gbotti]

Hi.

Nur damit ich keine Denkfehler habe:

- Du startest den Ping auf 10.0.14.200 von einem Rechner im 10.0.14.0/16-Subnetz, also Beispielsweise 10.0.14.201?
- Der den Ping ausführende Rechner ist mit lediglich einem Netzwerkinterface in dem 10.0.14.0/16-Subnetz?
- Hast du schon mal probiert die default policies auf DROP zu stellen und keine Rules für die eth0.X zu definieren, also den Rechner quasi komplett abzuschotten?

[monumentum]

Hallo,

deine Ausführungen sind korrekt. Der Ping kommt von einer "externen" Maschine aus dem Subnet 10.0.14.0/16. Der pingende Rechner hat nur ein Netzwerkinterface mit exakt dieser IP, keiner weiteren. Die default Policy steht bereits auf DROP (wie ja in der iptables-save zu sehen), und ohne irgendwelche weiteren Regeln funktioniert das auch.

[gbotti]

Bau mal in den IPTables-Regeln noch die Source-IP ein.

[monumentum]

Hallo,

wie meinst Du das? Welche Source-IP soll ich wie umbauen? Die Source-IP des externen Hosts, der pingt? Wenn ja, zu was soll ich die umbauen?

[gbotti]

Hallo,

wie meinst Du das? Welche Source-IP soll ich wie umbauen? Die Source-IP des externen Hosts, der pingt? Wenn ja, zu was soll ich die umbauen?

Momentan steht in der Rule:

Code: Alles auswählen

-A INPUT -i eth0.11 -j ACCEPT

Das heißt, du hast "lediglich" das Interface benannt.

Mach mal zum Test Beispielsweise:

Code: Alles auswählen

-A INPUT -i eth0.11 -s 172.20.10.0/24 -j ACCEPT
-A INPUT -i eth1.20 -s 192.168.15.0/24 -j ACCEPT
-A INPUT -i eth1.1 -s 10.192.168.0/24 -j ACCEPT

Nicht dass mit dem Tagging faul ist...