web-dev-qa-db-ja.com

DHCPパッケージがtun0インターフェイスを通過しない

リモートオフィスで次の設定をしています。

--- vlan interface --- Remote Router --tun0--> Main office Firewall --> Active Directory DHCP

dhcp3-relayを使用して、dhcpリクエスト（ブロードキャスト）をメインのADサーバー（ユニキャスト）に転送しています。問題は次のとおりです。dhcp要求がリモートルーターのVLANインターフェイス（ブロードキャスト）に到着し、ルーティングを介してADサーバーに正しく転送され、応答が返されますが、パケットを受信すると、内部でtun0からに転送されません。リクエストが最初に送信されたリモートルーターのvlanXXXインターフェース。これは、リモートルーターからのtcpdump出力です。

tun0インターフェース：

tcpdump -i tun0 -nevvv udp port 67 or 68

13:23:45.049995 Out ethertype IPv4 (0x0800), length 592: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 576) IP.VPN.REMOTE.OFFICE.67 > IP.OF.AD.SERVER.67: BOOTP/DHCP, Request from MAC:ADDR:OF:THE:REMOTE:CLIENT, length 548, Hops 1, xid 0x2c896edc, secs 11527, Flags [none] (0x0000)
          Gateway-IP IP.OF.NET.GATEWAY
          Client-Ethernet-Address MAC:ADDR:OF:THE:REMOTE:CLIENT [|bootp]

13:23:45.145014  In ethertype IPv4 (0x0800), length 350: (tos 0x0, ttl 125, id 24829, offset 0, flags [none], proto UDP (17), length 334) IP.OF.AD.SERVER.67 > IP.OF.NET.GATEWAY.67: BOOTP/DHCP, Reply, length 306, xid 0x2c896edc, Flags [none] (0x0000)
          Your-IP NEW.LEASE.FROM.AD
          Server-IP IP.OF.AD.SERVER
          Gateway-IP IP.OF.NET.GATEWAY
          Client-Ethernet-Address MAC:ADDR:OF:THE:REMOTE:CLIENT [|bootp]

ここでは、パケットがdhcrelayソフトウェアによってメインオフィスに正しく転送され、ADがホストに新しいリースを提供していることがわかります。このソリューションは、openvpnベース（mpls）ではない他のリンクで動作してIPをリモートオフィスに配布しています。

vlanXXXインターフェース：

tcpdump -i vlanXXX -nevvv udp port 67 or 68

13:21:45.022067 MAC:ADDR:OF:THE:REMOTE:CLIENT > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 64, id 147, offset 0, flags [none], proto UDP (17), length 576) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from MAC:ADDR:OF:THE:REMOTE:CLIENT, length 548, xid 0x496364c3, secs 11407, Flags [none] (0x0000)
          Client-Ethernet-Address MAC:ADDR:OF:THE:REMOTE:CLIENT [|bootp]

ホストからのブロードキャストリクエストのみが表示され、tun0に到着したため、vlanXXXにルーティングする必要がある応答は表示されません。

また、リモートルーターはこのプロトコルでかなり寛容です：

iptables -A INPUT  -p udp --sport 67:68 --dport 67 -j ACCEPT
iptables -A OUTPUT -p udp --sport 67 --dport 67:68 -j ACCEPT
iptables -A FORWARD -p udp --sport 67:68 --dport 67 -j ACCEPT
iptables -A FORWARD -p udp --sport 67 --dport 67:68 -j ACCEPT

dhcp3-リレープロセス情報：

hafw:~# ps fax | grep dhc
 5714 pts/0    D+     0:00                      \_ grep dhc
 5087 ?        Ss     0:04 /usr/sbin/dhcrelay3 -i vlanxxx IP.OF.AD.SERVER

デフォルト設定（/etc/default/dhcp3-relay）：

# Defaults for dhcp3-relay initscript
# sourced by /etc/init.d/dhcp3-relay
# installed at /etc/default/dhcp3-relay by the maintainer scripts

#
# This is a POSIX Shell fragment
#

# What servers should the DHCP relay forward requests to?
SERVERS="IP.OF.AD.SERVER"

# On what interfaces should the DHCP relay (dhrelay) serve DHCP requests?
INTERFACES="vlanXXX"

# Additional options that are passed to the DHCP relay daemon?
OPTIONS=""

ソフトウェアバージョン：

hafw:~# dpkg -l | grep dhcp3-relay
ii  dhcp3-relay                            3.1.1-6+lenny6           DHCP relay daemon

私がすでにリレー構成でやろうとしていて、動作を変更しなかったこと：

  • エージェント情報を追加するための-aオプションを追加します
  • -c 20を追加し、ホップ数をdefault（10）から20に増やします。とにかく、ADに到達するホップは8つだけです。
  • tun0とインターネットに面しているインターネットVLANインターフェースvlanYYYを追加します。
  • INTERFACES=を空にすると、-iオプションはありません。

何か足りないのですか？

networkingroutingfirewallopenvpndhcp
3
user34720

これは、dhcrelayユーティリティ自体の設計上の欠陥のように見えます。 ブロードキャストインターフェースでのみリッスンでき、OpenVPNはポイントツーポイントインターフェースです。 -iフラグはこれを変更しません（ブロードキャストインターフェイスのセットから選択されたインターフェイスの数を減らすだけです）。

回避策は、ゲートウェイ自体ではなく、リモートLAN内のデバイスでdhcrelayを実行することのようです。リレーされたユニキャストトラフィックは、OpenVPNトンネルを介してDHCPサーバーに渡され、再び戻されます。

この種のタスクに小型で安価なサーバーが必要な場合は、Raspbian（Debianを装った）を実行しているRaspberryPiをお勧めします。私は、各リモートオフィスのそれらのペアでDNSを実行しています。

参考文献

1
roaima