Hi there 👋

背景 いや、ちょっとこれも恥ずかしい話なんですがね。 僕は長いこと、「自作パスワード管理システム」的なものを運用していました。 どうやっていたかというと、 自前ホストしているRocket.Chat に、自分専用のチャンネルをひっそり立てて、 誰も入れないように鍵をかけて、 そのスレッドに “ログイン情報をラベル付きで投稿する” という、 ある意味 究極のアナログ DX をやっていたわけです。 もちろん一応、安全面は全く考えてなかったわけではなくて、 Rocket.Chat のデータは gocryptfs で暗号化されたストレージに保存 通信経路は https で暗号化 サーバは自分の管理下 チャンネルは自分しかアクセスできない と、一応「最低限の安全性」は確保しているつもりでした。 だけど、世の中ではみんな LastPass だの 1Password だの Bitwarden だのと言っているじゃないですか。 僕はこういう “流行り物” に疎いところがちょっとあって、 「パスワード管理ツールって本当に必要？」 と長年スルーしていたんですよね。 そんなとき、エンジニアの先輩から 「Bitwarden の OSS クローンで Vaultwarden っていうのがあって、自前ホストも簡単で、めっちゃ良いよ」 とすすめられました。 で、触ってみたら、UI も綺麗だし、ストレージ管理もラクだし、 正直「これはかなりイケてるな」と感じたわけです。 しかし、ここから僕の悪い癖が発動します。 “仕組みが分かっていないものに重要な情報を預けるのが嫌” これは性格なんですが、 ブラックボックスは信用できない。 暗号化の仕組みがわからないと不安になる。 果たして、 自前のサーバ（しかもレンタル）に Vaultwarden を置いて、 そこに人生の全パスワードをぶち込んで大丈夫なのか？ という疑念がどうしても消えない。 結論から言うと： Vaultwarden（Bitwarden）は、むしろ「Rocket.Chatにパスワードを書いてた頃の比じゃないほど安全」だった。 調べれば調べるほど「これは信頼できる暗号設計だな」と感じたので、 今回はその 安全性の仕組み をブログとしてまとめたいと思う。 安全性の評価 Bitwarden / Vaultwarden が扱う暗号モデルは、 いわゆる ゼロ知識暗号（Zero-Knowledge Encryption） である。 ...

いつもnatの設定を忘れてしまうのでここに残しておきたい ss@kong:~$ sudo sysctl -w net.ipv4.ip_forward=1 && \ sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -d 192.168.10.0/24 -o enp9s0 -j MASQUERADE && \ sudo iptables -A FORWARD -i tun0 -o enp9s0 -s 10.8.0.0/24 -d 192.168.10.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT && \ sudo iptables -A FORWARD -i enp9s0 -o tun0 -s 192.168.10.0/24 -d 10.8.0.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT

SRE本を読んでいく こちら

