カテゴリー: 技術

技術が生まれては消えていく、諸行無常のITの世界。個人が技術ログや検証環境を公開するための基盤として、クラウド（VPS）の選定は最初の分岐点となる。

国内にはConoHa VPSやさくらのVPSといった、日本語のドキュメントが豊富で至れり尽くせりな環境が整っている。しかし、本ブログの公開基盤（node01）には、グローバルで圧倒的なポータビリティを持つ海外VPS「Vultr」を選定した。

派手な広告やスペックシート上の数字に翻弄されず、インフラエンジニアの視点で両者の本質を比較し、さらに海外VPSの運用で必ず直面する「Outbound Port 25の沈黙」をサーバーレスで解決した実録をここに記す。

---

1. 徹底比較：Vultrと国内VPSの境界線

インフラを構築するにあたり、まずは国内大手VPSとVultrの特性を実直に比較した。

インフラの柔軟性とポータビリティ

Vultrの最大の利点は、OS選定の身軽さと秒単位の従量課金システムにある。国内VPSの多くは月額固定、あるいは時間単位の課金だが、Vultrは完全に使った分だけの請求となる。さらに、最新の Debian 13 (trixie) といったディストリビューションを即座にデプロイし、不要になればコンテナごと躊躇なく破棄・再構築できる。この圧倒的な機動性は、検証を繰り返すエンジニアにとって大きな価値がある。

ネットワークとロケーション

海外VPSと聞くとレイテンシ（遅延）を懸念するかもしれないが、Vultrは「東京リージョン」を完備している。実際に Chromebook（host）から東京リージョンの node01 へ通信を試みても、国内VPSと全く遜色ない極めて低レイテンシなレスポンスを維持している。地理的な制約は、東京リージョンを選ぶことで完全に無効化できる。

運用の手軽さとサポート

一方で、国内VPS（ConoHaなど）の優位性は、コントロールパネルの分かりやすさと日本語サポートの安心感にある。クレジットカードだけでなく、各種決済手段が標準で用意されている点も手軽だ。もし「インフラの細かい挙動に時間を取られたくない」「手早くWordPressを立ち上げたい」という場合は、ConoHa等の国内VPSを選ぶのが確実な選択肢になる。

その中でも、初期費用が無料で時間課金にも対応し、初心者からエンジニアまで広く支持されているConoHa VPSは、手堅く堅牢な選択肢の一つと言える。

---

2. 海外VPSが抱える「諸行無常の罠」：Outbound Port 25の沈黙

Vultrを選択し、Docker Compose による LEMP スタック（Nginx, WordPress, MariaDB）を立ち上げた後、一つの制約に直面した。それは、外部へのメール送信（Outbound Port 25）の常時閉塞である。

これは世界的なスパムメール抑制のための標準的なセキュリティ対策（OP25B）だ。国内VPSであれば、契約から一定時間（例：72時間）が経過すれば自動的に解除されることが多い。しかし、Vultrのような海外VPSにおいて、この制限は「原則として常時閉塞」であり、解除のためのサポート申請には厳格な身元確認や実績の提示という非常に泥臭いプロセスを要求される。

システムから「お問い合わせの通知メール」や「監視アラート」を送信したいだけにもかかわらず、インフラの壁に阻まれてポートが沈黙する。

だが、インフラが閉じているなら、サーバーのMTA（Postfix等）をいじって消耗するのではなく、外部の信頼できるコンポーネントを組み合わせて「バイパス（迂回路）」を作ればいい。それこそがエンジニアリングの美学である。

---

3. 技術実録：Resend ＋ Cloudflare によるスマートな迂回

サーバー内部に余計なメールサーバーの構築という不純物を入れず、完全に外部のサーバーレス基盤のみで、独自ドメイン（[email protected]）の送受信環境を構築した。

メールの流動設計

• 受信: 送信者 ➔ [email protected] ➔ 【Cloudflare Email Routing】 ➔ 個人Gmail
• 送信: 個人Gmail ➔ 【Resend SMTP】（中継・認証） ➔ 宛先

この設計であれば、VultrのOutbound Port 25制限の影響を一切受けない。

1. Resendでのドメイン追加

メール送信基盤には、開発者向けに実直なAPIを提供する「Resend」を採用した。ダッシュボードから it-mujo.com を追加し、Region に最寄りの東京(ap-northeast-1)を指定する。

2. Cloudflare DNSでのレコード設定と統合

Resendから提示されたドメイン認証用の各種レコード（TXT、MX）をCloudflareに登録する。この際、プロキシステータスが「DNSのみ」に設定されていることを確認する。

さらに、メールの到達率を高め、なりすましを防ぐためのDMARCレコード（TXT）も指示通りに設定を完了させた。

