特定のポート(サービス)への通信ができない場合¶

[更新：2022年09月14日]

ご利用中のVPSでインストールしたサービス(Webやメール)等が利用できない、その原因がポートへの通信に起因する場合の確認方法を記載します。

該当する症状 ¶

Apache/Nginxをインストールしたがブラウザからのアクセスができない
メールを送信しようとしたが送れない
SSHのポートを変更したが接続できなくなってしまった

Note

本文書の確認は、 Webへのアクセス を元に記載していきます。

その他のサービスに関しては適宜読み替えていただき、ご参照ください。

確認方法 ¶

Note

本文書に記載する内容はあくまでも調査のための一例であり、全ての調査方法を網羅しているものではありません。
基本的に導入のコマンドはRHEL系8以上を想定しています。そのためdnfコマンドがない場合は、yumやaptに読み替えていただきますよう、お願いいたします。
また本文書における実行コマンドは、全てroot権限が必要となります。

0. 事前準備 ¶

確認前の事前準備として、ご利用中VPSに tcpdump をインストールします。

# dnf install tcpdump

このコマンドによって、以下を判断することが目的となります。

通信パケットはクライアント(PC等)からご利用VPSまで到達しているか
パケットのやり取りは正常に行われているか

tcpdumpコマンドは基本的に以下の書式によって実行されます。

# tcpdump <オプション> <条件式>

本文書内で利用しないオプションもありますが、以下によく利用されるオプションを列挙します。

オプション

詳細

-i

パケットをキャプチャーするインターフェースの指定する

-n

送信先/送信元のIPアドレスの名前解決を行わずに出力する

-nn

-nを実施し、さらに送信先/送信元のサービス名変換を行わずに出力する

-w

引数にファイル名を指定し、キャプチャーしたパケットをファイルに保存する

-e

MACアドレスを表示させる

-v

出力される内容をより詳細にする

次に条件式についても以下に列挙します。

Note

条件式は組み合わせることによって複数の指定の仕方が可能ですので、記載はあくまでも一例となります。

条件式	詳細
host	送受信を行っている対象のIPアドレスを指定する(送信元/送信先問わず)
port	パケットの送出/受信ポートを指定する
ether	MACアドレスを指定する
tcp/udp	パケットのプロトコルがTCP/UDPを利用しているものを指定する
icmp	パケットのプロトコルがICMPを利用しているものを指定する
arp	パケットのプロトコルがarpを利用しているものを指定する
src	送信元の対象を指定する
dst	送信先の対象を指定する
and	条件式をand条件で組み合わせて、対象をより絞る時に利用する
or	条件式をor条件で組み合わせて、対象を複数抽出する時に利用する
not	後に記載される条件を否定し、その条件式以外を出力させる

最後にそれぞれのオプション、条件式を組み合わせての実行方法を例示します。様々な組み合わせがありますので、調査に即して適切な組み合わせを検討してください。

# tcpdump -i eth0 -n
※パケットの取得インターフェースをeth0に指定し、送信元/送信先のIPアドレスを名前解決しない。

# tcpdump -i eth0 -w /path/to/file
※eth0に受信したパケットを全てファイルに出力する。出力されたファイルはWireshark等のパケット解析ツールで読み込める。

# tcpdump -i eth0 -n host XXX.XXX.XXX.XXX and port 80
※送信元/送信先の対象IPアドレスを指定し、さらに送信元/送信先を問わず80番ポート(Webサーバ)へアクセスしている通信を抽出する。

# tcpdump -i eth0 -nn not src (host) XXX.XXX.XXX.XXX and dst port 80
※ポートの名前解決を無効化、特定の送信元以外の通信で、かつ宛先ポートが80番の通信を抽出する。()内の記述は省略可能。

警告

条件式の評価は先に記述されたものから順次判定されるため、記述に矛盾がある場合はエラーが表示されます。
また条件式を絞り込みすぎると出力される内容が限定的になるため、本来取得したかった通信上のエラーをキャプチャーできないという状況が発生する可能性もあります。
条件の指定は調査したい内容に合わせて、大きな部分から絞り込んでいくように指定してください。

tcpdumpコマンドにて取得したファイルは、 Wireshark に代表される外部ツールを利用して調査をすることが可能です。
Wiresharkを利用したパケットの確認方法は以下に記事がございますので、ご参照いただければ幸いです。
Wiresharkを使った通信監視（前編）

1. tcpdumpを実行してもパケットが受信できていない場合 ¶

