network

TL;DR Ubuntuサーバ20.04で、重複しているIPを持つサーバから重複しているかどうかを検知する場合は arping -I eth0 -0 -c 2 (IPアドレス) (eth0は適宜置き換え)を実行し、応答がある(戻り値:0)場合は重複あり、応答がない(戻り値:1)の場合は重複なしと判断します。 経緯 Ubuntu20.04 サーバ上で使用しているIPアドレスが重複しているかどうかを、そのIPアドレスを使用するサーバから検知したいと考えました。 arping, arp-scan等のコマンドを使うと説明するサイトが多数見つかるのですが、ほとんどが重複しているIPを持つ可能性のあるサーバとは別のサーバで実行することが前提のようで、うまくいきませんでした。 自身が同じIPアドレスを持っていると、そのIPアドレスを対象としたARPリクエストを送ってくれないようでTIMEOUTになってしまいます。 そこで、-0(数字のゼロ)オプションをつけると、ARPリクエストを送ってくれるようになりました。ただし、自分自身からは応答が帰ってきませんので、応答がある(戻り値:0)場合は重複あり、応答がない(戻り値:1)場合は重複なしと判断することになります。 このオプションは、ARPリクエスト送信時の送信元IPアドレスを0.0.0.0にするもののようで、これによりARPリクエスト自体が送られない問題を回避できるようです。 参考: Ubuntu20.04にインストールされるThomas Habetsさんのarpingのマニュアル

TL;DR DNSサーバのフォワーダをプロバイダ推奨の設定にしないと思わぬ障害に遭います 経緯 利用者より、ある取引先のWEBサイトがエラーで見られないとの連絡がありました。確認すると、Chrome,Edge,Firefox,IEのいずれもエラー。Chromeの場合はERR_SSL_PROTOCOL_ERR と表示されます。 10日ほど前にUTM(Fortigate)のFWのバージョンアップを行っていたので、まぁこれだろうと思って通信経路から外しても障害が解消しません。 SIMを搭載したiPad, iPhoneでキャリア網経由だと問題がなく、社内ネットワークに問題があることは分かりました。 ルータ直下にPCをつないでも症状は変わらず。ルータか、ONUより上流のキャリア側か、その間のLANケーブルか… WireSharkでパケットキャプチャをしてみましたが、私の技術力では原因を特定できず… ルータではフィルタリングをかけています。切り分けのため、予備機にフィルタリングを一切しない設定を実施。その配下にWindowsをつなぐのは怖いため、Linux(Lubuntu20.04)をセットアップし、IP固定、DNSは8.8.8.8としました。 Lubuntuで予備機に切り替える前に動作確認したところ症状が解消されていることを確認できました!!! そこで、もともと問題が発生してたPC(Windows10)でnslookupをDNSサーバ指定なしで実行した結果と、8.8.8.8を指定した結果が異なっていることが判明… 社内ではActive DirectoryのDNSを利用しています。DNSのキャッシュをクリアしましたが症状変わらず。フォワーダを確認したところ、かなり前にプロバイダから提供されて設定したグローバルアドレスでした。しかも現在はプロバイダを変更しています… 現在のプロバイダではDNSはルータでのPPPoEによる自動取得となっているので、フォワーダとして社内のルータを指定し、キャッシュを削除したところ症状が解消しました。 ちなみに変更前のプロバイダも現在は自動取得を推奨しているので、だいぶ前から設定が正しくなかったことが分りました。 結論として、誤ったDNS情報をもとに異なったサーバを見に行き、そのサーバはおそらく古いサーバでTLSのバージョンが古く冒頭のエラーとなったものと思われます。 サーバとの通信経路上の問題かと思ったら、通信を始める前の社内DNSの問題というオチ。改めてDNSは通信の基盤であり障害時には真っ先に調査・切り分けしないといけないことを実感しました。