最も注意すべきはSPFレコード（TXT）の記述だ。すでに Cloudflare Email Routing のSPFが設定されているため、DNSへ個別にレコードを複数追加してはならない（SPFの仕様上、複数レコードの存在は認証エラーの対象となる）。

既存のレコードを編集し、以下のように2つのinclude（識別子）を半角スペースで区切って統合する。

v=spf1 include:_spf.mx.cloudflare.net include:amazonses.com ~all

※当ブログの表示幅の制約により上記レコードは2行に折り返されて表示されるが、実際のDNS設定においては改行を挟まず、すべて半角スペースで区切って入力する。

※Resendが送信基盤として利用している識別子を、既存の記述と適切に組み合わせることで、CloudflareとResendの両者からの送信を正当なものとして証明する。

3. GmailへのSMTP統合

Resendで生成したAPIキー（re_から始まる認証文字列）をパスワードとし、Gmailの「他のメールアドレスを追加」から以下の通り設定を流し込む。

• SMTPサーバー: smtp.resend.com
• ポート: 587
• ユーザー名: resend（固定値）
• パスワード: 生成したAPIキーの文字列
• 接続方式: TLSを使用した安全な接続

これにより、Vultrサーバーの負荷を高めることなく、Gmailの使い慣れたインターフェースから独自ドメインでの双方向通信が完全に開通した。

---

4. 結び：制約を受け入れ、環境と共生する

完璧なクラウドインフラなど存在しない。国内VPSの「至れり尽くせりな環境」も一つの正解だが、Vultrが持つ「海外VPS特有の制約」と対峙し、それを自らの手で美しく克服していく過程にこそ、本質的な運用の愉しみがある。

制約を嘆くのではなく、与えられた環境の中で最適解を模索する。
双方向の通信を確保した node01 は、これでまた一歩、どこにあっても私の思考を支える強固な「標準」へと近づいた。

今回検証の舞台となったVultr（東京リージョン）は、独自の管理ツールによる事前設定を挟まず、OSを最小構成のままデプロイできる。従量課金で機動性の高い開発環境を求めるエンジニアにとって、今もなお有力な選択肢である。

執筆環境: host (Chromebook / Debian 13)
公開基盤: node01 (Vultr / Debian 13 / Docker)
接続環境: NordVPN (NordLynx)

「無常に漂う」執筆活動において、移動先での通信環境確保は避けられない課題である。私は主にスマートフォンによるUSBテザリングを選択している。Wi-Fiと比較して接続が安定し、同時に給電も行えるからだ。

ここで一つ、インターネット上でしばしば曖昧に語られる「誤解」を解いておきたい。

1. 検証：スマホ側VPNはPCを保護するか

一般に「スマートフォン側でVPNを有効にしていれば、テザリング先のデバイスも保護される」という記述を見かけることがある。しかし、私の環境（AndroidからのUSBテザリング）において実機検証した結果、事実は異なった。

スマートフォン側でNordVPNを有効にしても、USB経由で接続された「host（Chromebook/Debian 13）」の通信は、VPNトンネルを経由せず生のアドレスで送出されている。AndroidのOS仕様において、テザリングのトラフィックはVPNインターフェースをバイパスしてルーティングされるためだ。

つまり、移動先での安全を担保するには、接続元である「host」側にも個別のVPNクライアントが不可欠である。

2. hostへのNordVPN導入と環境構築

結論として、私はhost（Debian 13）側にもNordVPNを導入した。

導入プロセス

Debian環境への導入は、公式が提供するインストール用スクリプトを利用した。GUI版を指定して実行することで、CLIを含めたクライアント一式がインストールされる。

user@host:~$ sh ./install.sh -p nordvpn-gui

インストール後、ログインを済ませることでGUI上からステータスの確認や詳細設定が可能となる。なお、プロトコルについてはデフォルトで高速な「NordLynx」が選択されており、特段の変更を必要とせず最適なパフォーマンスが得られた。

通信経路の確定

host側でVPNを確立した状態で curl ifconfig.me を実行し、グローバルIPアドレスがNordVPNサーバーのものに置換されていることを確認した。

日本国内で信頼できるキャリア回線を利用している分には、VPNの必要性は低いかもしれない。しかし、海外の通信網を経由して node01 (Vultr) へSSH接続する局面においては、このトンネルこそが心理的な安全網となる。もちろん、国内外を問わず公衆Wi-Fiを利用する際にも、この設定は「標準」の防壁として機能する。

3. 運用上の私見

巷には「スマホ側でVPNをかければ万全」とする情報も散見されるが、スマートフォンOSのルーティング仕様を考えれば、PC側での個別接続が必須であることは明白である。