下記に条件と確認方法を記載します。

ご利用VPSの電源は起動していて、Webサービスも起動状態になっている
クライアントのWebブラウザからご利用VPSへアクセスした場合、ブラウザに「タイムアウト」の表示がされる
ご利用VPSで下記のコマンドを実行し、ブラウザからご利用VPSへアクセスしても全く出力が無い

# tcpdump -i eth0 -n port 80
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

※終了する場合はCtrl+Cを押下してください。

この条件に該当する場合、ご利用端末-ご利用VPS間の経路で何らかの通信エラーが発生していることが予想されます。

以下に予想される原因と対処方法を記載します。

1-1. パケットフィルターの設定不備 ¶

さくらのVPSでは一つのホストサーバーに対して複数のお客様VPSを収容しており、インターネットからお客様VPSまでのネットワークは以下のイメージとなります。

このイメージのように、弊社ネットワーク環境へ到達した通信は、ホストサーバーのNICを通ってスイッチングされ、ご利用VPSの仮想NICへ到達します。

弊社で提供しているパケットフィルター機能は、下記の図のようにパケットがVPSの仮想NICに到達する前でフィルタを行っているため、パケットフィルターが有効化されている場合は、VPSの仮想NICまで通信が到達しません。

そのためご利用VPS上でtcpdumpを行った際に、パケットの情報が出力されない状態になっている可能性がございます。

この場合はお手数ですが、パケットフィルターをご確認いただき、コントロールパネルからパケットフィルターの設定を適切に修正いただきますよう、お願いいたします。

1-2. HSTSによるリダイレクト ¶

解説の前提としてWebサービスでの確認となりますが、接続クライアント(PC)の各ブラウザにはHSTS(HTTP Strict Transport Security)という機能があります。
この機能はブラウザ側で提供されるもので、80番ポートを利用したWebサーバーへのアクセスが自動的にHTTPS(443番ポート)へ変換されるものになります。
HSTSに起因する問題であるかどうか、以下のコマンドで確認することは可能です。
※80番ポートへのパケットの着信が見えることもございます。

# tcpdump -i eth0 -n port 443
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:11:43.603016 IP XXX.XXX.XXX.XXX.13943 > YYY.YYY.YYY.YYY.https: Flags [S], seq 2952803574, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 190463372 ecr 0], length 0
16:11:43.603067 IP YYY.YYY.YYY.YYY.https > XXX.XXX.XXX.XXX.13943: Flags [S.], seq 51034214, ack 2952803575, win 28960, options [mss 1460,sackOK,TS val 2693706482 ecr 190463372,nop,wscale 7], length 0
16:11:43.623754 IP XXX.XXX.XXX.XXX.13943 > YYY.YYY.YYY.YYY.https: Flags [.], ack 1, win 1027, options [nop,nop,TS val 190463392 ecr 2693706482], length 0
<中略>
※パケットが到達した場合はこのように出力されます。

これでパケットの到達が確認できる場合は、以下のように対応することで修正することが可能です。

ご利用VPSにSSLを導入してもらい、HTTPS化してから確認する
Test-NetConnection コマンドを利用して確認する(接続クライアントのOSでWindowsをご利用の場合)

ご利用VPSにSSLを導入していただく場合、ドメインの設定やご用意等が必要となりますが、弊社にてご用意しておりますスタートアップスクリプトを使用していただくことで、簡単に設定を行うことが可能です。

スタートアップスクリプトのご利用方法についてはスタートアップスクリプト及び Let's Encrypt をご参照ください。

警告

スタートアップスクリプトを実行する場合は、OSの再インストールが必要となります。既存の環境は全て消去されますので、必要な情報の保管をお願いいたします。

上記に記載したように、特定のポートに対しての到達性を確認する場合に最も準備が簡単なものが、 Test-NetConnection コマンドになります。

以下にコマンド実行の簡単な手順を記載します。

Test-NetConnectionの実行方法¶

キーボードの Windows + R キーを押下して、「ファイル名を指定して実行」を起動させる
検索窓に「powershell」と入力する

以下のコマンドを実行する

> Test-NetConnection <対象ホスト名/IPアドレス> -Port <対象ポート>

ComputerName     : <対象ホスト名/IPアドレス>
RemoteAddress    : <対象IPアドレス>
RemotePort       : <対象ポート>
InterfaceAlias   : イーサネット
SourceAddress    : <検索端末に割り当てられているIPアドレス>
TcpTestSucceeded : True

