web-dev-qa-db-ja.com

IPTablesを適切に転送するNTPトラフィック

私は次の設定をしています：

    NTP
  10.21.3.169
    |
    |
  10.21.3.160 (eth1)
   Linux
  10.0.0.67 (eth0)
    |
    |
  10.0.0.65 (pcn1)
   OpenBSD

アイデアは、OpenBSDボックスのNTPDクライアント（OpenNTPではない）が、OpenBSDボックスのポートフォワーディングとLinuxボックスのiptablesを使用して、NTPサーバーから時間を取得できるようにすることです。

私は次のことが当てはまる段階にあります。

  • Linuxボックスでtcpdump udpを実行すると、OpenBSDボックスからの正しいトラフィックfromが表示されるように、OpenBSDボックスのpf.confが正しく設定されています。 ntpd -d -sを実行します
  • Linuxボックスのiptables構成は、OpenBSDボックスでntpd -d -sを実行すると、トラフィックがNTPサーバーでtcpdump udpを使用して表示されるように正しく設定されています。

しかし、何も返ってきません。どちらのマシンにも、反対方向のトラフィックはありません。

Linuxマシンで使用しているiptablesルールは次のとおりです。

iptables -A PREROUTING -t nat -i eth0 -p udp --dport 123 -j DNAT --to-destination 10.21.3.169:123
iptables -A FORWARD -t filter -p udp -d 10.21.3.169 --dport 123 -j ACCEPT

それは私には正しいようです。この作業を開始する前にあったIPTables構成には、「accept state RELATED/ESTABLISHED」ルールもあります。

私は何が間違っているのですか？何か足りないものはありますか？おそらく、返信のためのいくつかの追加のルール？

編集

@gromitの回答と@MadHatterのコメントのアドバイスに従い、次の情報を追加しました。

Linuxボックスでは、cat /proc/sys/net/ipv4/ip_forwardを実行すると1が得られます。 OpenBSDボックスでntpd -d -sを実行し、Linuxボックスでtcpdumpモニタリングeth0と"eth1を（異なる端末で同時に）実行すると、次の出力が得られます。

OpenBSD

[root@OpenBSDBox ~]# ntpd -d -s
ntp engine ready
no reply received in time, skipping initial time setting
no reply from 10.0.0.67 received in time, next query 3227s

Linuxボックス

tcpdump -n -n -i eth0 port 123

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
10:05:26.448943 IP 10.0.0.65.63822 > 10.0.0.67.123: NTPv4, Client, length 48

tcpdump -n -n -i eth1 port 123

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
10:05:26.449220 IP 10.21.3.160.63822 > 10.21.3.169.123: NTPv4, Client, length 48
10:05:26.449148 IP 10.21.3.169.123 > 10.21.3.160.63822: NTPv4, Server, length 48

したがって、Linuxボックスではルーティングがまだ正しくないようです。応答はNTPボックスから返されますが、OpenBSDには送信されていません。

わかりやすくするために、追加したiptablesルーティングは次のようになります。

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 123 -j DNAT --to-destination 10.21.3.169:123
iptables -t filter -A FORWARD -p udp -d 10.21.3.169 --dport 123 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth1 -p udp --dport 123 -j MASQUERADE
//for the final line, I changed @gromit's suggestion slightly, as the --from option wasn't recognised
iptables -t nat -A POSTROUTING -p udp --sport 123 -j SNAT --to-source 10.21.3.169

その最後のiptables行を残しても、tcpdump出力に違いはないようです。

編集2

これで、次のIPtablesエントリが得られ、OpenBSDボックスの時計を更新できます。

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 123 -j DNAT --to-destination 10.21.3.169:123
iptables -t nat -A PREROUTING -i eth1 -p udp --sport 123 -j DNAT --to-destination 10.0.0.65:123
iptables -t filter -A FORWARD -p udp -d 10.21.3.169 --dport 123 -j ACCEPT
iptables -t filter -A FORWARD -p udp -d 10.0.0.65 --sport 123 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth1 -p udp --dport 123 -j MASQUERADE
iptables -t nat -A POSTROUTING -p udp --sport 123 -j SNAT --to-source 10.21.3.169

ただし、2番目の事前ルーティングコマンドと2番目のフィルターコマンドは、私が理解しているように、すべてのUDPパケットをNTPサーバーのポート123から転送するため、やり過ぎのように思えます。これは、 Linuxボックスに送信されるすべてのNTP応答（つまり、Linuxボックス自体が時間を要求するときを含む）は、OpenBSDボックスに転送されます。

iptablesopenbsdntpd
4
Rich

これは、ルーティングに問題があるようです。

時間（3.169）を提供するシステムは、要求元のシステムに接続する方法を知っていますか？

そうでない場合は、Linuxボックスのiptablesに以下を追加します。

// this rule, redirects the packets for NTP to the NTP server on the Host
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 123 -j DNAT --to 10.21.3.169

// this rule make it look for the ntp server as if the linux box is requesting the packets, which
// makes routing not necessary and lets the packet flow back to the linux box
iptables -t nat -A POSTROUTING -o eth1 -p udp --dport 123 -j MASQUERADE

// now the linux box has to check, that the packets coming back are looking like they are from the
// main source
iptables -t nat -A POSTROUTING -i eth1 -p udp --sport 123 -j SNAT --from $ip_the_client_requested_the_time_from

これで、ntpパッケージが戻ってきて、時刻が同期されているように見えます。

Ntpデーモンとリダイレクトが同じシステムで実行されると簡単になります。次に、魔法全体を実行するiptablesの「-jREDIRECT」機能を使用できますが、これはローカルホストでのみ機能します。

KR、

グルミット

3
gromit

リクエストをブロックしているのがiptablesルールかどうかを確認する最も簡単な方法：右側のテーブルで「watchiptables -L -n -v」を実行し（-t nat /のいずれかを使用）、クライアントでntpdateコマンドを繰り返し実行します。それが実際にiptablesBLOCKの問題などである場合は、パケットをブロックしている行でiptablesカウンターが増加しているのがわかります。

2
Jeff McJunkin