複数のデバイスでVPNを動作させることは一見手間に思えるが、通信の出入り口をそれぞれの端末で独立して保護しておくことは、不確定要素の多い移動先でのエンジニアリングにおいて、極めて実直な選択であると考える。私のように移動先での安全を重視するエンジニアにとって、NordVPN は信頼に足るツールと言える。

4. 結び：情報のデバッグ

溢れる情報の中から真実を見極めるには、自身の環境での検証（デバッグ）に勝るものはない。

USBテザリングという日常的な手段の中に潜むセキュリティの空白を、NordVPNの導入によって埋めることができた。これで再び、どこに漂っていても本質を記す準備が整った。

5. 移動先でのエンジニアリングを支える機材

今回の検証のような長時間の外出先での執筆・通信には、安定した電源供給が欠かせない。私は最小限の荷物で最大効率を得るため、以下の充電器を携行している。

Anker Nano II 65W

MacBookやChromebook（C523NA）を急速充電できる出力を持ちながら、極めてコンパクトな充電器。プラグを折り畳めるため、ガジェットポーチの中でも他の機材を傷つけない。

---

執筆環境: host (Chromebook / Debian 13)
公開基盤: node01 (Vultr / Debian 13 / Docker)
接続環境: NordVPN (NordLynx)

1. はじめに：Chromebookという「制約」との対峙

ハードウェアとしてのChromebookは、Web端末として無駄を削ぎ落とした合理的な設計を持つ。その独特な制約を伴う構成は、Linuxを走らせる素材として興味深いが、一方でキーボードレイアウトにはエンジニアとして看過できない「欠落」がある。

これらをいかにして自分の思考のリズムに合わせるか。今回は、Wayland環境下でも強力かつシンプルにキーマップを制御できる「keyd」を用いた解決策を記す。

2. 標準機能の限界と keyd への移行

当初は GNOME 標準の gsettings を用い、検索キー（Super）と左Ctrlの入れ替えを試みた。しかし、「物理キーの組み合わせ（例：Ctrl + Backspace を Delete にする）」といった柔軟な定義を実現するには、標準機能では力不足であった。

複数の設定ツールが混在することは、管理の複雑化（不純物）を招く。私は gsettings の設定を「無」に戻し、すべてのキーマッピングを keyd という一つの器に集約することにした。

3. keyd の導入と設定プロセス

Debian 13 において keyd を導入し、設定ファイル /etc/keyd/default.conf を作成する。

インストールと設定ファイルの作成

user@host:~$ sudo apt update && sudo apt install keyd
user@host:~$ sudo vi /etc/keyd/default.conf

設定内容（/etc/keyd/default.conf）

レイヤーの概念を用いることで、シンプルかつ強力にキーを再定義できる。

[ids]
# すべてのキーボードデバイスを対象にする
*

[main]
# 1. 検索キー(leftmeta)と左Ctrl(leftcontrol)の入れ替え
# 検索キーをcontrolレイヤーとして扱う
leftmeta = layer(control)
# 物理左Ctrlをmetaレイヤーとして扱う
leftcontrol = layer(meta)

# 2. 右AltをDeleteに割り当て
rightalt = delete

# 3. 物理左Ctrl + Backspace を Delete として扱う
[meta]
# metaレイヤー（物理左Ctrl押下時）のBackspaceをDeleteに定義
backspace = delete

4. サービスの有効化

設定を反映させ、永続化するためにサービスを有効化・起動する。

user@host:~$ sudo systemctl enable keyd
user@host:~$ sudo systemctl start keyd

5. 結び：指先が「標準」に馴染む

設定を反映した瞬間、Chromebook特有の違和感は消え、私の指先は使い慣れた「標準」の操作感を取り戻した。

「管理を一つに絞る」という判断が、環境の純度を高める。道具を自分に合わせることこそが、本質的な構築の醍醐味である。

---

執筆環境: host (Chromebook / Debian 13)
公開基盤: node01 (Vultr / Debian 13 / Docker)
接続環境: NordVPN (NordLynx)

1. はじめに：なぜ「host」という名を与えるのか

Debianのインストールが完了した後、最初に行ったのは「個体名」の付与ではなく、標準への回帰である。

私はこの機体に host というホスト名を与えた。RFC 1178では個性的で覚えやすい名前（固有名詞）の採用が推奨されているが、本ブログではあえてその対極を目指す。

多くのRFCや技術文書において、host（あるいは mail や ns 等）は、特定の個体を示す名前ではなく、抽象的な役割や標準的なサンプルを示す記号として登場する。愛称を排し、あえてこの「記号」を名乗る。何者でもない「無」の状態から、私の本質的な構築が始まる。

2. ホスト名の変更プロセス

現代のDebianにおける、最も標準的でクリーンな変更手順を記す。

user@debian:~$ sudo hostnamectl set-hostname host

