ConoHa VPS移設記 ② IPv4/IPv6追加、netplan、ufw

MIGRATION ROADMAP — 全17工程

① SSH、ユーザー追加
② IPv4/IPv6追加、netplan、ufw
③ Apache2
④ Let's Encrypt
⑤ PHP
⑥ MariaDB
⑦ WordPress
⑧ Dovecot、Postfix
⑨ Vsftpd
⑩ Python
⑪ llama.cpp、ChromaDB
⑫ Anaconda、Keras、TensorFlow
⑬ Node.js
⑭ MongoDB
⑮ Mosquitto
⑯ RabbitMQ
⑰ Supervisor

01追加IPv4は「上限緩和の審査」が必要だった

ConoHaのIPv4アドレスはオプションで追加できるが、当初4個を申請したところ、払い出し上限緩和のための審査が必要というアナウンスが入った。審査待ちの間に代替案を検討し、最終的に4個の申請は通ったが、取得したのは1個。この1個をどう活かすかが今回のもう一つの論点になった。

021IPで複数サイトを運用する設計判断

サイトごとにIPを分ける旧サーバーの構成は、SSL証明書ごとに専用IPが必要だった時代（SNI普及以前、おおよそ2013年より前）のなごりで、今のブラウザ・クライアントはほぼ例外なくSNI（Server Name Indication）に対応している。そのためApache2側で<VirtualHost *:443>を名前ベースでサイト数分定義すれば、 1つのIPv4上に複数サイトを問題なく同居させられる。

メールについては旧サーバーで既に1IPマルチドメイン運用の実績があったため、今回もそのパターンを踏襲。結果として、

標準IPv4（160.251.175.xx）… メール・管理系
追加IPv4（160.251.145.xx）… ウェブ（5サイトすべてSNIで同居）

という役割分担にし、審査が通って追加IPv4が確保できた後も、当初の1IP前提の設計をそのまま活かす形にした。

メールのPTR/SPF/DKIMについて 1IPに複数ドメインを乗せる場合、PTR（逆引き）レコードは1個しか設定できない。ただし各ドメインのSPFレコードで送信元IPを許可し、ドメインごとにDKIMを設定、HELO/EHLO名を代表ホスト名に統一しておけば実務上は問題ない。多くの共用サーバーが実際にこの構成。

03ConoHaコントロールパネルでの割当

追加IPv4の申請自体はiPad miniのTermiusとは無関係にConoHa側の審査を経るが、 取得した追加IPv4を新サーバーへ割り当てる操作は、PCブラウザでコントロールパネルを開かないと機能しなかった。さらに、割り当てにはサーバーのシャットダウンが必要だった。作業前提として、この工程だけはiPad単体では完結しないことを踏まえてスケジュールする必要がある。

区分	値
標準IPv4	160.251.175.xx / 255.255.254.0（/23）
標準IPv4ゲートウェイ	160.251.xxx.x
標準IPv6	2400:8500:2002:3164:160:251:175:xx 他16個
標準IPv6ゲートウェイ	2400:8500:2002:xxxx::x
追加IPv4	160.251.145.xx / 23
追加IPv4ゲートウェイ	160.251.xxx.x

04新形式のnetplan：50-cloud-init.yaml

旧サーバーの設定ファイルは10-gmovps.yamlという名前で、dhcp4: trueやgateway6:キーを使う書式だった。新サーバーではcloud-initが初回起動時に50-cloud-init.yamlを自動生成しており、書式そのものが変わっている。

IPv4もDHCPではなく静的アドレス＋明示的なroutes指定
gateway6:キーは廃止され、routes:内のto: "::/0"で表現
match: macaddress + set-nameでインターフェース名をMACアドレスに紐付けて固定

2021年以前の設定を旧サーバーからそのまま移植せず、新しい書式に合わせて書き直す方針にした。

05eth1のMACアドレスは ip a で確認する

eth0はcloud-initが検出済みだが、追加インターフェース（eth1）はサーバー起動後にip aで確認するまでMACアドレスが分からない。

$ ip a 2: eth0: ... link/ether fa:16:3e:xx:xx:xx ... inet 160.251.175.xx/23 ... 3: eth1: ... link/ether fa:16:3e:xx:xx:xx ... inet6 fe80::f816:3eff:feab:xxxx/64 scope link # eth1にはリンクローカルIPv6のみ。IPv4はまだ未設定の状態

06完成版netplan

