现在用户量较大的机场的直连节点，还能较长期活着吗？/ Can airport direct-connect nodes with a large number of users stay alive in the longer term now?

[crazysvn]

我的节点目前也就几十个人在用，但已经两天封一次端口了，害怕。一个CMI一个CN2，都这样了，用的trojan协议。以后如果用户增加个十倍以上，岂不是天天封ip了，那还搞个毛。 1.目前有考虑改用naiveproxy，但据说也可能被封， 不知道被封的概率？另外就是比较缺少支持的客户端。 2.请问从封端口到封ip大概多久？或者换多少次端口后就基本会被封ip? 3.用所谓隧道中转的话，隧道本身是在什么情况下会被封？隧道更不容易被封的原因仅仅因为其是单ip连国外，还是因为其协议，或者其它？目前暂不考虑真IPLC之类巨贵的中转。

请问现在有啥办法能让节点较长期活着，比如两月不被封端口。

My nodes have only a couple dozen people using them at the moment, but they've been blocking ports once every two days, I'm afraid. One CMI and one CN2, both like this, using the trojan protocol. In the future, if the number of users increases by more than ten times, won't an ip get blocked every day? That will be useless.

1. At present, a change to use naiveproxy is being considered, but apparently that also may be blocked, I don't know with what probability? Also, there is a comparative lack of supported clients.
2. Roughly how much time is there between port blocking and ip blocking? Or, how many times can I change ports before my ip is basically blocked?
3. If I use the so-called tunnel to transit, under what circumstances will the tunnel itself be blocked? Is the tunnel less likely to be blocked just because it's a single-ip connection to a foreign country, or is it because of its protocol, or something else? I'm not considering expensive transit like true IPLC for now.

Please tell me what can be done now to keep the node alive for a longer period of time, like two months without the port getting blocked.

[sippejw]

你好 @crazysvn，

我是一名研究 TLS-in-TLS (在TLS隧道中建立的TLS连接) 的研究员，我所在的团队目前正进行一个项目，以确定这种流量是否以及如何在实际应用中被阻断。我们的合作者已经开发出在检测 TLS-in-TLS 流量的方法，并且我们已经在中国境内部署了实验以检测针对 Trojan 的封锁，但收效甚微。

如果您愿意就您了解的具体情况提供一些补充信息，这将对我们的项目有很多帮助。此外，也许我们的一些见解建议可以帮助您和其他社区成员减轻/缓解封锁。下面的这些问题将为我们发掘 GFW 如何检测和封锁这些代理提供非常有价值的信息。如果方便，您也可以直接通过电子邮件与我联系：jackson.sippe@colorado.edu。

• 能否提供 Trojan 的详细配置信息：包括选择的端口以及版本等。
• 能否提供一些流量上的统计信息：每天的连接数、不同 IP 用户总数、传输的数据总量？
• 服务器托管在哪里？您可以提供 ASN 或云服务商的名称。
• 您是否知晓用户正在使用哪种客户端以及这些客户端是怎样配置的？
• 这种阻塞是什么时候开始出现的？端口封锁是否每一天发生在相同时间？
• 如果不是，那么出现阻塞之前是否有任何其他异常？是来自未知 IP 的连接，还是来自某些特定 IP 或客户端的连接？

我们也欢迎您随时通过电子邮件私下与我们取得联系。感谢您的帮助！

Hi @crazysvn, I am a researcher studying TLS in TLS traffic identification and my group is currently working on a project to determine if and how this traffic is blocked in the wild. Our collaborators have developed methods for detecting TLS in TLS traffic and we have been running experiments within China to detect blocking of trojan with limited success. If you would be willing to provide some additional information about your specific situation it would be incredibly helpful to our project. Additionally, we may be able to offer suggestions to you and the rest of the community on mitigating the blocking. The questions below will provide much needed insight into how GFW is detecting and blocking these proxies. You can also reach out to me directly via email at jackson.sippe@colorado.edu.

• Can you provide configuration details of trojan, what ports you have been selecting, version, etc.
• Can you provide any traffic heuristics: number of connections per day, number of unique IPs, amount of data transferred?
• Where was the server being hosted? Either the ASN or the name of the cloud provider.
• Are you aware of the particular clients that users are using and how those have been configured?
• When did you begin to experience this blocking? Are the ports getting blocked at the same time each day?
• If not, are there any anomalies prior to experiencing blocking? Connections from unknown IPs or connections from a specific IP or client?

You are more than welcome to respond privately via email and we can discuss further. Thank you for your help!

[hanshelm02]

Hi, @sippejw . your project sounds really interesting and I think I can help out with some details. Let’s chat more about this? Drop me a message at [address redacted] and we can dive into it.

[sippejw]

Hi, @hanshelm02. I have followed up via email from jackson.sippe@colorado.edu. I look forward to hearing from you.