背景 複数拠点（A, B, Cなど）を OpenVPN 経由で接続し、 **2系統のVPNトンネル（10.8.0.0/24 と 10.10.0.0/24）**を経由して経路冗長化したい。（openvpnサーバは独立した2マシン） そんなニーズから検証を始めました。 各拠点はそれぞれローカルLAN（例: 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24）を持ち、 それらを OSPF (FRRouting) で自動経路学習させて、 VPNトンネル越しに相互通信できるようにしたい、という構成です。 やりたかったこと OpenVPNで各拠点を接続（多拠点site-to-site VPN） FRR (OSPF) を使って動的ルーティング トンネルごとにコストを設定して経路選択 できれば route-nopull で手動ルーティングを制御 目標は「OpenVPNトンネルを2本走らせて、FRRで経路選択を任せる」ことでした。 これを実現するにあたり、色々とハマったので知見をまとめておこうと思います。 OpenVPNのルーティングの構造 OpenVPNはユーザランドで動作し、/dev/net/tun デバイスを通じて通信します。 Linuxカーネルはtunデバイスにパケットを出す そこから先は**OpenVPNプロセス（ユーザランド）**が受け取り、独自の内部ルーティングテーブルで転送を行う つまり、Linuxのルーティングテーブル（ip route）とは別世界で動いています。（ここが非常に大事です。openvpnサーバないのルーティングテーブルがちゃんと設定されていないと、クライアントから届いたパケットをどのクライアントに転送すればいいかがわかりません。ちなみに、openvpnのルーティングテーブルは/var/log/openvpn-status.logから確認可能です） push と route-nopull の関係 OpenVPNサーバはクライアントに対して push “route …” を送ることで、 クライアントのOSにもユーザランドにもルート情報を注入します。 一方、クライアント設定で route-nopull を有効にすると、 その push 情報をすべて拒否します。 frrでルーティングをさせたい場合には、route-nopullにしておかないと、0.0.0.0/1と128.0.0.1/1がOSのルーティングテーブルに登録され、すべてのパケットが特定のnicから出るように設定されてしまうので注意が必要（server側で**push “redirect-gateway def1 bypass-dhcp”**が入っている場合） FRR(OSPF)を組み合わせても解決しない理由 FRRでOSPFを走らせると、 VPNトンネル越しに相手拠点のLAN情報（例: 192.168.x.x/24）が学習されます。 これにより、OSレベルのルーティングテーブルは更新されます。 しかし！ OpenVPNサーバはそのOSルートを全く参照しません。 OpenVPNプロセスは独自に「このLANはどのクライアントの背後にあるか」を iroute で知っていなければ、パケットをどこに転送すべきか判断できません。 自分の場合は、openvpnサーバの/etc/openvpn/ccd以下に書くルーティングファイルの情報が間違っており、クライアント1 -> サーバはパケットが届いていたが、サーバがクライアント2宛のパケットをうまく転送できずdropしてしまっていたのが原因ですね。 ...

以前の記事 https://blog.ingenboy.com/post/problem_site2site/ こちらの記事でVPNクライアントを介して、別々のNWセグメントに所属するサーバ間で通信をする方法を軽く説目しました。 この問題は、リターンパス問題だったのですが、今回、改めてリターンパス問題について書きたい。 まず、 1. IP層での基本ルール 送信元IP と 宛先IP はパケットに埋め込まれていて、転送中は変わらない（※NATしない限り）。 各ホストやルータは「自分のルーティングテーブル」を参照して、この宛先IPはどこに渡すべきか？ を決める。 宛先が自分の直接つながっているネットワークじゃなければ、**次のホップ（ゲートウェイ）**に渡す。 今回問題が起こった構成 [jhonny] 192.168.1.4 tun0:10.8.0.14 │ (LAN:192.168.1.0/24) │ デフォルトほぼVPN (0.0.0.0/1,128.0.0.0/1 → 10.8.0.13) ▼ [家庭ルータ(1系)] 192.168.1.1 │ （インターネット側へ） ▼ [VPN Server] tun0:10.8.0.1 gw:162.x.xxx.xxx ルート: 192.168.2.0/24 → 10.8.0.2(tun0) ▼ [kami] 192.168.2.10 tun0:10.8.0.30 ルート: 192.168.2.0/24 → enp6s0(直結) ▼ [Mac] 192.168.2.3 (LAN:192.168.2.0/24) デフォルトGW: 192.168.2.1（※ここがキモ） 2. 今回の例で流れを追う（リターンパスがなくてpingが返ってこないパターン） サーバから(jhonny)Mac に ping サーバ(10.8.0.1) が「192.168.2.3にICMPを送りたい」と思う VPNトンネルを経由して kaminogou(192.168.2.10) に届く kaminogou の Linux がルーティングを見て「192.168.2.3は自分のLAN直結だからそのまま出す」 Mac の en0 で「送信元=10.8.0.1 宛先=192.168.2.3」の ICMP が見える（ここまではOK） Mac が返信するとき Mac が「宛先=10.8.0.1に返したい」と思う Mac のルーティングテーブルを見る 10.8.0.0/24 の経路が無い なのでデフォルトゲートウェイ(192.168.2.1)に投げる 192.168.2.1（家庭用ルータなど）が「10.8.0.0/24 なんて知らん」と捨てる これがリターンパス問題 問い なぜ送信元が10.8.0.1になるのか？ -> サーバから送ったからだな。完全理解。 ...