eth0にIPv6を17個すべて追加し、eth1に追加IPv4とポリシールーティングを設定する。追加IPv4は同一データセンター内で主IPと隣接する構成のため、送信元アドレスに応じて専用ルーティングテーブル（table 201）を通す設定を入れないと、戻りパケットが正しく追加IPv4経由で返らない。

/etc/netplan/50-cloud-init.yaml

network: version: 2 ethernets: eth0: match: macaddress: "fa:16:3e:xx:xx:xx" addresses: - "160.251.175.xx/23" - "2400:8500:2002:3164:160:251:175:xx/64" - "2400:8500:2002:3164:a160:251:175:xxx/64" （中略、16個分のIPv6を列挙） nameservers: addresses: - xxx.xx.10.8 - xxx.xx.10.9 - 2400:8500:7703:502:xxx:xx:10:8 - 2400:8500:7703:502:xxx:xx:10:9 accept-ra: false set-name: "eth0" routes: - to: "0.0.0.0/0" via: "160.251.xxx.x" - to: "::/0" via: "2400:8500:2002:xxxx::x" eth1: match: macaddress: "fa:16:3e:xx:xx:xx" addresses: - "160.251.145.xx/23" set-name: "eth1" routes: - to: "0.0.0.0/0" via: "160.251.xxx.x" metric: 100 table: 201 routing-policy: - from: "160.251.xxx.x/23" table: 201

複数ファイルに分けなかった理由 netplanは複数ファイルをファイル名順にマージするが、addressesのようなリスト項目は同一デバイスに対して後勝ちで丸ごと置き換わる。ファイルをまたいで整合性を追うより、既存の50-cloud-init.yaml1本に完成形をまとめたほうがリモート作業では事故が少ない。

07cloud-initによる上書き対策

ファイル名が50-cloud-init.yamlのままだと、将来の再起動時にcloud-initがネットワーク情報を再検出し、手動編集を上書きする可能性がある。今のうちに無効化しておく。

/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

network: {config: disabled}

08反映と動作確認

リモートSSH経由の作業なのでapplyではなくtryを使い、疎通が切れないことを確認してから確定する。

$ sudo netplan generate $ sudo netplan try $ ip route show table 201 $ curl -4 --interface 160.251.145.xx https://ifconfig.me 160.251.145.xx

確認完了 curl --interfaceで追加IPv4（160.251.145.xx）が送信元として正しく返ってきた。ポリシールーティングが機能している証拠。

見落としがちな点 ConoHaのセキュリティグループは、標準IPに設定したIPv4v6-SSHのようなルールが追加IPv4（eth1）へ自動的には適用されない。 ③でApache2のポートを開ける前に、追加IPv4側にも必要なセキュリティグループが紐付いているか確認しておく。

09ufw

ufwはOS内側のファイアウォールで、ConoHaのセキュリティグループ（クラウド側）とは独立している。両方が「通す」設定になっていないと通信は通らない。

$ sudo ufw status verbose Status: active Logging: on (low) Default: reject (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22/tcp (OpenSSH) ALLOW IN Anywhere 22/tcp (OpenSSH (v6)) ALLOW IN Anywhere (v6)

確認したところ、このイメージではufwが最初から有効化済みで、OpenSSHもすでに許可されていた。 2021年以前の記憶では「ufwはデフォルト無効、手動でallow・enableする」という前提だったが、新しいConoHaのUbuntu 26.04イメージではSSHだけを許可した状態で最初からactiveになっている。表示がdenyではなくrejectになっているのも差分で、動作としては拒否時に応答を返すか黙って破棄するかの違いで、実害はない。

③以降、各ソフトを導入するタイミングで必要なポートを都度追加していく想定。

手順	追加するルール
③Apache2	`80/tcp`, `443/tcp`（Apache Fullプロファイル）
⑧Dovecot/Postfix	使うプロトコルに応じて25/465/587/993/995
⑨Vsftpd	`21/tcp` + パッシブポート範囲（vsftpd.conf側と一致させる）
⑭MongoDB、⑯RabbitMQ	外部公開せず、必要時は送信元IPを絞って許可

10ここまでの状態

追加IPv4（160.251.145.xx）を取得・割当、ウェブ専用として運用する方針を決定
標準IPv6 17個すべてをeth0に設定、追加IPv4はeth1＋ポリシールーティングで設定
curl --interfaceで追加IPv4からの送信経路を確認済み
ConoHaセキュリティグループ・ufwともにSSH以外は未開放の状態で③に進む