1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Routing mit IPTables, OpenVPN...

Dieses Thema im Forum "Netzwerk" wurde erstellt von h^2, 12 Juni 2017.

  1. h^2

    h^2 hat ne Keule +1 Mitarbeiter

    Registriert seit:
    4 September 2009
    Beiträge:
    1.340
    Ja, ein wenig OT hier, aber vielleicht kennt sich ja jemand aus. Das Ding läuft leider nur mit Linux, sonst hätte ich die Probleme nicht -.- Leider kenn ich mich mit iptables ziemlich schlecht aus :'(

    Ich habe folgendes Setup (vereinfacht):

    Code:
                   Internetz
                        |
      Internetz       NetzB
            |           |
     +------o-----------o------+
     |     eth0       tun0     |
     |          eth1           |
     +-----------o-------------+
                 |
                LAN
    

    Also ein physisches device nach innen mit subnetz 192.168.3.0 und eins nach Außen zum Internet. Zusätzlich ein OpenVPN-Tunnel tun0 über eth0 nach "NetzB". Der OpenVPN-Tunnel bekommt eine statische IP-Adresse und das NetzB sind auch Rechner mit öffentlichen, statischen IPs, die auch direkt ins Internet können.
    Über den VPN-Tunnel werden standard-mäßig nur die Routen für NetzB gepusht, so dass der Router Anfragen aus dem LAN je nach Ziel entweder über eth0 oder tun0 NATet. Das funktioniert auch soweit alles.

    Man kann auch mit ping -I oder traceroute -i vom Router aus explizit über tun0 rausgehen (an Adressen außerhalb von NetzB), dann kommen die Antworten auch über tun0 zurück, alles wie erwartet.

    ABER wenn man von außen auf die IP von von tun0 zugreifen möchte klappt es nicht. Das heißt wenn ich von NetzB auf die (statische) IP von tun0 zugreife, dann geht alles, aber wenn ich aus dem Internet versuche, dann kommen keine Antworten zurück.
    Paradoxerweise sehe ich sogar auf dem Router per TCPdump, dass ICMP echo reply von tun0-Adresse zur anfragenden IP gesendet wird. Leider kommt davon aber nichts an. Ich weiß aber auch nicht nach/vor dem Anwenden welcher Regeln tcpdump mir das anzeigt.

    Ich habe mal manuell aus den IPTables fast alle drop Anweisungen entfernt und explizit eine ACCEPT Regel für ICMP hinzugefügt, trotzdem ist das Verhalten dasselbe.

    Hier die IPTables:
    Code:
    Chain INPUT (policy ACCEPT)
    num  target  prot opt source  destination   
    1  ACCEPT  0  --  anywhere  anywhere   
    2  ACCEPT  0  --  anywhere  anywhere  state RELATED,ESTABLISHED
    3  ACCEPT  icmp --  anywhere  anywhere   
    4  ACCEPT  udp  --  anywhere  anywhere  udp dpt:route
    5  ACCEPT  0  --  anywhere  anywhere  state NEW
    6  ACCEPT  0  --  anywhere  anywhere  state NEW
    7  ACCEPT  icmp --  anywhere  anywhere 
    
    Chain FORWARD (policy ACCEPT)
    num  target  prot opt source  destination   
    1  ACCEPT  0  --  anywhere  anywhere  state RELATED,ESTABLISHED
    2  ACCEPT  gre  --  192.168.3.0/24  anywhere   
    3  ACCEPT  tcp  --  192.168.3.0/24  anywhere  tcp dpt:1723
    4  lan2wan  0  --  anywhere  anywhere   
    5  ACCEPT  0  --  anywhere  anywhere   
    <--- einige weitere forwards --->
    14  ACCEPT  tcp  --  anywhere  192.168.3.204  tcp dpts:5000:5100
    15  ACCEPT  udp  --  anywhere  192.168.3.204  udp dpts:5000:5100
    16  DROP  tcp  --  anywhere  0.0.0.0  tcp spt:0
    17  DROP  udp  --  anywhere  0.0.0.0  udp dpt:0
    18  TRIGGER  0  --  anywhere  anywhere  TRIGGER type:in match:0 relate:0
    19  trigger_out  0  --  anywhere  anywhere   
    20  ACCEPT  0  --  anywhere  anywhere  state NEW
    
    Chain OUTPUT (policy ACCEPT)
    num  target  prot opt source  destination   
    
    Chain advgrp_1 (0 references)
    num  target  prot opt source  destination   
    
    Chain advgrp_10 (0 references)
    num  target  prot opt source  destination   
    
    Chain advgrp_2 (0 references)
    num  target  prot opt source  destination   
    
    Chain advgrp_3 (0 references)
    num  target  prot opt source  destination   
    
    Chain advgrp_4 (0 references)
    num  target  prot opt source  destination   
    
    Chain advgrp_5 (0 references)
    num  target  prot opt source  destination   
    
    Chain advgrp_6 (0 references)
    num  target  prot opt source  destination   
    
    Chain advgrp_7 (0 references)
    num  target  prot opt source  destination   
    
    Chain advgrp_8 (0 references)
    num  target  prot opt source  destination   
    
    Chain advgrp_9 (0 references)
    num  target  prot opt source  destination   
    
    Chain grp_1 (0 references)
    num  target  prot opt source  destination   
    
    Chain grp_10 (0 references)
    num  target  prot opt source  destination   
    
    Chain grp_2 (0 references)
    num  target  prot opt source  destination   
    
    Chain grp_3 (0 references)
    num  target  prot opt source  destination   
    
    Chain grp_4 (0 references)
    num  target  prot opt source  destination   
    
    Chain grp_5 (0 references)
    num  target  prot opt source  destination   
    
    Chain grp_6 (0 references)
    num  target  prot opt source  destination   
    
    Chain grp_7 (0 references)
    num  target  prot opt source  destination   
    
    Chain grp_8 (0 references)
    num  target  prot opt source  destination   
    
    Chain grp_9 (0 references)
    num  target  prot opt source  destination   
    
    Chain lan2wan (1 references)
    num  target  prot opt source  destination   
    
    Chain logaccept (0 references)
    num  target  prot opt source  destination   
    1  ACCEPT  0  --  anywhere  anywhere   
    
    Chain logdrop (0 references)
    num  target  prot opt source  destination   
    1  DROP  0  --  anywhere  anywhere   
    
    Chain logreject (0 references)
    num  target  prot opt source  destination   
    1  REJECT  tcp  --  anywhere  anywhere  reject-with tcp-reset
    
    Chain trigger_out (1 references)
    num  target  prot opt source  destination
    
    Was sollte ich mir als nächstes angucken?
     
  2. double-p

    double-p BOFH

    Registriert seit:
    6 September 2003
    Beiträge:
    684
    Ort:
    Buxtehude, Germany
    Das Routing oder eher Firewalling in NetzB (also nicht auf dem Router aus dem Schaubild)?
     
  3. h^2

    h^2 hat ne Keule +1 Mitarbeiter

    Registriert seit:
    4 September 2009
    Beiträge:
    1.340
    Ne, das kann ich ausschließen. Ich bin mir jetzt mit folgendem sicher: die Pakete kommen korrekt an auf dem tun0, aber die Antworten werden über eth0 rausgeschickt (mit der IP von tun0). Aber wieso und weshalb, das ist noch die Frage. Bzw. ich weiß warum die Routen standard-mäßig darüber gehen, das ist ja so eingestellt, aber sollte die Antwort nicht irgendeinen State haben, der sie dafür markiert über tun0 zurück rauszugehen?
     
  4. double-p

    double-p BOFH

    Registriert seit:
    6 September 2003
    Beiträge:
    684
    Ort:
    Buxtehude, Germany
    Dann stimmt das routing nicht - bzw die Aussage, dass du den Reply auf tun0 in tcpdump siehst.
     
  5. h^2

    h^2 hat ne Keule +1 Mitarbeiter

    Registriert seit:
    4 September 2009
    Beiträge:
    1.340
    Richtig :)

    Die incoming ICMP sehe ich auf tun0, die Antwort sehe ich auf eth0 (weil das routing nicht stimmt).

    Die Frage ist wie ich das Routing anders regeln kann, grundsätzlich soll ja die defaultroute für Adressen im Internet weiterhin über eth0 gehen. Nur eben Antworten auf eingehende Verbindungen auf tun0 sollen auch über tun0 wieder raus. Einfacher wäre vielleicht noch, dass alle Nachrichten von der IP von tun0, auch immer nur über tun0 rausgehen.
    Mein letztes intensives Firewalling und Routing liegt schon ein paar Jahre zurück und mit dem OpenBSD PF schien mir das alles viel einfacher....
     
  6. Illuminatus

    Illuminatus in geheimer Mission

    Registriert seit:
    3 August 2003
    Beiträge:
    1.107
    Auf welchem Interface hast du das mit tcpdump gesehen? http://www.slashroot.in/linux-kernel-rpfilter-settings-reverse-path-filtering
    Was war die Quell-IP des echo-request und wie lautet deine Routingtabelle?

    Schätze du musst mit dem ip Werkzeug dir ein paar Regeln schreiben und Pakete markieren. Aufgrund der Markierung soll dann die Rückroute gefunden werden.
    https://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux/
     
  7. double-p

    double-p BOFH

    Registriert seit:
    6 September 2003
    Beiträge:
    684
    Ort:
    Buxtehude, Germany
    In pf(4) wuerde ich mal in Richtung tag/tagged und received-on denken. Geht mit iptables wahrscheinlich auch "irgendwie"
     
  8. h^2

    h^2 hat ne Keule +1 Mitarbeiter

    Registriert seit:
    4 September 2009
    Beiträge:
    1.340
    OT: Wenn es nur Router gäbe, auf denen OpenBSD oder FreeBSD liefe mit vernünftigem modernen WLAN ;'( (und ja, das 11ac und die Kanalbündelung bringen bei dem Elektro-Smog deutliche Vorteile). In meiner nächsten Wohnung werde ich wohl Router und AP einfach trennen müssen...
     
  9. h^2

    h^2 hat ne Keule +1 Mitarbeiter

    Registriert seit:
    4 September 2009
    Beiträge:
    1.340
    War dann doch einfacher als gedacht:
    Code:
    ip rule add from VPN_IP  table 200
    ip route add default via VPN_GW dev VPN_DEV table 200
    
    :cool: