Clever Geek Handbook

Rostelecomによるサイトのブロックメカニズムの調査とそれを回避する方法

この投稿では、Rostelecomがサイトをブロックするメカニズムについて簡単に説明し、サードパーティのホスト（プロキシ、VPNなど）へのさまざまなトンネルを使用せずにサイトをバイパスする方法を示します。 これは、いくつかの他のプロバイダーに適用される可能性があります。



ロック結果



RTはしばらくの間、IPではなくURLによってHTTPサイトをブロックしてきました。

ブロック時に、 95.167.13.50 /？st = 0＆dt = < IP> ＆rs = <URL>の形式のリダイレクト。ここで、<IP>はブラウザーが接続されているIP、<URL>は要求したURLです。 送信されたトラフィックを見ると、サーバー応答の先頭のみが上書きされ、残りはそのままであることが明らかになります。
こんな感じ 
 HTTP / 1.1 302が見つかりました
接続：閉じる
場所：http://95.167.13.50/?st=0&dt=192.237.142.117&rs=grani.ru/

 f-8
転送エンコード：チャンク
接続：キープアライブ

 6d7
 <！DOCTYPE HTML>
 <html lang = "ru" xmlns：fb = "http://www.facebook.com/2008/fbml">
   <head>



     <メタ文字セット= "utf-8">

     <タイトル>
       Grani.ru：
      主なもの
     </ title>
 ...


サイトの本当の答え 
 HTTP / 1.1 200 OK
サーバー：nginx / 1.2.1
日付：日曜日、2015年2月1日17:34:03 GMT
 Content-Type：テキスト/ html; 文字セット= utf-8
転送エンコード：チャンク
接続：キープアライブ

 6d7
 <！DOCTYPE HTML>
 <html lang = "ru" xmlns：fb = "http://www.facebook.com/2008/fbml">
   <head>



     <メタ文字セット= "utf-8">

     <タイトル>
       Grani.ru：
      主なもの
     </ title>
 ...


つまり ヘッダーを復元する方法を見つけた場合、ロックをバイパスできます。 明らかに、これは最も手頃な方法ではありません。



ブロックされるものと方法



RTサイトのブロックが手動制御であることは明らかです。



レジストリのすべてのサイトがブロックされるわけではありません。 少なくとも、まったくブロックされていないHTTPSサイトがいくつかあります。

通常、HTTPSサイトはIPによってブロックされます。プロバイダーが証明書に代わってHTTPSにクロールする場合があり、この場合はURLによってブロックされます。



レジストリからのHTTPSサイトは、HTTPによってのみ（IPではなくURLによって）ブロックされ、HTTPS経由で簡単にアクセスできる場合があります。



より深く探る



一連の実験の過程で、次のロックの原則が特定されました。





回避策



したがって、次の回避策があります。





実用的な実装



3proxyに基づく実装を選択しました。 正規表現に基づいて送信されたすべてのデータを変更できるプラグインが含まれています。 同時に、プロキシは非常に軽量で要求が厳しくなく、通常のルーターにインストールできます。



前述のとおり、実際の最も便利なオプションは、ホストの前に追加のヘッダーを追加し、ホストヘッダーを変更することです。 明らかに、ホストの変更が望ましいのは、 要求のサイズは増加しません。 私は定期的にこの方法を使用して、どの情報を消費できるかを自分で決定します。



ただし、一般的に、両方のオプションは簡単にカスタマイズできます。

追加の見出しを追加する 
 pcre_rewrite cliheader dunno "Host：" "X-Something：\ r \ nHost："
ヘッダーの変更 
 pcre_rewrite cliheader dunno "ホスト：" "ホスト："


基本設定 
 ＃DNSサーバー
 nserver 77.88.8.8
 nserver 8.8.8.8
 ＃キャッシュDNS
 nscache 65536
 ＃バックグラウンドで作業する
デーモン
 ＃プラグイン接続、フルパスを指定する価値があります
プラグインPCREPlugin.ld.so pcre_plugin
 ＃上記のルールの1つ
 pcre_rewrite ...
 ＃プロキシを起動し、オプション-aを使用すると、Forwarded-ForおよびViaヘッダーを削除できます
プロキシ-a -p8080




UPD：

@ValdikSSは非常に興味深いコメントを述べました。

Rostelecomからインターフェイスに着信するトラフィックを見るとすぐに。 DPIはおそらく直列ではなく並列に接続されており、そこにはクライアントトラフィックのみが入ります。 なぜなら DPIはWebサイトよりも明らかに近く、DPIからのロケーションを持つパッケージはサイトからの実際の最初のパッケージよりも早く到着し、サイトからのパッケージはOSカーネルによって再送信としてすでに破棄されているため、Linuxを使用している場合、iptablesの1行でロックをバイパスできます： 



iptables -A INPUT -p tcp --sport 80 -m string --algo bm --string "http://95.167.13.50/?st" -j DROP


私から：

実際、再送信があります。 私はトラフィックを見ましたが、明らかに十分に慎重ではありませんでした。

最初にHTTP 302とロケーションのみを含むパケットが送信され、次に通常のサイト応答を含むパケットが送信されます。

ただし、システムは2番目のパケットを破棄せず、1番目のパケットと統合します。

つまり パッケージが来る

1 
 HTTP / 1.1 302が見つかりました
接続：閉じる
場所：http://95.167.13.50/?st=0&dt=192.237.142.117&rs=grani.ru/
2 
 HTTP / 1.1 200 OK
サーバー：nginx / 1.2.1
日付：日曜日、2015年2月1日17:34:03 GMT
 Content-Type：テキスト/ html; 文字セット= utf-8
転送エンコード：チャンク
接続：キープアライブ

 6d7
 <！DOCTYPE HTML>
 ...
そして、アプリケーションはこれを見ます

だから 
 HTTP / 1.1 302が見つかりました
接続：閉じる
場所：http://95.167.13.50/?st=0&dt=192.237.142.117&rs=grani.ru/

 f-8
転送エンコード：チャンク
接続：キープアライブ

 6d7
 <！DOCTYPE HTML>
 ...


これは、WindowsとLinuxの両方で見られます。



しかし、上記のiptablesルールは実際に問題を解決します。


+1回避策。



この方法は、ゲートウェイ/ルーターでも使用できます。 もちろん、ルールはFORWARDチェーンに追加する必要があります。


More articles:


All Articles