Closed w311ang closed 2 years ago
如果能解决的话,我希望能提供一点捐赠,谢谢作者了
应用层(DNS)管不了网络层/传输层(IP/TCP/UDP)。
感觉问题应该是iptables
的使用,你应该仔细研究一下……
非 Linux 用户,对这个也不大熟悉。
猜测一下是不是再套一个portfwd
又可以解决问题,我发现套个tcp2udp之后请求IPv6 TCP又是正常的,因为是老版不知道新版tcplocal是不是也是正常的
你是维护者,我想知道是不是dnsforwarder针对ipv6 udp的响应中包含了自己监听的端口号
猜测证实,的确是由dnsforwarder返回的端口号
有意思的是,经iptables重定向请求其他互联网上dns源port又变成了53 验证一下经过了dnsforwarder
是不是dnsforwarder针对ipv6 udp的响应中包含了自己监听的端口号
并不是这么工作的。 DNS 应答内容本身并不包含这些,并且是谁请求的就返回给谁。至于,使用的 IP 和端口,都是由网络驱动自动记录的。 显然的,你这里监听使用的端口 534,系统没道理说用的 53。至于怎么 534 变成 53,应该是 iptables 的工作。 这里就是 iptables 在中间没有按预期工作。。。
不熟悉 iptables,纯粹猜测一下:重定向如果完整的转移了原始的 IP 协议包,那在这里就不合适,这里期望的是一个类似代理的 IP 协议 payload 的转发;或者应该换个其它使用方式。
我用dns2tcp试了一下也是一样的,不应该是dnsforwarder的问题
你方向搞错了。这不是 DNS 软件的问题,也不是 DNS 软件该做的事。
打个比方吧: 有线上专卖店-53、专卖店-534、买家-dig。dig 向 53 下了单,但是,平台小二-iptables 强行(姑且认为这是它的合法权利)把它转给了 534。534 照收件地址发了货。收到货的 dig 较真儿,发现发货人的邮局不是 53 的,提出了异议。 那么,你觉得问题在哪儿,应该怎么解决?
其实,最直接的,是想办法直接用 53 端口。实在没办法非要中转,也要保证 iptables 做好双向的中间人工作。
改了个example,按预期可以接受TPROXY并发往指定IP端口并给客户端伪装成是目标IP端口返回的数据 https://github.com/w311ang/ipportfwd
我用iptables把53端口重定向到了dnsforwarder出现了如下错误,而在被IPv4 UDP请求时是正常的
在请求时dnsforwarder也有反应,所以应该是重定向成功了,我觉得跟这个有点雷同https://github.com/coredns/coredns/issues/3097