皆さん、こんにちは。RosKomNadzorからの最新ニュースに照らして、私はプロバイダーがどのようにロックを操作するかを調べることにしました。 GoogleのDNSは保存されず、ブロックされたサイトはHTTPリクエストを禁止されたサイトに割り当て、見つかったTCPセッションからパケットをドロップすることで機能することが判明しました。 しかし、少し選んだ後、1つのbusyboxで十分であることがわかりました。 誰も気にしない-猫の下でウェルカム。
すぐにブロックの実装がプロバイダーに依存することを予約してください。私の方法はうまくいかないかもしれません。 そこで、よく知られているサイトrutracker.ogrの例を考えます（投稿のドメインとIPアドレスは回避するために変更されました）。
プロバイダーが一般的にどのように応答するかを確認するための簡単な要求から始めました。
ホームページリクエスト
wget -O / dev / null "rutracker.ogr" --2016-02-10 01:21:18-http：//rutracker.ogr/ 認識されたrutracker.ogr（rutracker.ogr）... 195.82.147.214 rutracker.ogr（rutracker.ogr）への接続| 195.82.147.214 |：80 ...接続が確立されました。 HTTPリクエストが送信されました。 回答を待っています...
ダンプパッケージ
01：25：10.736021 IP 192.168.5.2.53724> 195.82.147.214.80：フラグ[S]、seq 778021515、win 29200、オプション[mss 1460、sackOK、TS val 40091571 ecr 0、nop、wscale 7]、長さ0 01：25：10.771529 IP 195.82.147.214.80> 192.168.5.2.53724：フラグ[S。]、seq 866160985、ack 778021516、win 14600、オプション[mss 1400]、長さ0 01：25：10.771562 IP 192.168.5.2.53724> 195.82.147.214.80：フラグ[。]、Ack 1、29200を獲得、長さ0 01：25：10.771701 IP 192.168.5.2.53724> 195.82.147.214.80：フラグ[P。]、seq 1：141、ack 1、win 29200、長さ140：HTTP：GET / HTTP / 1.1 01：25：11.129078 IP 192.168.5.2.53724> 195.82.147.214.80：フラグ[P。]、seq 1：141、ack 1、win 29200、長さ140：HTTP：GET / HTTP / 1.1 01：25：11.849176 IP 192.168.5.2.53724> 195.82.147.214.80：フラグ[P。]、seq 1：141、ack 1、2929を獲得、長さ140：HTTP：GET / HTTP / 1.1 01：25：13.292495 IP 192.168.5.2.53724> 195.82.147.214.80：フラグ[P。]、seq 1：141、ack 1、2929を獲得、長さ140：HTTP：GET / HTTP / 1.1
クライアントは正常に接続し、リクエストを送信するだけです。 タイムアウト前のTCPフォワーダーの束。 DPIはセッションを認識し、禁止されたものとしてドロップしました。 そして、何らかの理由で、私は同じことを試してみましたが、Telnetを使用しました。
telnet経由のページ要求
telnet rutracker.ogr 80 195.82.147.214を試す... rutracker.ogrに接続しました。 エスケープ文字は「^]」です。 GET / HTTP / 1.1 ユーザーエージェント：Wget / 1.16.3（linux-gnu） 受け入れる：* / * Accept-Encoding：identity ホスト：rutracker.ogr 接続：キープアライブ HTTP / 1.1 301が永続的に移動しました サーバー：nginx 日付：2016年2月9日火曜日22:29:50 GMT コンテンツタイプ：テキスト/ html コンテンツの長さ：178 場所：http：//rutracker.ogr/forum/index.php 接続：キープアライブ <html> <head> <title> 301恒久的に移動</ title> </ head> <body bgcolor = "white"> <center> <h1> 301を恒久的に移動</ h1> </ center> <hr> <center> nginx </ center> </ body> </ html>
telnetを介した要求に応じてパケットをダンプする
01：33：15.354300 IP 192.168.5.2.53782> 195.82.147.214.80：フラグ[S]、seq 4112340002、win 29200、オプション[mss 1460、sackOK、TS val 40236956 ecr 0、nop、wscale 7]、長さ0 01：33：15.389921 IP 195.82.147.214.80> 192.168.5.2.53782：フラグ[S。]、seq 3472440534、ack 4112340003、win 14600、オプション[mss 1400]、長さ0 01：33：15.389967 IP 192.168.5.2.53782> 195.82.147.214.80：フラグ[。]、Ack 1、29200を獲得、長さ0 01：33：16.226472 IP 192.168.5.2.53782> 195.82.147.214.80：フラグ[P。]、seq 1：17、ack 1、win 29200、長さ16：HTTP：GET / HTTP / 1.1 01：33：16.263181 IP 195.82.147.214.80> 192.168.5.2.53782：フラグ[。]、Ack 17、14600を獲得、長さ0 01：33：16.263214 IP 192.168.5.2.53782> 195.82.147.214.80：フラグ[P。]、seq 17：139、ack 1、win 29200、長さ122：HTTP 01：33：16.298317 IP 195.82.147.214.80> 192.168.5.2.53782：フラグ[。]、Ack 139、win 14600、長さ0 01：33：16.789180 IP 192.168.5.2.53782> 195.82.147.214.80：フラグ[P。]、seq 139：141、ack 1、win 29200、length 2：HTTP 01：33：16.827756 IP 195.82.147.214.80> 192.168.5.2.53782：フラグ[。]、Ack 141、勝利14600、長さ0 01：33：16.828043 IP 195.82.147.214.80> 192.168.5.2.53782：フラグ[P。]、seq 1：383、ack 141、win 14600、長さ382：HTTP：HTTP / 1.1 301が永久に移動しました 01：33：16.828067 IP 192.168.5.2.53782> 195.82.147.214.80：フラグ[。]、Ack 383、win 30016、長さ0 01：33：20.376119 IP 192.168.5.2.53782> 195.82.147.214.80：フラグ[F。]、seq 141、ack 383、win 30016、長さ0 01：33：20.412142 IP 195.82.147.214.80> 192.168.5.2.53782：フラグ[F。]、seq 383、ack 142、win 14600、長さ0 01：33：20.412177 IP 192.168.5.2.53782> 195.82.147.214.80：フラグ[。]、Ack 384、win 30016、長さ0 01：33：30.299143 IP 192.168.5.2.53780> 195.82.147.214.80：フラグ[FP。]、Seq 1515330593：1515330733、ack 3791059975、win 29200、長さ140：HTTP：GET / HTTP / 1.1
実際、この時点で、DPIはペイントほどひどくないことが明らかになりました。 ダンプをよく見ると、telnetが別のパケットで要求の最初の行を送信していることがわかります。 つまり、DPIはTCPストリームを分析しませんが、クライアントからサーバーへのデータを含む最初のパケットは、データベースを突破するためにホストのパスとフィールドからUrlを収集しようとします。 パスを含む最初のクエリ行とホストフィールドを含む行が異なるパケットで引き離された場合、DPIはそのようなセッションを正しく処理できず、スキップします。
ケースは小さいままでした。 TCPセッションの最初のHTTPリクエストのヘッダー（Connection：Keep-Aliveを思い出してください）を2つのパケットに分割し、残りを単に送信するプロキシを作成する必要がありました。 また、ホームネットワーク全体を提供するために、このプロキシをOpenWrtの下のルーターで動作させたいと考えました。 そのようなプロキシを作成するには多くの方法がありますが、私は、ボックス化されたソリューションではなく、概念実証を作成することを目標としていたため、最も怠zyで、最も速く、最もぎくしゃくしたものを選びました。
プロキシとして、tcpsvdの下から実行するシェルスクリプトがあります（デフォルトでは、tcpsvdアプレットはOpenWrtのbusyboxでは利用できないため、標準のbuildrootを使用して再構築する必要があります）。 念のために、tcpsvdはポートをリッスンし、クライアントが接続するときに子プロセスを開始し、その入出力をソケットにリダイレクトするようなものであることを思い出させてください。
このスクリプトのようになりました（足で叩かないでください、これは単なる概念の証明です）
#!/bin/sh # appendLine() { if [[ ! -z "$1" ]] then echo -ne "$1\r\n$2" else echo -ne "$2" fi } header1="" header2="" host="" while [[ true ]] do # read -r line # 0x0D line=`echo "$line" | tr -d "\r"` # if [[ -z "$line" ]] then break fi # , Host: header1, - header2 if [[ -z "$host" ]] then if [[ `echo "$line" | grep -c "Host:"` -eq "1" ]] then host=`echo "$line" | sed -re 's/^Host: (.*)\r?$/\1/'` header2=`appendLine "$header2" "$line"` else header1=`appendLine "$header1" "$line"` fi else header2=`appendLine "$header2" "$line"` fi done { # echo -ne "$header1\r\n" # , netcat , , - sleep 1 # echo -ne "$header2\r\n\r\n" # , DPI , - cat 2>/dev/null } | nc "$host" 80
念のため、TCPセッションの開始時にのみ1秒間待機することを明確にします。通常、ブラウザはセッションを切断せず、リクエストを送信し続けるため、明らかなブレーキはありません。
この松葉杖プロキシは次のように始まります。
tcpsvd 0.0.0.0 3128 ./proxy.sh
何らかの方法でブラウザからプロキシにトラフィックをリダイレクトするだけです。 たとえば、次のようにこれを行うことができます 。または、禁止サイトのリストからプロキシ自動検出ファイルを生成できます。 2番目のオプションはより単純で、怠lazが再び勝ち、次のようになりました。
{ echo -e "function FindProxyForURL(url, host)\n{\n\tif (" wget "http://api.antizapret.info/group.php?data=domain" -O- | sed -re 's/^(.*)$/localHostOrDomainIs(host,"\1") || /' echo -e "false)\n{ return \"PROXY 192.168.5.1:3128\"; }\nreturn \"DIRECT\";\n}"; } > ~/antidpi.pac
このファイルをプロキシ設定にスリップした後、禁止サイトが疑いなく開かれ始めました。
怠け者でない人がプロキシを正常にしたり、自転車を発明した場合は、既成の標準ソリューションを示してくれたら嬉しいです。
それだけです、ご清聴ありがとうございました。