一张完全常规的技术支持票证发现了俄罗斯几个地区意外的Protonmail IP地址禁令，Protonmail是一项非常有用的服务，可帮助人们评估其互联网自由，这是一项非常有用的服务。 我真的不想引起轰动，但这个故事是如此的奇怪和莫名其妙，我无法抗拒。
TL; DR
免责声明：情况仍在发展。 可能没有恶意，但很可能是恶意。 一旦收到新信息，我将更新帖子。
俄罗斯的两个最大的ISP MTS和Rostelecom开始根据FSB的请求阻止对加密电子邮件服务Protonmail的SMTP服务器的通信，而没有考虑政府对受限网站的正式注册。 似乎已经发生了一段时间，但没有人特别注意它。 到现在为止
所有相关方均已收到相关信息要求，并有义务予以答复。
UPD： MTS提供了FSB字母的扫描，这是限制访问的基础。 理由：正在进行的克拉斯诺亚尔斯克大运会和“电话恐怖主义”。 应该防止ProtonMail电子邮件发送到安全服务和学校的紧急地址。
UPD： Protonmail对“这些陌生的俄罗斯人”及其打击欺诈滥用的方法感到惊讶，并提出了一种更有效的方法-通过滥用邮箱 。
UPD： FSB的辩解似乎不正确：禁令破坏了ProtonMail的传入邮件，而不是传出邮件。
UPD： Protonmail耸了耸肩，并更改了它们MX的IP地址，从而使它们脱离了该特定FSB字母之后的阻止。 接下来将发生的是开放式问题。
UPD：显然，这封信不是唯一的一封信，仍然有一组VOIP服务的IP地址，这些地址在受限制的网站的正式注册表中没有适当的记录就被阻止了。
我们喜欢Habr用户，因为他们精通技术。 他们了解“计算机卫生”的含义。 我们的某些用户一直在使用Protonmail （一种“加密电子邮件”服务）。 今天，我们将只讨论技术问题，而不再讨论服务本身及其业务模型。
每天我们都会向用户发送大量电子邮件，并且由于我们关心自己的独立性和隐私权，因此我们不使用外部邮件服务（ESP）。 相反，我们使用我们自己的资源，从裸机服务器和自维护的MX服务器到加密连接并拥有我们的独立IP地址。
上周，我们的支持团队因来自Protonmail用户的消息而超负荷，他们抱怨我们的邮件无法发送给他们：
你好 从2019年3月的第一周开始，当我尝试登录时，我得到一个红色的横幅，说他们无法向我的地址发送电子邮件。 我试图手动发送测试消息，但无济于事，由Protomail托管的邮箱本身功能完善（其他电子邮件也可以使用）。 Habr的最后摘要是2月28日。
我没有更改那里或Protomail上的任何设置，但是在第一次出现问题时，我退出了Android应用程序。
我认为该帐户没有受到破坏，但是我找不到用于访问该帐户的IP列表，因此无法确定。 希望您的帮助，因为没有有效的电子邮件，我无法对评论/帖子进行投票。
将电子邮件地址从Gmail更改为Protomail。 确认电子邮件未到达新地址。
当然，我们的技术支持建议使用诸如检查垃圾邮件文件夹之类的简单内容，但是类似投诉的数量之多迫使我们深入研究。
简要介绍电子邮件的工作原理对于大多数现代互联网用户而言，使用电子邮件意味着登录电子邮件服务提供商网站上的“个人收件箱”，然后通过相同的Web界面发送信件。 然后发生了一些魔术，不久之后，这封信就到达了接收端的Web界面。
这种“魔术”称为SMTP（准确地说是esmtp）。 发送服务器从接收地址中提取域部分（@之后），并向接收者域的MX服务器发出DNS请求。 对于support@habr.team，它看起来像这样：
MX代表“邮件交换”。 它指示接收方使用的电子邮件服务，或者确切地说，指示接收域的托管服务器收集新邮件的电子邮件服务器。 上面的示例表明，我们的域名habr.team由Google（G.Suite）托管。
找到MX服务器后，将通过esmtp协议向优先级最高的服务器发出请求，以将邮件传递给用户。 列出了多个服务器以实现冗余，因为Internet的“互连性”是一个非常相对的术语。
这就是发送信件的样子：
注意：不一定必须将来自特定域的邮件发送给DNS中列出的MX服务器上的用户； 这仅用于传入邮件。 可以通过通常在SPF记录中列出的其他服务器转发外发邮件。
我们浏览了邮件日志，发现从服务器到Protomail MX服务器（185.70.40.101，185.70.40.102）的连接尝试总是超时。 由于多种原因，这看起来很奇怪，并且类似于俄罗斯的互联网审查机制。
非常抱歉，但是我必须离题并告诉您互联网，自治系统和路由的工作方式通常，术语“互联网”由两个词组成：“互联网”，并且可以解释为“网络网络”或“联合网络”。 互联网没有“技术中心”（尽管它有“组织中心”）：它只是连接理论上彼此相等的不同网络（尽管某些网络比其他网络更平等，但这是改天讲故事）。 网络被称为“自治系统”（AS），并通过门或“对等”相互连接。 每个AS都有一个唯一的编号，供其他AS用来标识它。 类似于IP地址，但以更一般的方式。 每个网络都从其“邻居”接收到附近网络的连接拓扑，这些附近网络如何连接到其附近网络等。 从本质上讲，每个网络都具有从该网络的角度看所有AS如何相互连接的映射。 根据该映射从一个AS到另一个AS的路由简称为“ AS路径”。
例如，我们的自治系统号（ASN）为204671，Protonmail服务器托管在大型美国公司Neustar的网络上，其ASN为19905。我们有两个与ISP相连的大门，这意味着从我们到Neustar的两条可能的AS路径网络。 由于多种原因，最好选择其中一个（通过MGTS），因此我们的AS路径如下所示：204671（美国）-57681（MGTS，ISP），8359（MTS，较大的ISP）-22822（Limelight ）-19905年（Neustar）。
这是路由表：
到Protonmail的两个MX服务器中的任何一个的每个路由都在MTS网络上断开，如下所示：
GW-Core-R3#traceroute ip 185.70.40.101 probe 1 timeout 3 Type escape sequence to abort. Tracing the route to 185.70.40.101 VRF info: (vrf in name/id, vrf out name/id) 1 185.2.126.73 [AS 57681] 2 msec 2 212.188.12.73 [AS 8359] 2 msec 3 195.34.50.73 [AS 8359] 3 msec 4 212.188.55.2 [AS 8359] 3 msec 5 * 6 * 7 * 8 *
我们在Neustar网络中找到了另一台主机，并以此作为参考来消除MTS和Limelight之间可能的干扰：
GW-Core-R3#traceroute ip 156.154.208.234 probe 1 timeout 3 Type escape sequence to abort. Tracing the route to 156.154.208.234 VRF info: (vrf in name/id, vrf out name/id) 1 185.2.126.73 [AS 57681] 2 msec 2 212.188.12.73 [AS 8359] 2 msec 3 212.188.2.37 [AS 8359] 14 msec 4 212.188.54.2 [AS 8359] 20 msec 5 195.34.50.146 [AS 8359] 27 msec 6 195.34.38.54 [AS 8359] 37 msec 7 68.142.82.159 [AS 22822] 26 msec 8 * 9 156.154.208.234 [AS 19905] 26 msec
同时，我们通过另一个ISP成功完成了对Protonmail的MX服务器的另一条跟踪（它在Neustar处中断，但是可以预期-连接仍然有效）：
$ traceroute -a 185.70.40.101 traceroute to 185.70.40.101 (185.70.40.101), 64 hops max, 52 byte packets 1 [AS49063] hidden (hidden) 5.149 ms 268.571 ms 6.707 ms 2 [AS49063] 185.99.11.146 (185.99.11.146) 5.161 ms 6.317 ms 5.476 ms 3 [AS0] 10.200.16.128 (10.200.16.128) 5.588 ms [AS0] 10.200.16.176 (10.200.16.176) 5.225 ms [AS0] 10.200.16.130 (10.200.16.130) 5.001 ms 4 [AS0] 10.200.16.49 (10.200.16.49) 6.480 ms [AS0] 10.200.16.156 (10.200.16.156) 5.439 ms 7.469 ms 5 [AS20764] 80-64-98-234.rascom.as20764.net (80.64.98.234) 6.208 ms 9.301 ms 6.348 ms 6 [AS20764] 80-64-100-102.rascom.as20764.net (80.64.100.102) 24.281 ms [AS20764] 80-64-100-86.rascom.as20764.net (80.64.100.86) 54.632 ms 23.936 ms 7 [AS20764] 81-27-254-223.rascom.as20764.net (81.27.254.223) 27.589 ms 116.438 ms 27.348 ms 8 [AS22822] siteprotect.security.neustar (68.142.82.153) 28.683 ms 25.376 ms 41.489 ms
鉴于traceroute并不是一个非常可靠的工具，因此我们进行了另外一些实验，例如，使用MTS的Looking Glass服务：
显然，这可能是MTS级别上的故意限制服务。 但是，咨询Roskomnadzor的官方注册表后发现，此处未列出两个地址（两个域名都没有IP）：
无法根据您的要求找到任何东西
撇开俄罗斯的互联网审查制度的细节而言，ISP封锁资源只有一个有效的理由-所谓的“注册表转储”，其中或多或少地合法地存放了该资源。 有时，资源会在没有相关注册表项的情况下被阻塞（俗称“无注册表阻塞”），通常在任何法律案例中都没有理由提出这些要求。
在这一点上，我们怀疑是简单的技术误解或另一个无关站点的恶意解锁。 是的，我们不会在没有仔细检查所有事实的情况下发出警报。
我们向MGTS技术支持发送了一封电子邮件，详细说明了我们的发现，并要求澄清。 过了一会儿，我们收到一个无法回答的问题：“不是我们，是MTS，问他们。” 当然，我们没有这么做，而是迫使MGTS做好工作并进行适当的调查。 我们得到的回应非常有趣：据相关部门的MTS员工称，FSB已于2019年2月25日通过第12 / T / 3 / 1-94号正式信函与他们联系，要求他们紧急封锁这些主机：
在这一点上，我们的胡说八道的探测器已经超出了规模，我们挖得更深了。 而且更快。
我们向FSB发送了一个请求，询问该信件是否存在以及是否存在，他们有何理由？
我们还要求MGTS提供理由：
之后，我们去了俄罗斯某个即时通讯服务中某些非法的一些主题聊天室。 电信界很不情愿地做出了反应：
- “我有解决这些问题的经验，没有人愿意使用RKN的工具。 首先，它很复杂。 其次，将问题转移到另一个部门并不能解决问题。”
- “您需要提供这么多的文档，跳过那么多的官僚作风（并且如果不做所有这些事情，将受到金钱的惩罚），没有人会打扰。”
好吧，很难真正判断它们，因为电信行业的员工必须处理这么多废话（考虑“ SORM”，“网络节点”或“注册表转储”不只是对他们的言语，而是每天的烦恼） 。
尽管如此，俄罗斯互联网防御社区的聊天室还是对此案进行了热情的调查，并对他们自己进行了适当的调查。
他们提出了一个有趣的想法-检查哪些ISP（在俄罗斯或其他国家）阻止通过RIPE Atlas访问MX服务器。 结果是可以预见的，但仍然很奇怪：在俄罗斯，服务器被MTS和Rostelecom以及通过这两个ISP工作的网络（ 主要MX服务器和备用 MX服务器 ）阻止。 全球检查在俄罗斯，乌克兰和伊朗检测到问题（ 主服务器和备份的 全球结果 ）。
一项更具参与性的研究表明，Rostelecom的行为类似：
周末之后，MTS最终提供了对订购该区块的FSB字母的扫描。 当然，他们指责``电话恐怖分子''并将其全部归因于第二十九届世界大学冬季运动会-大运会2019：
然后，Protomail代表对reddit ， Twitter和TechCrunch做出了反应。 不出所料，他们对FSB的方法过钝感到惊讶，并愿意合作寻找真正的罪犯：
嗯 Protomail自己怀疑所有这些都有隐藏的议程。 好吧，这似乎是事实。 因此，正如我已经解释过avobe一样，MX记录是一种处理传入电子邮件的机制。 FSB显然是故意破坏了传入的邮件而不是传出的邮件，因此，他们清楚地证明了拯救学校校长免于麻烦的“合理性”。 因此，我们有三个选择：
- 他们只是阻止了他们最初发现的东西（这是一个懒惰的解释，但是根据Occam Razor的说法，这很可能是这样的：某人一定只是读过“ nslookup for dummy”）。
- 他们试图限制建立匿名且无法追踪的质子地址的可能性，以收集有关自身的破坏性信息（在大多数情况下不起作用）
- 粗略的UFO解释。
证明就是这样：从Proton发送到另一服务的电子邮件通过了未被阻止的不同IP。 请记住，FSB禁止185.70.40.101和185.70.40.102。 你在这里看到这些吗？
ProtonMail的负责人向TechCrunch证实了这一发现，并建议与外国执法部门合作打击恐怖活动，而不仅仅是解决这个问题：
ProtonMail首席执行官安迪·颜（Andy Yen）在给TechCrunch的电子邮件中称该街区“特别是偷偷摸摸”。
日元说：“ ProtonMail不会以正常方式被阻止，实际上实际上更加隐蔽。” “他们阻止访问ProtonMail邮件服务器。 因此，Mail.ru-以及大多数其他俄罗斯邮件服务器-不再能够将电子邮件传递到ProtonMail，但是俄罗斯用户进入他们的收件箱没有问题，”他说。
日元说：“大量封锁ProtonMail的方式伤害了所有希望提高在线安全性的俄罗斯公民，这似乎是一种糟糕的方法。” 他说，他的服务比该国其他竞争对手提供更高的安全性和加密功能。
他解释说：“我们还采取了技术措施，以确保继续为我们在俄罗斯的用户提供服务，我们在这方面一直取得良好进展。” “如果确实存在合法的法律投诉，我们鼓励俄罗斯政府按照既定的国际法和法律程序重新考虑其立场并解决问题。”
-ProtonMail首席执行官安迪（Andy Yen）@ TechCrunch
同样，看起来这个FSB字母只是被命令阻止SMTP服务器接收传入的邮件。 Web访问和传出SMTP服务器仍然可以正常工作，这意味着无论FSB尝试做什么，它们都不是很擅长。
我们再说一遍：即使不理会在地球上十分特殊的1/8地域上规范互联网问题的整个法律方面，也存在游戏规则。 这些规则并不是十分清晰，非常模棱两可，并且会一直在变化，但是即使它们显然是为使这些规则的维护者受益而设计的，它们仍然是规则。 即使那样，也有人试图绕过它们。 这很像卡夫卡风格，根本没有正当程序。 至少在任何法院案件中，您都可以请一位行业专家进行咨询，但是该决定完全基于一个特定人的个人世界观。
因此，这是我们到目前为止收集到的所有事实。 所有请求都已发送，但并非所有请求都得到响应。 当然，我们希望这只是MTS某人工作拙劣的结果，但是，老实说，从一开始它看起来并不十分可能。
对于我们也使用Protomail的用户，则他们可以安全地继续使用Habr的Proton邮箱，因为我们通过不玩这类游戏的另一家俄罗斯ISP将流量从我们重新路由到Protomail服务。 MGTS可能会失去另一个客户。