Routing Problem

S

Serow

0
Hi,

folgendes Setup:

Host: zoom
IP: 172.16.1.1/24

Host: spiderman
IP: 172.16.1.4/24
IP: 10.0.0.1/24

Wenn ich von zoom zu 172.16.1.4 pinge funktioniert das:

Code: 
mathias@zoom:~$ ping 172.16.1.4 -c 2
PING 172.16.1.4 (172.16.1.4) 56(84) bytes of data.
64 bytes from 172.16.1.4: icmp_seq=1 ttl=61 time=39.8 ms
64 bytes from 172.16.1.4: icmp_seq=2 ttl=61 time=40.3 ms

--- 172.16.1.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 39.866/40.129/40.392/0.263 ms
mathias@zoom:~$

Auf zoom habe ich eine Route in das 10.0.0.0/24 Netz gesetzt:

Code: 
mathias@zoom:~$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
************    88.198.108.17   255.255.255.240 UG    0      0        0 eth0
************    0.0.0.0         255.255.255.240 U     0      0        0 eth0
10.0.0.0        172.16.1.4      255.255.255.0   UG    0      0        0 tun-split-udp
172.16.2.0      0.0.0.0         255.255.255.0   U     0      0        0 tun-full-tcp
172.16.0.0      0.0.0.0         255.255.255.0   U     0      0        0 tun-full-udp
172.16.1.0      0.0.0.0         255.255.255.0   U     0      0        0 tun-split-udp
0.0.0.0         88.198.108.17   0.0.0.0         UG    0      0        0 eth0
mathias@zoom:~$

Scheinbar interessiert ihn meine Route aber nicht die Bohne, denn ein traceroute auf 10.0.0.1 sollte ja zumindest die 172.16.1.4 zeigen oder?

Code: 
mathias@zoom:~$ traceroute -n 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  *^C
mathias@zoom:~$

Ein tcpdump auf spiderman zeigt auch definitiv, dass da nichts ankommt, dh das Problem muss auf zoom liegen. Hier meine Firewall:

Code: 
iptables -P INPUT DROP                                                          # disallow input
iptables -P OUTPUT ACCEPT                                                       # allow output
iptables -P FORWARD DROP                                                        # disallow forwarding

###################################
# INPUT
###################################
iptables -A INPUT -i lo -j ACCEPT                                               # loopback
iptables -A INPUT -i tun+ -j ACCEPT                                             # traffic from vpn clients
source /etc/iptables/block-ranges                                               # lock out china
iptables -A INPUT -i eth0 -p tcp --dport 80 -j ACCEPT                           # apache2
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT                           # openssh
iptables -A INPUT -i eth0 -p tcp --dport 25 -j ACCEPT                           # postfix
iptables -A INPUT -i eth0 -p tcp --dport 993 -j ACCEPT                          # dovecot
iptables -A INPUT -i eth0 -p udp --dport 1194 -j ACCEPT                         # openvpn split
iptables -A INPUT -i eth0 -p udp --dport 1195 -j ACCEPT                         # openvpn full
iptables -A INPUT -i eth0 -p tcp --dport 443 -j ACCEPT                          # openvpn full
iptables -A INPUT -i eth0 -p icmp -j ACCEPT                                     # allow ping
iptables -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT        # allow related traffic

###################################
# FORWARD
###################################
iptables -A FORWARD -i tun+ -o tun+ -j ACCEPT                                   # routing between vpn networkrs
iptables -A FORWARD -i tun+ -o eth0 -j ACCEPT                                   # route vpn networks to the outside
iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT

###################################
# OUTPUT
###################################
iptables -A OUTPUT -o lo -j ACCEPT                                              # loopback
iptables -A OUTPUT -o tun+ -j ACCEPT                                            # traffic to vpn clients

###################################
# POSTROUTING
###################################
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE                    # nat routing from vpn networks to internet

Das was ich da mache match ja quasi auf die zweite Regel von OUTPUT (wobei die Default Policy eh auf ACCEPT ist). Von firewall-seite sollte doch also alles passen oder?

Sieht jemand den Fehler? Ich seh langsam den Wald vor lauter Bäumen nicht mehr :D

ciao
serow
 
traceroute wird dir die 172.16.1.4 erst zeigen, NACHDEM eine entsprechende nachricht vom typ ICMP Time Exceeded, TTL exceeded (ICMP typ 11 code 0) von 172.16.1.4 empfangen wurde

was sagt der interface packet counter von tun-split-udp auf zoom bei ping und traceroute? werden ausgehende pakete registriert?

registriert das betreffende interface auf spiderman eingehende pakete?

wie sieht das routing und die firewall auf seiten von spiderman aus?

ist das forwarding flag auf spiderman gesetzt?
 
Zuletzt bearbeitet:
Hi,

der packet counter wächst. Das sieht man auch mit einem "tcpdump -i tun-split-udp icmp". Auf spiderman hingegen tut sich packet counter technisch auf tun0 nichts.

Die Firewall von spiderman sieht so aus:

Code: 
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD
iptables -t nat -F
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

###################################
# PREROUTING
###################################

###################################
# INPUT
###################################
iptables -A INPUT -i lo -j ACCEPT                                                       # loopback

iptables -A INPUT -i eth0 -j ACCEPT                                                     # allow from local network

iptables -A INPUT -i ppp0 -p icmp -j ACCEPT                                             # ping
iptables -A INPUT -i ppp0 -p tcp --dport 22 -j ACCEPT                                   # openssh
iptables -A INPUT -i ppp0 -p udp --source 217.10.79.9 --dport 5060 -j ACCEPT            # asterisk to sipgate
iptables -A INPUT -i ppp0 -p udp --source 217.10.79.9 --dport 10000:20000 -j ACCEPT     # asterisk to sipgate
iptables -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT                # related

