tc
私は以下のようにTAPインタフェース()tap0
から着信パケットのMACアドレスを変更しました。ここではmac_org
、QEMU仮想マシンのゲストのMACアドレス、およびに置き換える必要がある他のMACアドレスですmac_new
。mac_org
tc qdisc add dev tap0 ingress handle ffff:
tc filter add dev tap0 protocol ip parent ffff: \
flower src_mac ${mac_org} \
action pedit ex munge eth src set ${mac_new} pipe \
action csum ip pipe \
action xt -j LOG
また、入力フックからUDPパケットを記録するためのiptablesルールを追加しました。
iptables -A INPUT -p udp -j LOG
syslog は、DHCP 検索パケットがそれに応じて変更されたことを示します。ログtc
エントリは次のとおりです。
IN=tap0 OUT= MAC=ff:ff:ff:ff:ff:ff:${mac_new}:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=338 TOS=0x00 PREC=0xC0 TTL=64 ID=0 DF PROTO=UDP SPT=68 DPT=67 LEN=318
tc
ローカル受信パケットがソケットに転送されると、netfilter 入力フックのログエントリは受信フックに従い、同じ結果を表示しますが、フォーマットは若干異なります。
IN=tap0 OUT= MACSRC=${mac_new} MACDST=ff:ff:ff:ff:ff:ff MACPROTO=0800 SRC=0.0.0.0 DST=255.255.255.255 LEN=338 TOS=0x00 PREC=0xC0 TTL=64 ID=0 DF PROTO=UDP SPT=68 DPT=67 LEN=318
QEMUを始める前にこれを実行してdnsmasq
素晴らしいtap0
結果を得ました。
DHCPDISCOVER(tap0) ${mac_org}
代わりに含まれている内容をstrace -f -x -s 10000 -e trace=network dnsmasq ...
表示する呼び出しを実行します。recvmsg
${mac_org}
${mac_new}
recvmsg(4, {msg_name={sa_family=AF_INET, sin_port=htons(68), sin_addr=inet_addr("0.0.0.0")}, msg_namelen=16, msg_iov=[{iov_base="... ${mac_org} ..." ...
どうやってそのようなことが起こりましたか? netfilter 入力フック以降にパケットが変更されたようです。
答え1
tc
私が理解したところでは、変更されたイーサネットアドレス(リンク層のみ)をクライアントが要求に含める内部フィールド(クライアントのハードウェアアドレス)(アプリケーション層は変更されていません)と混同しています。CHADDR
DHCPDISCOVER
tc