Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PREROUTING似乎有cache,导致公网机器先发包失败 #44

Open
xylophone21 opened this issue Jun 6, 2023 · 1 comment
Open

PREROUTING似乎有cache,导致公网机器先发包失败 #44

xylophone21 opened this issue Jun 6, 2023 · 1 comment

Comments

@xylophone21
Copy link

xylophone21 commented Jun 6, 2023

复现环境: Ubuntu 20.04.4 LTS
网络架构: Client A(192.168.99.102:64701) --> (192.168.99.1) NAT full cone ( 192.168.1.102:64701) --> Client B (192.168.1.101:62130)
复现过程:

  1. Client B向Nat的192.168.1.102:64701发送UDP包,此时首个包会被fullconenat_tg收到,然后在get_mapping_by_ext_port这里因为没有找到返回XT_CONTINUE,从而导致UDP包被丢弃,这是正确的.
  2. 马上Client B再次发送相同的包, 这个时候fullconenat_tg不会收到通知
  3. Client A向Client B发包,建立64701端口上的洞
  4. Client B再次发送相同的包,这个包应该能够被Client A收到,但这时实际情况是会给步骤2相同,似乎这个通知被kernel cache住了,不会到fullconenat_tg, 我们的规则也就不会生效.

备注:
如果跳过步骤1-2,直接执行3-4是可以的.

@xylophone21
Copy link
Author

另外,这个cache的有效期似乎跟conntrack差不多, 如果持续执行步骤4, 则这个cache的时间会很长, 但如果停止发包,则cache会很快被淘汰

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant