tomcat白名单（十）passthrough配合SNI究竟在第几层【重要】

1

 

中间的是反向代理；右边的是正向代理，tomcat白名单（四）正向代理

 

2

基于clienthello会不会拆粘包，为什么每次wireshark看到的都是正好的的结论，那它拿sni的第一个clienthello包不是一个应用层的吗

 

deepseek首先承认了ClientHello是应用层的包，并且点出了为什么一般仍然认为它在四层- ‘看’和‘改’的区别

强调了握手仍在客户端和后端之间

 

3 有没有SNI 4层转发的云服务

ALB作为阿里云主推7层服务，会看SNI，但也会TLS termination，不符合

同时ALB可以支持http协议簇（比如GRPC应用层转发），不支持sofa

ESA边缘安全加速，没有提及根据SNI做4层转发，会读SNI，但可能只做安全校验

NLB不支持SNI路由，只能后端配个集群它轮询转发，典型反向代理

 

4 出站流量拦截+转发

4.1 在三层网络层做？iptable？nat？

不行，对方域名解析会变

4.2 阿里云防火墙

确实通过SNI识别，但是它直接把包丢了不转发

4.3 DNS劫持

先骗过客户端，再接管流量

 

4.4 标准代理协议

 

 东西到了7层，确实更灵活，但是也更不可控，因为7层更灵活

同时，也没有现成的云服务产品支持

 

 

4.5 继续回到4.3

缺点：只能https协议，不支持http/websocket及其他自定义7层协议；需要fallback处理这些流量

 

4.6 高可用

4.5.1.1 虚拟IP

4.5.1.2 NLB+HAproxy集群

NLB的健康检查-三次握手

 

4.7 有没有云服务商支持4.5.1.2，这样就省去部署HAproxy集群

4.7.1 腾讯/京东/阿里的7层LB都会卸载SSL

4.7.2 谷歌

 

（这个好像ds说错了，他想说的可能是七层的ALB）

谷歌继续：

 

4.7.3 阿里云NLB-典型反向代理，需要自建nginx stream或haproxy