作者回复: 1. 是的,TTL的操控是traceroute之类工具的核心,通过它实现了“逐跳”的探测。你这里提到了TTL为0时,路由器回复ICMP超时消息,这个补充非常好。 另外,文稿里的例子用默认UDP的方式遇到了“黑洞”,也就是对端并没有对这个UDP探测包回复IMCP port unreachable消息,但是它会对ICMP echo request探测包回复IMCP port unreachable消息,所以通过traceroute -I就可以看到完整的路径了。一般来说,对端要么对UDP模式有响应,要么对ICMP模式有响应,所以我们可以两个分别试一下。 2. 是的,telnet的握手SYN包发出去,但对端一直没回复SYN+ACK,导致telnet的connect()无法成功返回,造成了挂起。
作者回复: 嗯,这个要结合客户端和服务端的抓包,对比来分析: 1. 客户端抓包中有发出SYN,但在服务端抓包中没收到SYN,一般是客户端去往服务端的问题,检查这个方向上的网络设备;虚拟化情况下,也可能是客户端或者服务端VM/pod所在的hypervisor上的virtual switch等环节做了“手脚”,这些也在广义的网络设备范畴内,也要查; 2. 在服务端抓包中,发现SYN包进来了,但服务端没回SYN+ACK,那就检查本地是否有拦截(比如iptables)、端口监听是否正常、系统资源是否正常、应用的网络部分的代码是否正常、应用层的network syscall的返回是否正常; 3. 在服务端抓包中,发现SYN包进来了,自己也回了SYN+ACK,但客户端抓包中没收到SYN+ACK,推进方法跟1类似。 在1的服务端的入方向,tcpdump抓包发生在iptables规则起作用之前,所以如果SYN/SYN+ACK已经来了,tcpdump就能看到SYN,但iptables接着做拦截的话,这个连接也还是无法建立(跟网络上丢失的效果一致),这时候虽然见着了SYN但协议栈没回复SYN+ACK,却并不是协议栈的问题(而是iptables拦截导致)。这个分析也适用于3的客户端入方向。 可能没有涵盖所有情况,先想到这些:) 防火墙的话,会引起1和3,当然防火墙也会引起别的问题。关于防火墙的内容,下周上第5和第6课就可以学习到了。
作者回复: 笔记挺好的:)
作者回复: 回复100分:) 对于问题一,稍作补充:如果udp端口号不是递增,会有个问题是无法判断返回的time-to-live exceeded报文是代表了哪一跳。由于这个ttl exceeded报文携带了这次探测的udp端口号信息,比如是34440,减去base number33434,就是6,那么就是第6跳回复的。 问题二,抱歉可能大家对“挂起”的理解不完全一致,我原意是指telnet没有失败退出,也没有成功到提示符,而是处在尝试连接状态中。 telnet成功后,表示握手成功,这时,我们可以继续发送文本,比如GET / HTTP/1.1 Host: www.baidu.com 这就是一次模拟的HTTP请求。 可以参考我这边的实验结果: $ telnet www.baidu.com 80 Trying 180.101.49.11... Connected to www.a.shifen.com. Escape character is '^]'. GET / HTTP/1.1 Host: www.baidu.com HTTP/1.1 200 OK Accept-Ranges: bytes Cache-Control: no-cache Connection: keep-alive Content-Length: 9508 Content-Type: text/html Date: Thu, 13 Jan 2022 13:19:58 GMT P3p: CP=" OTI DSP COR IVA OUR IND COM " P3p: CP=" OTI DSP COR IVA OUR IND COM "
作者回复: 很赞~ 是的,我观察到traceroute不是“挨个”探测的,而是一把发出多个不同TTL(和不同UDP端口)的探测报文,然后根据返回的情况,再判断的
作者回复: 看明白你的问题了,是指traceroute udp模式(也就是默认模式)下,为什么每次发送的udp探测包,其目的端口是递增的对吧?这样可以通过返回的ICMP消息里面携带的payload(这是一个“内嵌”的udp数据包),识别到这个ICMP是呼应了哪个udp探测包。如果每次端口号都相同,那所有的ICMP回复,就没有区别了,这并不是我们想要的。
作者回复: 是的:) TCP的报文叫segment IP的报文叫datagram,其实UDP的也叫datagram 二层的叫frame segment是指“属于一个大块信息中的一部分”的报文,datagram是前后没有关系的相对独立的报文。 说到这里,你也可以联想一下VXLAN这个协议。作为overlay网络,为什么把UDP当做底层传输协议,而不是用TCP呢?我们可以对比一下普通网络和overlay网络: 普通网络(相对而言就是underlay网络):frame ( IP ( UDP/TCP ) ) overlay网络:outer frame ( outer IP ( outer UDP ( inner frame ( inner IP (inner UDP/TCP ) ) ) ) 一个建立在overlay网络上的传输层(也就是上面的inner UDP/TCP),本身已经完成了传输功能(比如TCP的话就是传输可靠性的保证等等特性),所以不需要在底层underlay网络再浪费资源做一次传输层保证了。而因为UDP跟IP都是datagram,不需要维护复杂的状态,所以被选为VXLAN的underlay协议。
作者回复: 恩蛮常见的现象,原因就是中间节点没有对icmp类型的消息做回复,但终点是做了。所以建议icmp和udp都做一遍,这样两张拼图互相缺失的部分就补起来了
作者回复: ss是linux的命令,mac可能无法安装。不过你可以试试安装一个ubuntu docker或者VM
作者回复: 赞,你的基础应该很好了,希望我的实际案例对你有补充和帮助~