ConoHa VPS のプライベートネットワーク設定

手順は以下ページにある。

https://support.conoha.jp/v/privatenetwork/

振り当てられたIPv4アドレスを、自分で設定する必要がある。

CentOS8では、コンソールで設定する場合は、nmcliコマンドを使うのが推奨されているらしい。

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/getting-started-with-system-administration_configuring-basic-system-settings#configuring-a-static-ethernet-connection-using-nmcli_configuring-and-managing-network-access

マニュアルに従い、IPv4アドレスを以下のように設定した。

1)デバイスの確認

nmcli device status

デバイスeth1があるが、まだコネクションが定義されていない状態。

2)コネクションの設定

コネクション名もeth1として、アドレスは10.10.10.3の場合、以下のように設定した。

nmcli connection add con-name eth1 ifname eth1 type ethernet
nmcli connection modify eth1 ipv4.address 10.10.10.3/24
nmcli connection modify eth1 ipv4.method manual
nmcli connection modify eth1 connection.autoconnect yes

3)コネクションのDown/Up

nmcli connection down eth1
nmcli connection up eth1

デバイス状態にて、eth1もconnectedとなったことが確認できた。

4)セキュリティー設定

デフォルトではpublicの設定が適用されるが、プライベート用の設定を適用する。

Apache2.4とPHP7.4の連携

動作中のシステムを、そろそろ各種バージョンアップした新サーバーに移す作業に入ったが、新サーバーで、ApacheからPHPが動作しなかった。

新サーバーのバージョン

CentOS8.2
Apache2.4.37
PHP7.4.10

原因

以前のApacheのデフォルトが 、MPM prefork だったのが、今回は MPM event になっていた。

(確認)

/etc/httpd/conf.modules.d/00-mpm.confの中を見ると、ロードするモジュールがMPM eventのモジュールに変わってる。

対応

以前のpreforkにするということも考えられるが、MPM eventで突き進むことにした。

連携するために追加でやったことは、以下。

1.php-fpmの有効化

php-fpmをサービス起動するように設定

systemctl enable php74-php-fpm
systemctl start php74-php-fpm

2.mod_proxy_fcgiを有効化

今までは、/etc/httpd/conf.modules.d/00-proxy.confは、すべてコメントアウトしていたが、以下を有効にする。

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so

CertbotによるSSL証明書の設定

CentOS 8.2 にLet’s encrypt でSSL証明書を設定した時のメモ。

検索すると、古いやり方が出てくる。最新のやり方は、Certbotの本家サイトに行くのがいい。

https://certbot.eff.org/lets-encrypt/centosrhel8-apache

OSとWebサーバーを選んで、後は指示通りにやるだけ。

一応、CentOS 8.2 で、Apache 2.4 でやった時の手順は以下(2020年9月3日時点)。

1.SSLサーバーの設定

mod_sslは既に入れてあり、SSLは有効化されている。

ただし、SSL証明書を取得したいドメインについては、バーチャルホストとして定義することが必要。

デフォルトの/etc/httpd/conf/httpd.confではなく、/etc/httpd/conf.d以下に、バーチャルホストを定義する。ここに定義した、XXXX.com.confに対して、後の手順4で、Certbotが、XXXX.com-le-ssl.confを作成して、XXXX.com.confについても、httpsリダイレクトに修正してくれる。

2.EPELライブラリの有効化

https://fedoraproject.org/wiki/EPEL#Quickstart

これも既にやってあったけど、一応、以下をやる。

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

後、一応、こちらも入れておいた方がいいい。

sudo dnf config-manager --set-enabled PowerTools

3.Certbotのインストール

sudo dnf install certbot python3-certbot-apache

4.証明書のインストール

HTTP用にバーチャルホストが定義してあれば、自動で証明書を取得して、定義ファイルも作ってくれる。

sudo certbot --apache

SSL化したいバーチャルホストを選択すれば、後は自動でやってくれる。ドメイン定義がちゃんとあっていることが前提なので、新サーバーに移行する場合の、新サーバー側で事前のSSL証明書取得についてはできない。

5.自動更新の設定

crontabに直接、定期的に更新するのを設定する。

echo "0 0,12 * * * root python3 -c 'import random; import time; time.sleep(random.random() * 3600)' && certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

6.確認

https://www.ssllabs.com/ssltest/

yum update失敗で、再起動できず