反映後の確認：

user@host:~$ hostname
host

この user@host:~$ というプロンプトこそが、本ブログにおけるすべての技術ログの起点となる。

3. 最小構成の確認と選定：プリインストールと追加パッケージ

今回のDebian 13環境では、インストール直後の時点で sudo や curl が既に利用可能な状態にあった。これら基本ツールが揃っていることを確認した上で、場所を問わず動作する開発環境を支える、最小限の構成を整える。

プリインストール済み

• sudo / curl: 既に導入済み。
• vim.tiny: 標準で同梱。本格的なエディタや構成管理ツールへの移行は、今後の必要性に応じて検討する。

追加インストールしたパッケージ

• ufw: ファイアウォールの設定。不特定のネットワーク環境における入り口を絞る。
• wget: 外部リソース取得の補完。
• gnome-tweaks: デスクトップ環境における微調整用。

user@host:~$ sudo apt update && sudo apt install -y ufw wget gnome-tweaks

4. 結び：漂いのための地盤が整った

ホスト名が決まり、最小限の道具と防御（ufw）が揃った。
どこにあっても、この「host」が私の標準となる。ここからようやく、Wayland下でのキーマップ調整など、より深い本質の追求へと漂い始めることができる。

---

執筆環境: host (Chromebook / Debian 13)
公開基盤: node01 (Vultr / Debian 13 / Docker)
接続環境: NordVPN (NordLynx)

1. はじめに：なぜ「ChromeOS」を消し去るのか

ハードウェアとしてのChromebookは、その削ぎ落とされた構成ゆえに「無」に近い。しかし、ChromeOSという枠組みの中では、その真価を十分に享受できない。

私はこの機体に純粋なDebian 13を置くことにした。先達の知見を頼りに、既存の環境を解体し、再構築した記録をここに記す。

2. ファームウェアの「書き換え」と現実的な選択

ChromebookにLinuxをクリーンインストールする際、避けて通れないのがファームウェアの操作である。

参照した資料（全学生に知ってもらいたいChromebookにLinuxをクリーンインストールす る方法）では、ハードウェアのWrite Protect（WP）を物理的に解除し、UEFI（Full ROM）を焼く手法が推奨されていた。

しかし、私が手にした個体において、物理的なWP解除（ネジの取り外し等）は相応の手間を要するように見受けられた。分解に挑む労力と、不確実なリスクを天秤にかけた結果、私は物理的な破壊を伴わない道を選択した。

ここで私は、スクリプト（firmware-util.sh）が提示する選択肢と対峙することになる。

• 1) Install/Update RW_LEGACY Firmware: 選択可能。
• 2) Install/Update UEFI (Full ROM) Firmware: WP解除が未済のため、選択不可
  。

私は前者を選んだ。Full ROM化という「完全な解放」ではないが、RW_LEGACYという「共存の道」を選んだことで、分解の手間を避けつつDebianを起動させる準備を整えた。

3. Debian 13 のインストールと直面した「不完全さ」

USBメモリからDebian 13のインストーラーを立ち上げ、既存のパーティションを全て消去する。この瞬間、Chromebookは完全に「無」へと回帰した。

インストール自体は滞りなく完了したが、起動後の環境にはいくつかの「不完全さ」が残された。

• 音の欠落: 内蔵スピーカーからは一切の音が流れない。しかし、Bluetoothヘッドセットを接続すると、静寂は破られた。
• キーボードの違和感: Chromebook特有の配列は、標準的なLinux操作において指の動きを阻害する。

4. 調整：不完全さを受け入れる

音が出ないことも、キーボードが使いにくいことも、この機体を選んだ「無常」の一部である。

私はBluetoothでの音声出力を常用し、Wayland環境下でのキーマップ調整（gsettingsやkeydの活用）を経て、この不完全な道具を自分の思考に馴染ませていった。これらの詳細な設定プロセスは第4記事に記した。

完璧な環境を求めるのではなく、与えられた制約の中で最適解を模索する。それもまた、本質を記すための過程である。

5. 検証に使用した機材

今回の構築にあたり、実際に使用した機材を記しておく。特別なスペックは必要ないが、インストールメディアについては書き込みの安定性と、作業の邪魔にならないサイズ感を重視して選択した。

ASUS Chromebook C523NA

15.6インチの大画面ながら軽量なモデル。今回のDebian 13インストールにおいても、標準的な手順で動作することを確認している。

Transcend JetFlash 710 128GB

堅牢なメタルボディを採用した小型USBメモリ。インストールメディアとして常用しているが、安定性は高い。

---

執筆環境: host (Chromebook / Debian 13)
公開基盤: node01 (Vultr / Debian 13 / Docker)
接続環境: NordVPN (NordLynx)