TcpTestSucceeded 項目がTrueになっていることを確認する

上記のTcpTestSucceededがFalseになっている場合は、ご利用VPSへのネットワーク上の到達性が失われていますので、パケットフィルターの状況をご確認ください。

Trueになっている場合は、クライアントからご利用VPSの対象ポートへアクセスし、問題なく到達できていることを表します。

2. tcpdumpを実行してパケットが受信できている場合 ¶

上記で説明した内容と異なり、対象のポートでtcpdumpを実行した際に受信がてきていると仮定します。

ただし、本来であればクライアント→サーバーへアクセスがされれば、サーバー→クライアントへレスポンスがあるものの、レスポンスがない場合を想定します。

# tcpdump -i eth0 -nn port 80
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:11:43.603016 IP <接続元IPアドレス>.13943 > <ご利用VPSIPアドレス>.80: Flags [S], seq 3473259437, win 64240, options [mss 1414,nop,wscale 8,nop,nop,sackOK], length 0
16:11:43.623754 IP <接続元IPアドレス>.13943 > <ご利用VPSIPアドレス>.80: Flags [S], seq 3473259437, win 64240, options [mss 1414,nop,wscale 8,nop,nop,sackOK], length 0
<中略>

この場合は、外部からご利用VPSへのアクセスは到達しているものの、VPS内部の状態に起因してレスポンスがない状態を表しています。

想定される原因について下記に記載いたしますので、それぞれご確認ください。

2-1. iptables/Firewalldの設定不備 ¶

iptablesがご利用VPSの内部に設定されているものの、対象ポートやサービスへの許可をする設定が入っていない場合、ご利用VPSからのレスポンスが返らないまま通信が終了します。
その場合、PCのブラウザではタイムアウトなどの出力がされていると考えられます。
正常な通信とiptablesが通信を阻害している場合のイメージ図が下記です。

正常な場合¶

ご利用VPSの仮想NICに到達したトラフィックは宛先ポートに対して通信を実施し、そのポートをリッスンしているサービスが応答を返す、という流れになっています。

iptablesが通信を阻害している場合¶

iptablesで各サービスへの通信が許可されていない場合、各サービスへの通信はiptablesで遮断されてしまいます。

tcpdumpは仮想NICに対して実施しているためパケットの受信が観測できますが、各種ログを出力しているサービスはパケットの受信を認識できないため、ログの出力がされません。

Note

ご利用のインターネット回線によっては、25番ポートへの直接通信ができないように OP25B 設定がされていることがあります。

接続の確認ができない場合はOP25Bについてもご確認をお願いいたします。

また以前許可したiptablesを設定ファイルへ反映しておらず、再起動等により許可していない状態へ巻き戻ってしまうパターンも散見されます。

iptables/Firewalldの確認方法を以下へ記載いたしますので、それぞれ下記のリンクをご参照ください。

2-2. サービスの起動不具合 ¶

ご利用VPSからのレスポンスがない原因がiptablesでない場合、実行されているサービスに関して、下記をご確認ください。

A. サービスの自動起動が設定されていなかった場合¶

サービスの自動起動設定がされていない状態で、再起動等が発生した場合に起こります。

以下確認と対応方法について記載します。

# systemctl status httpd (指定するサービス名は確認対象に変更してください)
# systemctl start httpd (上記で停止していた場合起動)
# systemctl is-enabled httpd
# systemctl enable httpd
※Webサービスの場合、関連するサービス(SQLやphp-fpm等)の起動状態も確認が必要です。

B. サービスのポート設定が変更されていた場合¶

ご利用VPS上で対象サービスのリッスンポートが変更されていたものの、サービスが再起動されず旧ポートで動いていたが、再起動等でそれが反映された場合に起こります。

各サービスの設定ファイルの修正が必要になりますが、現在リッスンしているポートの確認は以下で行います。

# systemctl status httpd (サービスが起動していることを確認)
# ss -tulnp state listening (現在リッスンしているポートの一覧とサービス名を表示)

C. サービスの起動に失敗している場合¶

サービスを起動したものの、設定不備やデータの不具合等により起動に失敗する可能性があります。

以下のようにご確認いただき、問題箇所の特定と修正を行ってください。

# systemctl status httpd (サービスがinactiveもしくはdeadになっていることを確認)
# journalctl -xe --no-pager | less (systemdの起動ログの確認)
# less /var/log/messages (システムログを確認)