DHCP-Server im Bridged Mode

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • DHCP-Server im Bridged Mode

    Hallo,

    wir haben ein Problem bei einer mittels OpenVPN realisierten Ethernet-Brücke. Ich würde mich freuen, wenn mir jemand mit dem Zaunpfahl winken könnte. :oops:

    Brainfuck-Quellcode

    1. Client-Netzwerk Server-Netzwerk
    2. ------------+ +------------
    3. I +-----------+ +-------------+ +-----------------+ I
    4. ------------#------------# FRITZ!Box #-.-.-.-.-.# Router #-----------# efw #-----------#------------
    5. I +-----------+ +-------------+ +-----------------+ I
    6. ------------+ RED GREEN +------------
    7. 192.168.15.65-99/24 192.168.15.64 ((INTERNET)) 192.168.12.1 192.168.12.9 192.168.15.1 192.168.15.2-64/24

    Der Server läuft auf einer "Endian Firewall Community release 2.2.rc3" und der Client auf einem Router (FRITZ!Box - "OpenVPN 2.1_rc2 mipsel-linux"). Die Verbindung an sich ist in Ordnung, was ja auch schon das Problem ist: DHCP-Clients aus dem Client-Netzwerk erhalten z.T. ihre IP-Konfiguration oder auch nur DHCP-Optionen wie die DNS-Server aus dem Server-Netzwerk. Sobald der Tunnel dann nicht mehr steht (wg. DSL-Problemen auf Server-Seite leider recht häufig), gehen sämtliche DNS-Anfragen ins Leere.

    Auf 'ner älteren efw hatte ich das mal per iptables gelöst, aber ich besitze die Doku dazu leider nicht mehr. Ich habe die Regel bereits in verschiedensten Ketten (z.B. OPENVPNDHCP, INPUT, INPUTFW, etc.) ausprobiert, aber der DHCP-Server antwortet immernoch wie zuvor.

    Quellcode

    1. iptables -I $CHAIN -p udp --sport 67:68 --dport 67:68 -m physdev --physdev-in tap1 -j DROP

    Eigentlich sollte das ja nicht passieren, weil der Request "gedropped" werden soll. Wo erfahre ich, in welcher Reihenfolge die zahlreichen Ketten abgearbeitet werden, oder in welcher Kette müsste die Regel greifen?

    Ich habe auch mal versucht, den DHCP-Server der efw durch die benutzerdefinierten Konfigurationszeilen dazu zu überreden, den DHCP-Clients im Client-Netz ihre passende Konfiguration zu senden, was zu bizarren Ergebnissen führte: Das DHCPOFFER-Paket kam zwar mit den untenstehenden (richtigen) Optionen, der DHCPACK kam dann aber mit den falschen.

    Quellcode

    1. group brdg-clnt {
    2. host host1 {
    3. hardware ethernet 00:11:22:33:44:55;
    4. fixed-address 192.168.15.65;
    5. }
    6. host host2 {
    7. hardware ethernet 00:66:77:88:99:AA;
    8. fixed-address 192.168.15.66;
    9. }
    10. option subnet-mask 255.255.255.0;
    11. option domain-name "our-net.local";
    12. option routers 192.168.15.64;
    13. option domain-name-servers 192.168.15.64;
    14. option ntp-servers 192.168.15.64;
    15. default-lease-time 864000;
    16. max-lease-time 1123200;
    17. }
    Alles anzeigen

    Versuch macht halt kluch... :D Ich möchte die Konfiguration des efw-DHCP-Servers jetzt aber ungerne komplett händisch erstellen. Mir wäre es eh am liebsten, wenn das ganze wieder wie zuvor über die Firewall geregelt werden könnte.

    Vielen Dank schonmal im Voraus und 'n guten Rutsch...
  • Re: DHCP-Server im Bridged Mode

    Hallo nochmal,

    die Funktionsweise der iptables-Ketten habe ich jetzt glaube ich durchschaut. :???: Trotzdem werden DHCP-Request-Pakete offensichtlich immernoch weitergeleitet, obwohl sie im efw-Log eindeutig als -je nach Einstellung- INPUTFW:DROP oder VPNFW:DROP zu finden sind. Auch die Zähler (iptables -L -v) deuten daraufhin, dass die Regeln greifen. Aber der efw-DHCP-Server antwortet nach wie vor. Auch die folgende (ausgehende) Regel war nicht von Erfolg gekrönt (auch nicht mit DROP als Sprungziel):

    Quellcode

    1. iptables -I OPENVPNDHCP -v -m physdev --physdev-out tap1 -p tcp --sport 68 --dport 67 -j REJECT
    2. iptables -I OPENVPNDHCP -v -m physdev --physdev-out tap1 -p udp --sport 68 --dport 67 -j REJECT


    Nutzt der Server vielleicht doch direkt das tap-Interface obwohl er nur für die Brücke br0 gestartet ist?

    Ich hoffe auf frische Ideen, meine sind zur Zeit ausgeschöpft...

    Also denn, nochmal 'n guten Rutsch!
  • Re: DHCP-Server im Bridged Mode

    Hallo,

    leider besteht das Problem immernoch. Die Pakete gehen lt. Wireshark auf jeden Fall auf/über die Ports UDP 67 (Server) & UDP 68 (Client). Ob vielleicht noch andere Ports genutzt werden, kann ich nicht ausschließen, weil der Netzwerk-Traffic bei mehreren Windows-Clients im Netzwerk dermaßen unübersichtlich ist, dass ich nur die Kommunikation über die Standard-Ports genauer betrachtet habe (Lt. IANA.ORG: 67 & 68 jeweils TCP und UDP). Es finden sich auf diesen Ports alle DHCP-Pakete (Release, Discover, Request, Offer, Inform, Ack...), weshalb ich davon ausgehe, dass nur diese benutzt werden.

    Ich befürchte mittlerweile, dass es hier nicht ohne weiteres möglich ist, die Pakete adequat auszufiltern, würde mich aber freuen, wenn mir doch noch ein Weg aufgezeigt werden könnte...

    Gruß
    Andreas