iptables -A INPUT -i tun+ -j ACCEPT                                                     # allow from vpn networks

###################################
# FORWARD
###################################
iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT                                           # local to local
iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT                                           # local to internet
iptables -A FORWARD -i ppp0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT      # internet to local
iptables -A FORWARD -i tun+ -o eth0 -j ACCEPT                                           # vpn networks to local
iptables -A FORWARD -i eth0 -o tun+ -j ACCEPT                                           # local to vpn networks

###################################
# OUTPUT
###################################
iptables -A OUTPUT -o lo -j ACCEPT                                                      # loopback
iptables -A OUTPUT -o tun+ -j ACCEPT                                                    # vpn networks

###################################
# POSTROUTING
###################################
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE                                    # nat out ppp0

Das forwarding flag ist auch gesetzt:

Code: 
mathias@spiderman:~$ cat /proc/sys/net/ipv4/ip_forward
1
mathias@spiderman:~$

Wie kann das denn sein, dass der Ping aus tun-split-udp raus geht, die Route also doch stimmt, und auf spiderman's tun0 nichts ankommt?

ciao
serow
 
ich bin mir nicht sicher ob der fehler nur auf zoom zu suchen ist ... steigende pkt counter sind eigentlich ein indiz dafür, dass das packet wirklich raus ging ...

ich würde versuchen herauszufinden, ob das paket die maschine physikalisch verlässt ... sprich ob die gegenstelle von zooms eth0 packete sieht


aber mir gehen auch gerade die ideen aus ...

zeig mal ein route -n von spiderman

welche software steht hinter dem tun? gibts da evtl irgendwelche filter?
 
Hi,

GrafZahl hat gesagt.:
ich bin mir nicht sicher ob der fehler nur auf zoom zu suchen ist ... steigende pkt counter sind eigentlich ein indiz dafür, dass das packet wirklich raus ging ...

ich würde versuchen herauszufinden, ob das paket die maschine physikalisch verlässt ... sprich ob die gegenstelle von zooms eth0 packete sieht
Zum Vergrößern anklicken....

das kann ich leider nicht, da mir der next hop nicht gehört und der Switch dazwischen auch nicht.

GrafZahl hat gesagt.:
zeig mal ein route -n von spiderman
Zum Vergrößern anklicken....

Code: 
mathias@spiderman:~$ sudo route -n
[sudo] password for mathias: 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
178.7.168.1     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
172.16.1.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
172.16.0.0      172.16.1.1      255.255.0.0     UG    0      0        0 tun0
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
mathias@spiderman:~$

Wie man sieht hat er eine Route 172.16.0.0/16 durch tun0.

GrafZahl hat gesagt.:
welche software steht hinter dem tun? gibts da evtl irgendwelche filter?
Zum Vergrößern anklicken....

Den Tunnel baut OpenVPN auf und zwar von Spiderman zu Zoom. Filter dürften also keine drin sein. Spiderman kann auch jede IP in 172.16.0.0/24 pingen.

Es ist in der Tat schwierig zu sagen wo das Problem liegt, zoom oder spiderman. Der TX packets counter steigt um 4 wenn ich 4 ICMP requests verschicke und tcpdump zeigt auch an, dass es raus ging. Das spricht für ein Problem in spiderman. Auf spiderman tut im RX packets counter garnichts auf tun0 und tcpdump sieht auch rein garnichts - was irgendwie für ein Problem in zoom spricht oder? :D

Dabei ist mir gerade noch was eingefallen: Ich habe auf zoom auf eth0 gesnifft und mir Port 1194 angezeigt (openvpn). Dabei ist mir aufgefallen, dass ein Ping auf die VPN IP von spiderman (172.16.1.4) für jeden ICMP request und response ein UDP Packet erzeugt. Wenn ich die 10.0.0.1 pinge, sieht man das nicht! Damit wäre klar, dass das Problem auf Zoom liegt oder?

ciao
serow
 
Hi,

ich bin der OpenVPN Sache nochmal etwas nachgegangen und habe herausgefunden, dass man dem Client per OpenVPN explizit sagen muss, dass er ein bestimmtes Subnet routen soll. Stichwort: ccd, iroute

http://www.pronix.de/pronix-989.html

Damit wäre das Problem gelöst. Vielen Dank für die Unterstützung!

ciao
serow
 
Hi,

ganz so scheint es nicht zu sein, denn der Eintrag in der Routing Tabelle muss trotzdem da sein. Scheint wohl doch eher ein Filter zu sein oder sowas.

ciao
serow
 
ohne routing eintrag weiß der kernel deines system nicht, dass die daten aufs TUN sollen ... das ist ganz normales routing

ich frage mich allerdings welchen sinn der filter von openvpn hat ... sicherheit? wohl eher eine aufgabe für die firewall ... so wie ich das verstehe wird auf diese weise für ein openvpn netz ersichtlich zu welchem endpunkt die daten müssen, die über das interface raus gehen ... diese information ist im TUN-Fall aber der routing tabelle entnehmbar ... das gateway wird dort genannt, und muss (vpn)lokal sein ... und ob openvpn nun informationen über iroute bezieht und propagiert, oder die routing tabelle ließt, ändert meines wissens nichts an den bekannten informationen ... da das openvpn netz die IPs der verbundenen TUNs kennt wäre klar wo das gateway ist und wohin die daten müssen ...

für TAP ist es eh egal ... wenn man da keine broadcasts im VPN machen will muss man halt macs cachen wie bei nem switch

überseh ich hier was, oder ... "weil wegen sicherheit"?
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben