したがって、プロバイダーはTTK Ulyanovsk（以前のDARS Telecom）であり、セッション中は外部IPとのPPPoE接続です。 ロックは、DPIでブロックされたサブネット/ホストをラップすることにより行われます。 DNSは代替ではありません。
% traceroute ya.ru traceroute to ya.ru (87.250.250.242), 64 hops max, 40 byte packets 1 bras.ulttk.ru (79.132.125.1) 0.899 ms 0.787 ms 0.817 ms 2 ulk06.ulk26.transtelecom.net (217.150.41.98) 1.552 ms 1.536 ms 1.536 ms 3 * * * 4 Yandex-gw.transtelecom.net (188.43.3.213) 21.828 ms 15.955 ms 17.003 ms % traceroute rutracker.org traceroute to rutracker.org (195.82.146.214), 64 hops max, 40 byte packets 1 bras.ulttk.ru (79.132.125.1) 1.778 ms 0.843 ms 0.751 ms 2 ulk06.ulk26.transtelecom.net (217.150.41.98) 1.656 ms 1.698 ms 1.439 ms 3 * * * 4 188.43.0.18 (188.43.0.18) 16.589 ms BlackList-gw.transtelecom.net (188.43.30.130) 16.435 ms BL-gw.transtelecom.net (188.43.31.170) 16.377 ms 5 Filter-gw.transtelecom.net (188.43.30.33) 17.006 ms 16.859 ms 17.080 ms % traceroute kinozal.tv traceroute: Warning: kinozal.tv has multiple addresses; using 104.24.107.53 traceroute to kinozal.tv (104.24.107.53), 64 hops max, 40 byte packets 1 bras.ulttk.ru (79.132.125.1) 0.810 ms 0.809 ms 0.739 ms 2 ulk06.ulk26.transtelecom.net (217.150.41.98) 1.653 ms 1.802 ms 1.736 ms 3 * * * 4 Filter-gw.transtelecom.net (188.43.30.34) 16.451 ms BL-gw.transtelecom.net (188.43.31.170) 16.405 ms 16.418 ms 5 Filter-gw.transtelecom.net (188.43.30.33) 99.751 ms 78.541 ms 17.021 ms 6 Cloudflare-msk-gw.transtelecom.net (188.43.3.65) 212.754 ms 107.803 ms 117.062 ms 7 104.24.107.53 (104.24.107.53) 28.015 ms 17.216 ms 17.357 ms
さらに、一部のサイトはIPによって単純かつ控えめにブロックされています（少なくともRSTを送信してくれてありがとう）。 たとえば、RutrekerのBTアナウンスメント：
02:48:58.530078 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) ip109.176.ulttk.ru.22099 > bt.rutracker.org.http: Flags [S], cksum 0xd538 (correct), seq 3425095266, win 65535, options [mss 1452,nop,wscale 6,sackOK,TS val 1991139339 ecr 0], length 0 02:48:58.546482 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto TCP (6), length 40) bt.rutracker.org.http > ip109.176.ulttk.ru.22099: Flags [R.], cksum 0x13b9 (correct), seq 0, ack 3425095267, win 0, length 0
ブロッキングページを表示する必要がある同じサイトでは、パッシブDPIが機能します。 Rutrekerの例を考えてみましょう。
02:27:28.605860 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) ip109.176.ulttk.ru.27338 > rutracker.org.http: Flags [S], cksum 0xeafc (correct), seq 3703194126, win 65535, options [mss 1452,nop,wscale 6,sackOK,TS val 1989849414 ecr 0], length 0 02:27:28.646812 IP (tos 0x0, ttl 58, id 0, offset 0, flags [DF], proto TCP (6), length 48) rutracker.org.http > ip109.176.ulttk.ru.27338: Flags [S.], cksum 0x81d2 (correct), seq 2683499593, ack 3703194127, win 14600, options [mss 1400,nop,wscale 8], length 0 02:27:28.646913 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) ip109.176.ulttk.ru.27338 > rutracker.org.http: Flags [.], cksum 0xe266 (correct), seq 1, ack 1, win 1028, length 0 02:27:28.647281 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 117) ip109.176.ulttk.ru.27338 > rutracker.org.http: Flags [P.], cksum 0xb1d5 (correct), seq 1:78, ack 1, win 1028, length 77: HTTP, length: 77 GET / HTTP/1.1 Host: rutracker.org User-Agent: curl/7.56.0 Accept: */* 02:27:28.663665 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto TCP (6), length 286) rutracker.org.http > ip109.176.ulttk.ru.27338: Flags [FP.], cksum 0xf88c (correct), seq 1:247, ack 78, win 0, length 246: HTTP, length: 246 HTTP/1.1 301 Moved Permanently 02:27:28.663724 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) ip109.176.ulttk.ru.27338 > rutracker.org.http: Flags [.], cksum 0xe126 (correct), seq 78, ack 248, win 1024, length 0 02:27:28.664047 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) ip109.176.ulttk.ru.27338 > rutracker.org.http: Flags [F.], cksum 0xe121 (correct), seq 78, ack 248, win 1028, length 0 02:27:28.695429 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) ip109.176.ulttk.ru.42348 > dib-filtr-gw.transtelecom.net.http: Flags [S], cksum 0x0556 (correct), seq 2835326510, win 65535, options [mss 1452,nop,wscale 6,sackOK,TS val 1989849504 ecr 0], length 0
この結論をさらに詳しく見てみましょう。 605860から646913の瞬間から、クライアントは「実際の」Rutrekerとのトリプルハンドシェイクを実行します。 647281では、クライアントは77バイトの長さでHTTPリクエストをRutrekerに送信しますが、通常のACKの代わりに、246バイトのHTTPリダイレクトで「偽の」Rutreker FPAから受信します。 さらに、このTCP接続のフレームワーク内で、正しいACK 78がありますが、SEQシーケンス番号は左側にあることに注意してください。 次に、クライアントは接続を閉じて、彼らが言ったところに行きます。 RutrekerからのACKおよびHTTP応答は届きません。
原則として、プロバイダーがFPAフラグ付きのこの奇妙なTCPを必要としていた理由は明らかです。FINはクライアント側から接続を開始し、PUSHはこのセグメントをクライアントのTCPキューにプッシュし、正しいACKはすべてを美しく見せるために、この「偽の」TCPセグメントクライアントのTCP \ IPスタックによってドロップされました。 しかし、このFPAも彼を殺しました。
そのため、主な戦略は、FPAフラグが設定されたTCPセグメントを、ブロックされたリソースのアドレスから来ているかのようにドロップすることです。
古いAtomのFreeBSDは私のホームネットワークのルーターとして機能し、pfはパケットフィルターとして機能します。 主な問題は、pfがステートフルファイアウォールであるということでした。 最初に許可された発信SYN、状態レコード、およびその後のすべての要求がRutrekerアドレスのファイアウォールの状態テーブルに入力された後、最も重要なことに、このTCP接続内の回答はファイアウォールルールを通過しなくなり、すべて許可されます。
このような動作により、ファイアウォールのパフォーマンスが大幅に向上し、ルールの数が減りますが、この場合、効果的なフィルタリングができなくなります。 したがって、ブロックされたリソースへのすべての要求/応答はステートレスモードで生成されます。 状態を保存せずに。 pfでは、ルールは次のとおりです。
WAN="ng0" LAN="re0" Blocked="{ .IP1, .IP2, .IP3, .. }" ... # -UNBLOCK- # for LAN hosts pass in quick on $LAN proto tcp from $LAN:network to $Blocked no state block drop out quick on $LAN proto tcp from $Blocked to $LAN:network flags FPA/FPA pass out quick on $LAN proto tcp from $Blocked to $LAN:network no state # -UNBLOCK- # for me (router itself, for testing) pass out quick on $WAN proto tcp from ($WAN) to $Blocked no state block drop in quick on $WAN proto tcp from $Blocked to ($WAN) flags FPA/FPA pass in quick on $WAN proto tcp from $Blocked to ($WAN) no state ...
許可ルールのno stateディレクティブは状態の保存を禁止し、UNBLOCKブロックの最初のルールはブロックされたリソースへの発信呼び出しを許可し、2番目のルールはFPAフラグが設定された着信メッセージを「偽」ブロックし、3番目のルールは他のすべての着信メッセージを許可します。 すべてのルールのクイックディレクティブは、このルールに一致する場合、ファイアウォールが後続のすべてのフィルタリングルールを表示しないようにします。 結果（トリプルハンドシェイクが失敗しました）：
01:48:10.221343 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 117) ip109.176.ulttk.ru.42714 > rutracker.org.http: Flags [P.], cksum 0xccb6 (correct), seq 1:78, ack 1, win 1028, length 77: HTTP, length: 77 GET / HTTP/1.1 Host: rutracker.org User-Agent: curl/7.56.0 Accept: */* 01:48:10.237686 IP (tos 0x0, ttl 61, id 0, offset 0, flags [DF], proto TCP (6), length 286) rutracker.org.http > ip109.176.ulttk.ru.42714: Flags [FP.], cksum 0x136e (correct), seq 1:247, ack 78, win 0, length 246: HTTP, length: 246 HTTP/1.1 301 Moved Permanently 01:48:10.563977 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 117) ip109.176.ulttk.ru.42714 > rutracker.org.http: Flags [P.], cksum 0xccb6 (correct), seq 1:78, ack 1, win 1028, length 77: HTTP, length: 77 GET / HTTP/1.1 Host: rutracker.org User-Agent: curl/7.56.0 Accept: */* 01:48:10.604853 IP (tos 0x0, ttl 58, id 42669, offset 0, flags [DF], proto TCP (6), length 40) rutracker.org.http > ip109.176.ulttk.ru.42714: Flags [.], cksum 0x00c5 (correct), seq 1, ack 78, win 58, length 0 01:48:10.605043 IP (tos 0x0, ttl 58, id 42670, offset 0, flags [DF], proto TCP (6), length 422) rutracker.org.http > ip109.176.ulttk.ru.42714: Flags [P.], cksum 0x9bc5 (correct), seq 1:383, ack 78, win 58, length 382: HTTP, length: 382 HTTP/1.1 301 Moved Permanently Server: nginx Date: Thu, 26 Oct 2017 21:48:10 GMT Content-Type: text/html Content-Length: 178 Location: http://rutracker.org/forum/index.php Connection: keep-alive
221343-RutrekerへのHTTPリクエスト
237686-FPAフラグを使用したプロバイダーDPIからの応答（ルーターの外部インターフェイスからダンプするため、ここで表示されます。クライアントはそれを受信しません）
563977-クライアントは応答を待たず、要求を繰り返します
604853-実際のRutrekerはACKを送信します
605043-実際のRootrackerはHTTP応答を送信します
PS同じことが現代のファイアウォールでもできます。pfは私が使っているからです。 注意深い読者は、プロバイダーのDPIによるIPスプーフィングがIP TTLによって基本的に検出されることにも気付く可能性があります（58対61）。 ただし、pfはIPパケットのすべてのフィールドをフィルタリングすることはできず、メインフィールドのみをフィルタリングできます。 他のファイアウォールを使用する場合、IP TTLの不一致は、TCP FPAとともに「偽の」パケットの追加記号として使用できます。
それはすべての人々です！