[学习实践]防火墙DNAT与SNAT详谈以及用tcpdump抓包解决定位SNAT源IP（可能有俩源IP），防火墙经过地址转换抓包详解。
对于SNAT这种转换，肯定是跨网段了，怎么个意思呢？
对于家里网想访问公网，肯定会把家里电脑的如：192.168.1.100转为申请的公网出口IP地址。
而对于武哥讲到的：
tcpdump -q -tttt -nn 'tcp and dst 10.73.234.1** and dst port 8080' -P in -i eth0
参数解释：
-P：指定要抓取的包是流入还是流出的包。可以给定的值为"in"、"out"和"inout"，默认为"inout"。
tcpdump -q -tttt -nn 'tcp and dst 10.10.0.45 and dst port 9500' -P in -i enp0s3
Warning: -P switch is not compatible with the upstream version. You should use -Q instead.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-07-29 10:00:14.149878 IP 10.10.2.1.37566 > 10.10.0.45.9500: tcp 0
2021-07-29 10:00:14.157827 IP 10.10.2.1.37566 > 10.10.0.45.9500: tcp 0
2021-07-29 10:00:14.158114 IP 10.10.2.1.37566 > 10.10.0.45.9500: tcp 522
2021-07-29 10:00:14.165897 IP 10.10.2.1.37566 > 10.10.0.45.9500: tcp 0
10.10.2.1 指公网XX云VPN虚拟地址。
更多：SLB健康检测的IP和VIP不是同一个IP，且NAT模式VIP下在的机器访问自己的VIP肯定出现1/N的访问不到的情况，于是淘宝采用了FullNat模型，其本质是通过会话查表规避出现源和目的一样的情况。Tcpdump查检测IP方法：https://jackxiang.com/post/10128/
也就是说LVS的浮动IP向内转到里面的Jenkins某一台服务器时，其源IP和LVS浮动IP不一样且有可能是俩IP（主A备B），也就是同一台客户机发起请求，居然有可能是从A过来，也可能是从B过来，此时在Jenkins（10.73.234.180）配置的防火墙上面配置的IP可能只有A，而没有B，那么从B过来的包被拦截后，也就无法通过外包服务器触发里面的这台Jenkins进行部署代码，起码有一半的概率。
同理：对于GitLab里也出现类似问题，探测IP在探测后端机时，也是因为有俩IP，IPtable里面只写了一个，导致探测出现认为后端两机器都活着，在用户作SSH里连接Gitlab（10.73.234.179）时，出现LVS发现后端另一台也活着，Git Client在SSH 时会时而连接另外一台，在另一台日志出现被攻击的提示，且要修改/home/xiangdong/.ssh/known_hosts 的IP地址，因为另一个SNAT的IP过来连接了，会认为不安全，得删掉。
对于同一个SLB下的服务器N台访问自己的VIP，会出现1/N的的概率访问不通的解释：
S-->SLB-->D
16.1.1.1 -> 18.1.1.1->出现在SLB里访问的口当SLB的VIP向自己进行回包时,查路由表时，发现源地址一样，导致SLB不再转包，原因是源的目的地址都一样：
X@eth10 IP 18.1.1.1 > 18.1.1.1: S 4229408411:4229408411(0) win 64240 cmss #这俩地址一样了于是不再转发，于是发的包没有回收到，于是出现业务上卡住了。
防火墙经过地址转换抓包详解：
https://blog.csdn.net/shiyuqi_blog/article/details/90230186
防火墙DNAT与SNAT详谈：
https://blog.51cto.com/luosea/1686022
R表示收到，X表示发出，R@eth1是从eth1口收到数据包。X@eth2是从2口发出数据包
16.1.1.1>18.1.1.2 表示IP 16.1.1.1发给IP 18.1.1.2
Seq后面的数是序列号 request和reply的号一致就是一个数据包
抓包过程详解：
防火墙eth1口收到16.1.1.1发给18.1.1.2的request数据包
接着从eth2口这个request数据包转发出去
然后防火墙eth2口收到18.1.1.2发给16.1.1.1的reply数据包
防火墙再从eth1口转发这个reply给16.1.1.1
---------------------
作者：一只认真的鱼
来源：CSDN
原文：https://blog.csdn.net/shiyuqi_blog/article/details/90230186
版权声明：本文为博主原创文章，转载请附上博文链接！
对于家里网想访问公网，肯定会把家里电脑的如：192.168.1.100转为申请的公网出口IP地址。
而对于武哥讲到的：
tcpdump -q -tttt -nn 'tcp and dst 10.73.234.1** and dst port 8080' -P in -i eth0
参数解释：
-P：指定要抓取的包是流入还是流出的包。可以给定的值为"in"、"out"和"inout"，默认为"inout"。
tcpdump -q -tttt -nn 'tcp and dst 10.10.0.45 and dst port 9500' -P in -i enp0s3
Warning: -P switch is not compatible with the upstream version. You should use -Q instead.
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp0s3, link-type EN10MB (Ethernet), capture size 262144 bytes
2021-07-29 10:00:14.149878 IP 10.10.2.1.37566 > 10.10.0.45.9500: tcp 0
2021-07-29 10:00:14.157827 IP 10.10.2.1.37566 > 10.10.0.45.9500: tcp 0
2021-07-29 10:00:14.158114 IP 10.10.2.1.37566 > 10.10.0.45.9500: tcp 522
2021-07-29 10:00:14.165897 IP 10.10.2.1.37566 > 10.10.0.45.9500: tcp 0
10.10.2.1 指公网XX云VPN虚拟地址。
更多：SLB健康检测的IP和VIP不是同一个IP，且NAT模式VIP下在的机器访问自己的VIP肯定出现1/N的访问不到的情况，于是淘宝采用了FullNat模型，其本质是通过会话查表规避出现源和目的一样的情况。Tcpdump查检测IP方法：https://jackxiang.com/post/10128/
也就是说LVS的浮动IP向内转到里面的Jenkins某一台服务器时，其源IP和LVS浮动IP不一样且有可能是俩IP（主A备B），也就是同一台客户机发起请求，居然有可能是从A过来，也可能是从B过来，此时在Jenkins（10.73.234.180）配置的防火墙上面配置的IP可能只有A，而没有B，那么从B过来的包被拦截后，也就无法通过外包服务器触发里面的这台Jenkins进行部署代码，起码有一半的概率。
同理：对于GitLab里也出现类似问题，探测IP在探测后端机时，也是因为有俩IP，IPtable里面只写了一个，导致探测出现认为后端两机器都活着，在用户作SSH里连接Gitlab（10.73.234.179）时，出现LVS发现后端另一台也活着，Git Client在SSH 时会时而连接另外一台，在另一台日志出现被攻击的提示，且要修改/home/xiangdong/.ssh/known_hosts 的IP地址，因为另一个SNAT的IP过来连接了，会认为不安全，得删掉。
对于同一个SLB下的服务器N台访问自己的VIP，会出现1/N的的概率访问不通的解释：
S-->SLB-->D
16.1.1.1 -> 18.1.1.1->出现在SLB里访问的口当SLB的VIP向自己进行回包时,查路由表时，发现源地址一样，导致SLB不再转包，原因是源的目的地址都一样：
X@eth10 IP 18.1.1.1 > 18.1.1.1: S 4229408411:4229408411(0) win 64240 cmss #这俩地址一样了于是不再转发，于是发的包没有回收到，于是出现业务上卡住了。
防火墙经过地址转换抓包详解：
https://blog.csdn.net/shiyuqi_blog/article/details/90230186
防火墙DNAT与SNAT详谈：
https://blog.51cto.com/luosea/1686022
R表示收到，X表示发出，R@eth1是从eth1口收到数据包。X@eth2是从2口发出数据包
16.1.1.1>18.1.1.2 表示IP 16.1.1.1发给IP 18.1.1.2
Seq后面的数是序列号 request和reply的号一致就是一个数据包
抓包过程详解：
防火墙eth1口收到16.1.1.1发给18.1.1.2的request数据包
接着从eth2口这个request数据包转发出去
然后防火墙eth2口收到18.1.1.2发给16.1.1.1的reply数据包
防火墙再从eth1口转发这个reply给16.1.1.1
---------------------
作者：一只认真的鱼
来源：CSDN
原文：https://blog.csdn.net/shiyuqi_blog/article/details/90230186
版权声明：本文为博主原创文章，转载请附上博文链接！
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：https://jackxiang.com/post/10243/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
最后编辑： jackxiang 编辑于2021-7-29 10:07
[实践OK]Centos7修改grub启动菜单等待时间,以及grub修复
[实践OK]Mac和Linux下如何高效回退到特定层级目录？评论列表
