1.这个问题可以总结为当ILB后端server 1 Telnet ILB 80时，如果ILB把流量转发到server2 ，则会Telnet成功，如果ILB把流量转发到server1自身，则会失败。
2.根据我们的测试和后台的确认，Azure ILB会对进入的流量做DNAT，对于内部server出去的流量，会做SNAT
情景1：当server1 去telnet ILB 80时，ILB将流量转发到server2时会出现Telnet成功，这时ILB会对目的地址做一个转换，转换成server2的ip。此时这个请求的格式会变成
目的MAC：server2的MAC | 源MAC：ILB的MAC | 目IP：server2 的IP10.0.1.6 | 源 ip：server1的IP10.0.1.5 |
当Server2回复这个包的时候，由于ILB充当的是网关的作用，所以这个包会回给ILB，ILB收到之后，会对这个包做一个SNAT，将原地址转换成ILB的地址。所以我们在server1上抓包的结果是Server1在和ILB 通信，但是在server2上抓包时，会看到server2在和server 1通信。
情景2：当server1去telnet ILB 80时，ILB将流量转发到server1自身时会出现Telnet失败。这是因为ILB会对流量做一个DNAT。格式是
目的MAC：server1 MAC | 源MAC：ILB MAC | 目的ＩＰ:Server 1 的IP 10.0.1.5 | 源ip:server1的IP，10.0.1.5 |
当server1收到上述包之后，就会开始构建回包，此时他查到目的IP是自身，这样的包属于loopback环回包。会直接在虚拟机里丢弃。
目的ＩＰ:Server 1 的IP 10.0.1.5 | 源ip: server 1ip 10.0.1.5 |
在虚拟机里抓包会看到虚拟机会每隔3s重新发出 SYN包。但没有收到ILB回复的ACK包，于是Telnet显示结果就会出现timeout
工程师建议：
===========
这是平台ILB的设计和TCP/IP 协议原理决定的。后端server不作为Client即可避免这个问题。
ILB配置后telnet不通
原文地址：http://blog.51cto.com/286722/2056396