やろうとしていたこと
客先に納入したシステムを遠隔からメンテナンスするために、ラズパイを踏み台サーバとして使用する予定でした。
ラズパイにインターネット経由で遠隔ログインするために、4GPi（4G/LTE 通信モジュール）と、イプシム の固定グローバルIPのSIMカードを使用しています。
4GPi を使用するとラズパイで簡単に4G/LTE回線を使った通信を行うことができます。
障害内容（ラズパイにssh接続できない）
客先にラズパイ一式を送り、動作確認のためにラズパイの電源を入れてもらいました。自社環境のPCからラズパイへのssh接続を試みたところ、"Connection refused"（接続拒否）になってしまいました。
$ ssh pi@XXX.XXX.XXX.XXX
ssh: connect to host XXX.XXX.XXX.XXX port 22: Connection refused
断っておくと、事前に社内で動作確認した際には問題なくssh接続ができていました。客先に送った途端にssh接続ができなくなったのです。
原因調査
メンテナンス作業は翌日に予定されており、急ぎで対処する必要がありました。
ping疎通確認（L3チェック）
ラズパイのIPアドレスに対して ping を実行したところ、予想に反してpingは通ることがわかりました。
$ ping -c 5 XXX.XXX.XXX.XXX
PING XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX) 56(84) bytes of data.
64 bytes from XXX.XXX.XXX.XXX: icmp_seq=1 ttl=237 time=292ms
64 bytes from XXX.XXX.XXX.XXX: icmp_seq=2 ttl=237 time=75.0ms
64 bytes from XXX.XXX.XXX.XXX: icmp_seq=3 ttl=237 time=64.4ms
64 bytes from XXX.XXX.XXX.XXX: icmp_seq=4 ttl=237 time=63.1ms
64 bytes from XXX.XXX.XXX.XXX: icmp_seq=5 ttl=237 time=61.5ms
--- XXX.XXX.XXX.XXX ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 61.501/111.160/291.778/90.433 ms
もしかするとIPアドレスを間違えているか、もしくはIPアドレスが変わった？可能性があるかもしれないと思いましたが、pingを実行しながらラズパイの電源を落としてみたところ※、ラズパイの電源を落としたタイミングでpingが通らなくなったので、ラズパイに設定されたグローバルIPアドレスは生きていると考えられました。
※このとき客先にはディスプレイしかなかったため、直接ラズパイにログインしてもらって諸々の状況を確認することはできませんでした。
ファイアウォールでsshパケットが拒否されている？
L3（ネットワーク層）の疎通が OK ということは問題が L4（トランスポート層）以上にあると考えられます。すぐに思いつくのは、ファイアウォールでSSHのパケットが拒否されている可能性ですが、ラズパイ自体のファイアウォール設定（ssh許可）は事前に設定しており、それが原因とは考えられませんでした。
ラズパイが原因ではないとすると、途中の通信機器によってsshパケットが拒否されているのでしょうか？
パケットキャプチャで応答パケットを確認
"Connection refused" ということは、タイムアウトではないので、ラズパイかもしくは途中の通信機器の誰かが接続拒否を示すパケットを返してきているはずです。そのパケットの内容をみれば何かわかるかもしれません。
$ sudo tcpdump -i eth0 port 22 -w ssh.cap
パケットキャプチャした結果、PCからラズパイに向けてSYNパケットを送った後、RSTパケットにより切断されていることがわかりました。このRSTパケットを送ったのは誰でしょうか？
ここで注目したのは TTL（Time To Live）の値です。TTLとはIPパケットの寿命を表しており、IPパケットの寿命とは経由するルータの数（＝ホップ数）です。TTLはルータを経由するたびに（ネットワークを経由するたびに）ひとつずつ減算され、TTLが0になるとパケットが破棄されます。
sshのRST応答のTTL値＝237でした。一方で前記のpingコマンドの結果をみると、こちらもEcho ReplyのTTL＝237であることがわかります。このことから、ssh時のRSTパケットとpingのEcho Replyは同じ機器が応答している可能性が高いと考えられます。
pingはラズパイが応答しているはずなので、sshの接続拒否をしているのもラズパイということになります。ということは、sshサーバが動作していないのでしょうか？客先に送った途端sshサーバが動作しなくなった？
ここで行き詰まりましたが、その後、客先でラズパイに直接ログインしてもらって原因がすぐに判明しました。
原因判明
結果を言うと、ラズパイと4GPi（4G/LTE 通信モジュール）をつなぐUSBケーブルを接続していませんでした。つまりラズパイから 4GPi（wwanデバイス）が認識できていませんでした。したがってラズパイにはグローバルIPアドレスも振られていませんでした。この状態では当然インターネット経由で sshサーバにはアクセスできません。
そして、上の原因調査時点で ping に応答していたのは ラズパイではなく 4GPi でした。「ラズパイが ping 応答できている」という最初の思い込みが間違いだったのです（そもそもラズパイのTTLのデフォルト値は64なので、TTL=237の時点で違和感がなくてはいけませんでした）。
4GPiの電源はラズパイのGPIOで制御されているので、USBケーブルとは関係なく4GPiを起動することができます。また今回事前に4GPiのセットアップ（APN設定）を行っていたため、4GPiは電源を入れればLTEのネットワークに接続できる状態だったのです。
ラズパイと4GPiをUSBケーブルで接続するとラズパイにwwanインターフェースが生えて、そこにIPアドレスが設定されます。USBケーブルはラズパイと4GPi間の高速データ通信に使用されます。
結論
今回のように、手元で動作確認したときは特に問題がなかったのに、客先で動かすとうまく動かないという状況は一般的によく起こることだと思いますが、そういうときは一番最初に接続や設定のミスがないか、自社と客先で動作環境の違いがないかを確認・分析して対処すべきであることを反省しました。