At the “publications” subforum, the authors of the recent “Measuring and Evading Turkmenistan’s Internet Censorship” are asking for help from people in Turkmenistan to check their observations. They tested for censorship by sending DNS queries and HTTP/HTTPS requests into the country and checking for packets injected by the firewall.
One of the surprising results was that not every IP address in Turkmenistan triggered censorship. For example, sending a packet with a destination address of 95.85.96.36 triggered censorship, while 95.85.96.35 did not. The authors want help in checking whether the same is true in the other direction: whether censorship can differ based on the source address of a person in Turkmenistan.
agts: wikipedia works, hrw is dns banned, twitter is ip and dns banned
telecom: wikipedia works, hrw is dns banned, twitter is ip and dns banned
tmcell: wikipedia works, hrw works, twitter is ip banned
We were able to obtain two vantage points in agts and telecom and have some insight into your measurements.
We observed that twitter.com was both IP and DNS blocked, but that it was HTTP(S) blocked as well (i.e. if twitter.com was moved to a different IP address, it would still be blocked).
hrw.org is DNS blocked, but it is also HTTP blocked, NOT HTTPS blocked. If your browser automatically redirects HTTP to HTTPS, then it’s possible you would not experience censorship.
Furthermore, wikipedia.com is blocked over HTTP but NOT HTTPS, so similar to the case with hrw.org, if your browser automatically redirects HTTP to HTTPS, you may not experience censorship.
We still experienced inside->outside censorship from the two vantage points we obtained in telecom and AGTS, which both have external IPs that are not censored from the outside->inside direction. I do wonder if dynamic IPs are responsible for this behavior.
We discovered something odd that may not point to a load balancer being responsible for this behavior. When we run traceroutes from multiple vantage points across the world to an IP address subjected to censorship vs an IP address NOT subjected to censorship in AS20661, we observe a fork in the paths. This happens even if the IPs are within the same /24 network, such as in the case for 95.85.96.36 vs 95.85.96.35.
More specifically, packets destined to IPs subjected to censorship pass through routers within 217.174.235.0/24 when they first enter Turkmenistan’s network. When sending TTL limiting probes to such IP addresses using a censored domain, we can pinpoint at which hop the censor sits at. This hop always has an IP address within 217.174.235.0/24 as well and is approximately the third hop from when the packet first enters Turkmenistan’s network. We do not see packets destined for IPs that are NOT subjected to censorship enter this /24 network at all.
What’s interesting is that this routing decision seems to be made by the provider of AS20661, AS12389 (a Russian AS), because the fork occurs before it first enters Turkmenistan’s network. Perhaps it is unintentional that we don’t see all IPs censored from the outside->inside direction; the routing decision just causes packets to some IPs to not pass through the censor.
I’m not sure I quite understand. Are you asking to check whether from the inside->outside directions, the DNS injector does not filter a censored domain if the destination server is within a non-routable subnet?