VPNユーザー（およびその設定！）とサイトからのプロキシを定義します

<sup>暗闇から、悪から日を救うことができる

誰も必要ない</sup>



あなたの多くは、日常生活でVPNまたはプロキシを使用しています。 誰かがそれを絶えず使用し、州または企業レベルでブロックされたリソースにアクセスします。多くの場合、地理的な場所の制限を回避するためにそれを使用します。 ご存知かもしれませんが、ビデオ、音楽、ゲームストリーミングの分野の大規模なインターネットプレーヤーは、国のアクセスできないコンテンツのロックを解除したり、購入を大幅に安くしたりして地理的制限を簡単に回避するユーザーを好まなかったのです。 例に目を向ける必要はありません。Netflixは、わずか2か月前にVPNのブロックに関する条項を追加することで使用契約を変更しました。 Huluもユーザーをブロックすることで罪を犯し、Steamは一般的にロシアからのロシア語を話さないユーザーを疑っています。 最近、企業は特定のユーザーだけでなく、VPNサービス自体のIPアドレスもブロックしようとしているため、VPNサービス自体とそのユーザーに不便が生じています。 彼らは特別な手段を使用していないようですが、選択的に手動でブロックしています。 ブロッキングはまったくサポートしていませんが、質問の技術的な部分に興味がありました：プロキシサーバーとVPNの使用をなんらかの方法でサーバー側から判断することは可能ですか？

特定の条件下では可能です。 そして非常に正確に。

MSSおよびMTU

MTU、または最大送信単位-1つのパケットで送信できるデータの最大量。 MTUは、ユーザーからリモートサーバーへのトラフィックが通過するルーターでも、すべてのネットワークアダプターにインストールされます。 ほとんどの場合、MTU 1500はインターネット上で使用されますが、顕著な例外があります。これは、ちなみに、特定の規則の対象となることがよくあります。



ブラウザーまたはネットワークで動作する他のソフトウェアがリモートサーバーへのTCP接続を作成すると、パケットヘッダーに最大セグメントサイズ（MSS）値が配置され、1つのパケットでセグメントを送信できる最大サイズがサーバーに通知されます。 この値はMTUに非常に近く、インターネット接続の可能性についてサーバーに即座に明らかにし、不必要な断片化を排除し、チャネルを完全に活用できるようにします。

何らかのプロトコル（PPTP、L2TP（±IPsec）、IPsec IKE）を使用してVPNに接続しているときにパケットを送信すると、そのパケットは別のパケットに置かれ（カプセル化され）、オーバーヘッドと大きなパケットをもたらしますVPNなしで断片化なしで送信された場合、今、あなたは断片化する必要があります。 このような断片化を回避するために、OSは、実際のネットワークインターフェースのMTUよりも少ないMTUをネットワークインターフェースにインストールします。そのため、OSは断片化を必要とする大きなパケットを作成しようとしません。

PPTP、L2TP（±IPsec）、IPsecの場合、私が理解しているように、トンネルのMTUの標準はなく、ほとんどの場合に機能するこのような値をすべて設定し、それらは目でインストールされます。 原則として、これは1400です。これにより、MTUが最大1440のチャネルで、断片化することなくPPTPを使用できます（たとえば、ロシアのプロバイダーでよくあるように、インターネットにアクセスするには別のトンネルが必要です）。 OpenVPN-おそらく最も人気のあるVPNオプション-それどころか、逆になりました。

Openvpn

古いまたは単に湾曲したソフトウェアとの互換性のために、OpenVPNはデフォルトでVPNインターフェースのMTU値を低く設定せず、カプセル化されたTCPパケット内のMSS値を変更します。 デフォルトで1450に設定されているmssfixパラメータは、これに責任があります。MSTを変更して、MTU 1450のチャネルを完全に利用するようにします。 断片化せずにMTU 1450以上のチャネルを通過するようにオーバーヘッドを計算します。 この結果、標準のmssfix 1450でOpenVPNユーザーを識別するだけでなく、接続プロトコル（IPv4、IPv6）、トランスポートレイヤープロトコル（TCP、UDP）、暗号化、圧縮、およびMACパラメーターを決定する機会もあります。 それらは独自のオーバーヘッドをもたらし、MSSに反映されます。

典型的なMSS値を見てみましょう。

プロトコル	ブロックサイズ	MAC	圧縮	MSS
UDP	64	SHA1	-	1369
UDP	64	SHA1	+	1368
TCP	64	SHA1	-	1367
TCP	64	SHA1	+	1366
UDP	128	SHA1	-	1353
UDP	128	SHA1	+	1352
TCP	128	SHA1	-	1351
TCP	128	SHA1	+	1350
UDP	128	SHA256	-	1341
UDP	128	SHA256	+	1340
TCP	128	SHA256	-	1339
TCP	128	SHA256	+	1338

