1. TCP代理

关于TCP代理大家可以看一下其前置的基础知识

https://blog.csdn.net/Holmofy/article/details/68063201

1.1 TCP单向代理

TCP单向代理也称为半代理，从客户端发出的报文经过TCP代理，而从服务器端发出的报文不经过TCP代理，此时只能使用单向代理方式
TCP半代理工作原理

TCP 代理收到某客户端发来的与受保护服务器（匹配某个受保护 IP 表项）建立 TCP 连接的请求（SYN 报文）后，先代替服务器向客户端回应序号错误的 SYN ACK 报文。如果收到客户端回应的RST 报文，则认为该 TCP 连接请求通过 TCP 代理的验证。一定时间内，TCP 代理收到客户端重发的 SYN 报文后，直接向服务器转发，在客户端和服务器之间建立 TCP 连接。TCP 连接建立后，TCP代理直接转发后续的报文，不对报文进行处理。

1.2 TCP双向代理

从客户端发出的报文经和从服务器端发出的报文都经过TCP代理，此时可以使用单向代理方式，也可以使用双向代理方式。

TCP双向代理工作过程

TCP 代理收到某客户端发来的与受保护服务器建立 TCP 连接的请求（SYN 报文）后，先代替服务器向客户端回应正常的 SYN ACK 报文（窗口值为 0）。如果收到客户端回应的 ACK 报文，则认为该 TCP 连接请求通过 TCP 代理的验证。TCP 代理再向服务器发送同样的 SYN 报文，并通过三次握手与服务器建立 TCP 连接。双向代理方式中，在客户端和 TCP 代理、TCP 代理和服务器之间建立两个 TCP 连接。由于两个 TCP 连接使用的序号不同，TCP 报文交互过程中，TCP 代理接收到客户端或服务器发送的报文后，需要修改报文序号，再转发给对端，这样才能保证通信正常。

需要指出的是在实际工作中，我们经常会遇到各种网络设备和安全设备都会使用TCP双向代理模式，如负载均横设备、防火墙、WAF等

2. TTL

主要是IP包头的字段，其默认为64、128、256，每经过一个路由设备其TTL会减1，在实际的工作中可以用来分析环路、操作系统、TCP劫持等，这一块后期会专门写一个专题。

3. 案例

3.1 现象

在实战中进行扫描时，用户的110、25等端口明明没有面向互联网映射，防火墙映射都看破了，但是使用telnet 相关端口时就是可以通的。

思考了一下，这个场景似曾相识，多年以前在某个金融用户那边HVV时也遇到过，用户那边的确是没有开放，但是telnet就可以通，这里面答案就是TCP 代理。
应该是某个中间设备开了TCP代理，既然开了TCP代理，如果通过这个IP走的所有流量其相关应用都会给代理，按照这种思路，我们来测试一下，选择freebuf.com的IP的C段前10个的21、25、110端口进行扫描，发现其无一例外的都开放了21、25、110，真实情况肯定不是这样的，聪明的小伙伴已经想明白了吧，中间肯定有设备对21、25、100这些应用进行了代理。

3.2 代理IP

既然有中间设备进行代理，那么我们来找找是哪个IP在代理。这里面就涉及到TTL在分析代理中的实际应用了，我们前面说明，TTL默认为64、128、256，每经过一个网络设备或路由设备其TTL都会减一，这样的话我们可以根据TTL来判断代理的IP。
前面，我们看到60.205.171.1被代理了21、25、110端口，我们首先ping一下，可以看到其TTL为49，也就是和我们经过了64-49=15跳，至于为什么不是128-49或256-49大家仔细想一下就知道答案了。

我们直接telnet 60.205.171.1的21端口，然后使用wireshark抓包看看，分析60.205.171.1返回的数据包，直接看其TTL，可以看到其TTL为64

TTL为64，肯定就是我们出口的IP了，看一下IP地址为49.94.167.14

我们直接验证一下这个IP的21、25、110端口，可以看到其21、25、110端口都是开放的，至此，答案找到了，所有经过这个IP的其都会代理21、25、110端口

我们再来测试一下8.8.8.8，经过代理设备，其也代理了21、25、110端口