概要 2025年9月、RTX 5060 Ti を新マシンに差して Ubuntu 24.04 を入れたら…案の定ドライバ認識でドハマりしました。 この記事では、最初に遭遇したエラーから、最終的に nvidia-smi で 5060 Ti が認識されるまでの流れをまとめます。 1. 最初に出た症状 lspci では GPU が見えている（NVIDIA Corporation Device 2d04）。 しかし nvidia-smi を叩くとエラー： NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. dmesg には probe failed with error -1 が連発。 この時点では「ドライバが GPU を見つけてるけど、初期化に失敗してる」状態でした。 2. CSM と UEFI の壁 調べてみると、自分の Ubuntu は Legacy (CSM有効) モードでインストールされていたことが発覚。 最新の GPU は UEFIブート前提 なので、CSM 有効だと GPU 初期化に失敗しがちです。 対応したこと BIOS で CSM を OFF Above 4G Decoding = Enabled Resizable BAR = Enabled そして Ubuntu を UEFIモードで再インストール これで「Bootable device not found」問題も解決し、環境が最新GPUに対応できるようになりました。 ...

背景 地理、楽しいっすよね。めっちゃ好きです。 でも Google Maps って使うと、結局は Google って会社にお世話になってるわけですよ。 僕はこの「どっかの会社のお世話になっている状態」があまり好きではない。 だからサーバやデータセンターも自前運用するし、 Slack の代わりに Rocket.Chat を使うし、 JIRA ではなく Redmine を使うんです。 じゃあ Google Maps を自前で運用するにはどうするか？ これが今回のテーマです。 地図アプリがどうやって動いているか 必要なものは大きく分けて二つ。 レンダリングエンジン（地図を描画するライブラリ） マップデータ（地図そのもののソース） OSSのレンダリングエンジン（ライブラリ） Leaflet OpenLayers MapLibre GL JS それぞれでベースマップを比較できるデモも作りました。 👉 比較サイト OSSのマップデータ 選択肢は色々あります。 OpenStreetMap (OSM) 世界中のボランティアが作る地図データ。ラスタ（画像タイル）も配布されているが、見た目は少し古臭い。 実際の中身はベクタだが、配信されている地図はあらかじめ描画されているラスタタイル。（元がベクタならそれを出せばいいじゃん、、とは思った） OpenMapTiles OSMデータをベクトルタイル化するOSS。 これを使えば、Google Maps 並みにきれいなベクトル地図を完全自前で運用できる。 ラスタはやっぱり綺麗に映らないですね。なのでベクトルマップが欲しいのですが、 ベクトルマップは自分で作るしかないっぽいです。（Maptilerって会社がOSMを所有しようとしているので気をつけて） 実際に OSM → Vector Map を自前ホストする流れ 1. OSMデータのダウンロード Geofabrik から地域ごとの .osm.pbf を落とす。 例: 日本全体 https://download.geofabrik.de/asia/japan.html 2. OpenMapTiles でベクトルタイル生成 まずは GitHub から OpenMapTiles を取得します。 ...

背景 gmailの返答を自動化するプロジェクトを推進しています。 そこで、RAGですね。もうだいぶ時間が経っていますが、しっかりやっていきたいと思う。 RAG = 「Retrieval-Augmented Generation」 これを理解できればもう仕組みを理解したも同然です。 が一応説明しておきます。 RAGの仕組み めっちゃ簡単にいうと、 ベクトルデータベースに保存されたナレッジから 問い合わせと類似するナレッジを検索し引っ張り出し それを元にGEN AIに回答を作らせる という流れになります。 1でベクトルデータベースにナレッジを保存する時には、元の自然言語をベクトル表現に変換した物を格納する必要があります。 このベクトル変換器のことを「Embedding model」と言います。 x: 自然言語 f: Embedding model とすると y = f(x) で得られたy（とそれに対応するx）をベクトルDBに格納しておくわけですね。 x_q: 問い合わせが来た時 y_q = f(x_q) から得られるy_qと類似しているy_1, y_2, y_3, ,,, y_nを検索し、 それに対応するx_1, x_2, x_3, ,,, x_n を出力し、 ans = LLM(x_1, x_2, x_3, ,,, x_n) とう感じで回答を作らせるという流れです。 Embedding modelsの選定 こちらの記事に書いてある通り、Embedding modelの選定がRAG全体の回答生成性能に大きく影響する。 まあ、chatGPTに聞いた結果これが一番いいのかな。 BAAI/bge-base-en 今回RAGを構築するにあたり使うソフト vector DB: qdrant embedding model: BAAI/bge-base-en LLM: phi4 14b on ollama (@ rtx 3060 12g) Langchainなどの統合的なライブラリは使わない。なぜなら自由度が低いから。 vector DBでの検索も普通にREST APIでできるので問題なさそう。 ...

