それはすべて、ある晴れた朝、フォーラムforum.gsmhosting.comフォーラムに行くことができなかったという事実から始まりました。このリソースは私にとって特に役立つものではありませんでした。私のために開くことは少し驚きでした。 一時的な技術的な問題かもしれませんが、夕方にリソースの可用性を確認したところ、何も変わっていないことがわかりました。 それから私は問題が何であるかを理解しようとすることにしました。 2つのBeeline（L2TP）およびRostelecom（PPPoE）プロバイダーが接続ポイントに設定されています。これらはすべてMikrotikを通じて「統合」されています。 ロードバランシング、代替ルート選択などが使用されます。 ただし、HTTPやHTTPSなどの便利な機能はBeelineを介して開かれます。 forum.gsmhosting.comのnslookup Aレコードを見ると、次のことがわかりました。
Addresses: 104.27.158.203 104.27.159.203
ご覧のとおり、これらのアドレスは両方ともCloudFlareに属し、Rostelecomを介してこれらのIPのルーティングを構成しています-リソースが完全に機能していることがわかりました。 どうしたの？
ページhttp://moskva.beeline.ru/customers/help/safe-beeline/ugrozy-v-internete/zablokirovannye-resursy/で 、これらのIPアドレスの両方が実際にブロックされたリソースのリストに含まれるという情報をBeelineから取得できます。
同時に、連邦税務局2-6-27 / 2016-06-29-51-AI自体の法令を見つける試みは失敗しました。 また、フォーラムのIPアドレスとドメイン名は、ブロックされたリソースのリストに存在するかどうかを確認しました。
しかし、検証時にあちこちで、IPアドレスデータまたはドメイン名がレジストリに表示されなかったようです。
次のステップは、状況の詳細な説明とともにBeelineテクニカルサポートに連絡し、次の回答を受け取ったことです。
サブネット104.27.159.203/32がブロックされました。これはリソースmarathonbet.ccに関連しており、連邦税務局の決定によりアクセスがブロックされました。
現在、リソースforum.gsmhosting.comの背後にあるIP 104.27.159.203
資源所有者から連邦監視センターへの控訴が受領されました。
しかし、実際には別のプロバイダー-149-forum.gsmhosting.comの要件にも準拠するRostelecomが開かれましたが、ブロックされたmarathonbet.ccはなく、プロバイダーの代表者への返信で報告されました。
このサブネットが何であるかを理解している場合、このサブネットはアドレスプールhttps://www.cloudflare.com/に属します。 ご存知のように、CloudFlareのCDNを使用しているサイトは1,000以上あります。これが、marathonbet.ccのブロックが原因で正当なリソースが影響を受ける可能性がある理由です。 この状況は、最近のAmazon S3サービスのブロックと比較できます。 リソースforum.gsmhosting.comの所有者および連邦監視センターへの他の「犠牲者」からのアピールに関しては、ここではすべてが明らかであり、そのようなアピールはありません。 ヨーロッパでは、彼らは単にそのようなセンターの存在とロシアでの何かの妨害について知らない。
それでも、Rostelecomでは、このロックが正しく実装されており、marathonbet.ccを開こうとすると、ユーザーはスタブページhttp://warning.rt.ru/?id=13&st=0&dt=104.27.159.203&rs=marathonbet.cc/に 302を使用して自動的にリダイレクトします。リダイレクト。 HTTP経由でこのIPにある他のサイトは、非常に正しく開きます。
Beelineでは、すべてが「より興味深い」ものです。 そのmarathonbet.ccを開き、そのforum.gsmhosting.comのスタブhttp://blackhole.beeline.ru/が終了しない場合、接続はビーライン側で切断されます。 この場合、ブロッキングを実装するために考えられるすべてのソリューションの中で、残念ながら、Beelineは最も誤ったものを選択しました。
少なくとも「競合他社が149-FZの要件をよりよく満たす」レベルで、既存の問題に注意を向けることができれば、将来的には解決が期待できると思います。
psこの問題の解決策は、HTTPプロバイダー経由のアクセスがHTTPプロトコルヘッダーのHostフィールドの分析に干渉しない一方で、指定したIP over HTTPSをブロックすることです。 これがまさにRostelecomで起こることです。
しかし、それに応じて、簡単な返信を受け取りました。
このようなリソースのブロックは、サブネット104.27.159.203/32全体で正確に実行されます。
marathonbet.ccリソースに関係のないリソースの所有者は、連邦税務署に連絡してロックを解除するか、ホスティングプロバイダーに連絡して、サブネット104.27.159.203/32からのアドレスを提供し、正しいアドレスを提供するよう依頼する必要があります。
当然、競合他社は同様のブロックの実装に関するコメントを考慮していませんでした。また、通常の要求に対して適切な指示を持っている、第一レベルTPの通常の従業員が応答したようです。 サブネット全体として単一のIPアドレス104.27.159.203/32を指定する他の理由、少なくとも表示されません;）
最後に何がありますか？ 多くのリソースが何らかの方法でCloudFlareのCDNサービスを使用しています。この場合、一部のプロバイダー（同じビーライン）によってブロッキングがIPによって実装されています。 ブロックされたIPへのHTTPおよびHTTPS呼び出しは、プロバイダー側のファイアウォールによって単に「カット」され、加入者に追加の通知は行われません。 一方、一部の（Rostelecom）は、このようなロックの実装に対してより正確なアプローチを実装しています。たとえば、HTTPSを介してアクセスしようとするとIPのみをブロックし、HTTPを使用すると他のリソースは影響を受けません。 要求ヘッダーのHostフィールドを解析します。
「Beelineでの状況」に関するその後のチェックでは、他のリソースがプロバイダーによってブロックされており、そのAレコードがCloudflareプールに属していることが示されました。これは完全にIPによるものです。