ConoHa VPSのCentOS7.6サーバーで、yumアップデートを掛けたが、その後サーバーが無反応となってしまった。管理パネルから再起動かけたところ、kernel panicで起動できなくなった。VPSのため、レスキューモードでどう起動するかわからず、探したら以下ページを発見した。

https://qiita.com/kiyocy24/items/5897d58bdd04f2e2a65c

ただし、上記ページでは再起動となっているが、再起動の場合はタイミングが取りづらく何回も失敗した。以下の手順が良いと思う。

  1. コントロールパネルから一旦、強制終了する
  2. コントルールパネルから、起動する
  3. コントロールパネルの「コンソール」ボタンが有効化されたら、すかさず押す
  4. コンソール画面で、キー入力

上記手順で、古いカーネルなり、レスキューモードなりを選んで起動して、復旧作業ができるようになった。

NATトラバーサル機能の無効化

クラウドにSoftEtherVPNサーバーを設置して、ファイアウオールでListnerポートを開ける前にクライアントから接続できないことを確認しようとしたら、あっさり接続できてしまった。デフォルトでは、NATトラバーサル機能が有効になっているため、管理ポートへの接続できない場合には、NATトラバーサル機能で接続してしまう。

adminip.txtのIP制限だけでいいという考えもあるが、ファイアウオールによる接続制限も有効にしたいので、サーバー側のNATトラバーサル機能を無効にする。

(繋がった時の状況)

状態としては、以下。ファイアウォールはL2Tp/IPSec用の設定となっている。

  • サーバーはデフォルトで NATトラバーサル機能が有効
  • ファイアウオールで、Listner ポートは開放していない
  • サーバーのFirewallDでは、ssh,dhcpv6-client,ipsecが許可
  • ニフクラのファイアウォールではssh,udp500,4500を許可※
  • OUT側の制限は共になし

※ニフクラでは、自分で設定したもの以外にデフォルトルールが設定されている

https://cloud.nifty.com/spec/fw/default.htm

SoftEther VPNサーバー管理マネージャー で、接続先ホスト名「サーバーのホスト名」、ポート「Listnerのポート」を指定して接続すると繋がってしまう。NATトラバーサル機能で繋がっている。TCPコネクションを見ると、Listnerポートでは接続しておらず、プロセス内での接続が発生してるだけ。

# ss -np | grep vpnserver
tcp ESTAB 0 0 127.0.0.1:40000 127.0.0.1:45962 users:(("vpnserver",pid=3282,fd=81))
tcp ESTAB 0 0 127.0.0.1:45962 127.0.0.1:40000 users:(("vpnserver",pid=3282,fd=80))

接続先ホスト名「サーバーのホスト名/tcp」としてtcp接続に限定すると、期待通り接続に失敗する。

SoftEther VPN サーバー管理マネージャ

(NATトラバーサル機能について)

https://ja.softether.org/4-docs/2-howto/6.VPN_Server_Behind_NAT_or_Firewall/1.Dynamic_DNS_and_NAT_Traversal#NAT_.E3.83.88.E3.83.A9.E3.83.90.E3.83.BC.E3.82.B5.E3.83.AB.E6.A9.9F.E8.83.BD

ファイアウオールがあっても穴を作って通しちゃうという素晴らしい(というか恐ろしい)機能なので、扱いが要注意。開発者さんの以下ブログを参照。

http://d.hatena.ne.jp/softether/20121128#p2

http://d.hatena.ne.jp/softether/20121128#p7

「日本国内の 約 95.7% のファイアウォール・NAT を「外から内に」通過することができます。」とあるのが非常に興味深い。この数値はどう測ったのだろうか。

クライアントではTCP接続できないと、「/tcp」の指定が無ければNATトラバーサルで接続する仕様になっているらしい。

https://ja.softether.org/4-docs/3-kb/VPNFAQ011

(NATトラバーサルの無効化方法)

管理ポートの接続は確実に制限したいのでサーバーのNATトラバーサル機能を無効にする。サーバー停止した状態で、コンフィグファイルを編集することで、サーバー側のNATトラバーサル機能を無効にできる。

cd /usr/local/vpnserver
cp -p vpn_server.config vpn_server.config.org
vi vpn_server.config
-------------------------------
:
declare ServerConfiguration
{
:
bool DisableNatTraversal true
:
-------------------------------

再起動すると、管理ListnerのTCPポートを閉じた状態では、クライアントから接続できないことが確認できた。