64ビットのブロックサイズの暗号が使用されている場合、128がおそらくAESであれば、これはおそらくBlowfishです。



理論を検証するために、VyprVPNとibVPNの2つのVPNサービスがテストされました。 両方のサービスは、説明されている方法による設定の定義に従います。

この方法で検出されたくない場合は、サーバーとクライアントの両方でmssfixを0に設定して無効にし、MST 1460（IPv4の場合）を取得します。これは通常のMTU 1500に対応します。大多数のユーザーが持つ有線接続。 ただし、この場合、過度のフラグメンテーションが発生し、遅延が増加してスループットが低下するため、MTUを1400、1380などに設定するのが理にかなっている場合があります（2の倍数、または10以上）。 このような値は、モバイルインターネットなどのプロバイダーでよく使用されます。

プロキシ

プロキシサーバーがヘッダーを追加しない場合（X-Forwarded-Forなど）、プロキシサーバーを決定する方法は多くありません。 プロキシとVPNの技術的な違いは何ですか？ VPNの場合、リモートサーバーは、OSが未変更の（多くの場合）形式で作成したパッケージを受け取ります。 一方、プロキシは、リモートサーバーに関するすべての情報（IP、ポート、その他のパラメーター）とデータのみを受信し、プロキシ自体の側でパケットを作成して送信します。 さまざまなOSがさまざまな方法でパッケージを作成し、バージョンごとに違いを見つけることができます。 パッケージの作成者のOSを非常に正確に判断できますが、このバージョンはあまり興味がありません。

プロキシはLinuxおよびBSDで実行されることが最も多く、Windowsでより頻繁に使用されるように思えます。 ユーザーは、使用しているOSを含むUser-Agentをブラウザーで変更することを考えないことがよくあります。これは手近にあります。

p0f

私たちのニーズにぴったり合う素晴らしいプロジェクトp0fがあります。 受動的にトラフィックをリッスンし、OS、MTU、およびブラウザーを判別し、パッケージの作成者とUser-AgentのOSが一致しないことを通知できます。 さらに、APIがあります。 APIを使用してMTUエクスポートを追加し、署名を更新することにより、一般的なVPNプロトコルのユーザー、プロキシユーザー、およびUser-Agentを偽るユーザーをある程度正確に検出できます。

ＷＩＴＣＨ？

少し考えてから、アイデアを実装するための小さなWebサービスを作成することにしました。これは、何らかの理由で類似のものが見つからなかったためです。

これにより、OpenVPN接続の設定が簡単にわかります（もちろん、mssfixをタッチしなかった場合）。OSを特定し、User-AgentのOSと比較して、IPのPTRレコードを取得します。これを一連のルールと比較して、ホームユーザーまたはサーバーユーザー向けに設計されたインターネットチャネルを使用しているかどうかを判断します。

First seen = 2015/07/24 17:19:29 Last update = 2015/07/24 18:39:37 Total flows = 7 Detected OS = Linux 3.11 and newer HTTP software = Firefox 10.x or newer (ID seems legit) MTU = 1409 Network link = OpenVPN UDP bs64 SHA1 Language = Russian Distance = 15 Uptime = 1 days 19 hrs 39 min (modulo 165 days) PTR test = Probably home user Fingerprint and OS match. No proxy detected. OpenVPN detected. Block size is 64 bytes long (probably Blowfish), MAC is SHA1.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、WITCH？は、問題なくTor Browserユーザーを識別します。 すべてのオペレーティングシステムで同じ静的User-Agent（Windowsを使用）を使用し、出口ノードはLinuxおよびFreeBSDで実行されています。





テスト中に、多くの興味深い詳細が明らかになりました。

• Beelineのモバイルインターネットは、Linuxのプロキシを介してすべての接続を渡します。 これは、Beelineを持つ人がiPhoneからWTITCHに移動したときに発見され、OSはLinuxとして定義されていました。 おそらく、彼がHTMLタグを変更し、 mail.ru検索でツールバーを追加し、 サイトのデザインを変更するのは彼を通してだろう。
• モバイルデバイスのMTUは文字通り何でもかまいませんが、通常は0で終わります。例外は1358からのYotaです。それが何に依存しているかは明確ではありません。 異なる電話の同じSIMは異なるMTUを使用します。
• OpenVPNのmssfixを担当するコードは非常に遅いです。 ネットワーク、C、欲求、時間に関する知識がある場合は、最適化できるかどうかを確認してください。

そのようなこと。