新型コロナウイルス禍で企業ネットワークの姿が変わってきています。ネットワーク管理にも変化に対応した手法が求められています。この特集ではネットワークを流れるパケットをキャプチャーして収集し、Pythonとリレーショナルデータベースを用いて精度よく解析するための実践的なテクニックを紹介します。第4回は第3回 https://xtech.nikkei.com/atcl/nxt/column/18/01834/110900003/ で構築した環境を利用して、SaaS（ソフトウエア・アズ・ア・サービス）などで使われるサーバーの実体が置かれている場所を推定する手法を解説します。
2020年の新型コロナ禍初期、米Zoom Video Communications（ズーム・ビデオ・コミュニケーションズ）のビデオ会議サービス「Zoom」を多くの企業で使うようになりました。一方でそのZoomの通信が中国のサーバーを経由しているとして話題になりました。
中国のサーバーを経由しているとの報道後、Zoomはグローバルで通信の経路を調整したと発表しました。アプリケーションの実態としてどこに接続され、データがどの国に保管されているのかといったことは国際社会の動向に関連し、経済安全保障の観点からも神経質にならざるを得ない問題です。物理的なサーバー資産や抱えているデータの管理が各国・地域の現地法の影響を受ける可能性があるためです。
SaaSの導入に当たり、サーバーの設置場所を調査するのは容易ではありませんし、設置場所が変わることも想定しなければなりません。管理するとなれば定期的なチェックも必要です。筆者は「香港かシンガポールにサーバーがある」と説明を受けていたクラウドサービスについて、ある日突然欧州（と思われる場所）にサーバーが移管され、システムのレスポンスに大きな影響が出たトラブルを経験したことがあります。
定常的にパケットをキャプチャーし、各種SaaSのレスポンスや「RTT（ラウンドトリップタイム）」を自動的に収集できれば、異常に気付きやすくなったり、設置されている国をある程度推測したりする手助けになります。
RTTとは
この記事では以降、RTTという用語を用いて「パケット往復」の所要時間を表します。RTTの計測によく用いられるpingコマンドでは単に「時間」として扱われており、この値がRTTになります。例えばノードAから通信が開始され、その応答がノードBから発信されてノードAに到着した時間をRTTと定義します。
このやり取りの際にノードBで何らかの処理をするなどで応答発信の時間が延びてしまうことがあります。そのため、RTTの計測には処理時間が含まれている可能性があるストリーム途中のレスポンスを抽出するのではなく、決まった手続きの時間を計測する方が理にかなっています。
RTT計測時に考慮すべきこと
一般的なpingコマンドによるRTT計測では宛先となるノードと通信できるかどうかの到達性が問題になるケースがあります。pingコマンドが利用しているICMP（Internet Control Message Protocol）の疎通がサーバー側で許可されていない（ICMP Echo Requestの受信が許可されていない）場合に通信できない問題が発生します。
この問題を避けるため、確実に許可されているはずのTCPを使用した「TCPping」という手法も存在します。ただし、このTCPpingはTCPのコネクション生成手続きである「3ウェイハンドシェイク」を完結させない「ハーフスキャン」と呼ぶ実装になっている場合があります。サイバーセキュリティーの世界でいう「ポートスキャン」行為と区別がつきません。そのため利用には注意が必要です。セキュリティー上のログに検出されたり、実行頻度がサーバー側に問題視されたりする可能性があります。