背景 受託開発先の方からLLMを使って問い合わせや予約業務の自動化ができないかと聞かれた。 もちろんできますよ、と僕は答えたわけです。 しかし、一回gmailの内容をローカルに持って来ないと始まりませんよね？？ なので、gmailのメールをサーバに持ってくるためにgoogle apiを叩きます。 構成 webフロントエンド -> サーバ（アプリ） -> google api google apiの設定方法 1. プロジェクト作成 https://console.cloud.google.com/ にアクセス 以下の写真のgoogle cloudロゴの隣にあるボタンをクリック。この画像で言うと、gmail api access（ここから新しいプロジェクトを作る） プロジェクト名（例：gmail-auto-reply）を入力し、「作成」 2. Gmail API を有効にする google cloudロゴの隣にあるボタンから、先ほど作ったプロジェクトにプロジェクトを変更する 左側メニュー「APIとサービス」 → 「ライブラリ」を押す 検索ボックスに Gmail API と入力し、クリック。 enableボタンを押す 3. OAuth 同意画面を設定する 左側メニュー「APIとサービス」→「OAuth同意画面」 次のような画面が出てくる。get startedを押す 以下の情報を入力する ユーザータイプ 外部（基本はこれでOK） アプリ名 任意（例：Auto Mailer） サポートメール 自分のGmailでOK 開発者連絡先情報 自分のメールアドレス 4. 認証情報を作成（OAuth 2.0 クライアントID） 左メニュー「認証情報」→「＋認証情報を作成」→「OAuth クライアントID」 以下を入力する アプリケーションの種類 → 「Web アプリ」 名前は何でもOK（例：auto-mail-backend） 「承認済みのリダイレクトURI」に以下を追加： http://localhost:3000/auth/google/callback https://yourdomain.com/auth/google/callback (実際に使うサーバ) 作成ボタンを押す。クライアントシークレットが表示されるのでめももしくはダウンロード 5 スコープを追加（必要なら） ここまでで設定が完了。次にやることは以下。 ...

背景 自宅で動かしている Ollama + GenAI モデル（例えば phi4:14b）を、インターネット越しに使いたくなった。OpenVPN で穴を開けた上で、Nginx を使って自宅マシンへのプロキシを構成。 [ インターネット ] ↓ VPSのnginx (443) ↓ OpenVPN経由のプライベートIP (100.64.x.x) ↓ 自宅のGenAIサーバ (Ollama) 確かに便利ではあるが、「誰でも使える状態」にしてしまうのは少し怖くなった。 なので、Basic認証 を導入して、ユーザーとパスワードを知らないとアクセスできないようにした。 Nginx に Basic認証を追加する手順 認証用パスワードファイルを作成する まず、htpasswd コマンドを使って .htpasswd を作成。 sudo apt install apache2-utils # 初回のみ sudo htpasswd -c /etc/nginx/.ollama_htpasswd user1 2. Nginx の設定に認証を追加 /etc/nginx/nginx.conf server { listen 443 ssl; server_name hoge.ingenboy.com; ssl_certificate /etc/letsencrypt/live/ollama.ingenboy.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/ollama.ingenboy.com/privkey.pem; add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'Origin, Content-Type, Accept'; location / { # Basic 認証を有効にする auth_basic "Restricted Area"; auth_basic_user_file /etc/nginx/.ollama_htpasswd; proxy_pass http://100.64.1.41:11434; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } 3. 反映 sudo nginx -t && sudo systemctl reload nginx 4. 確認 curl -v https://ollama.ingenboy.com → 401 Unauthorized ...