Issue

この記事を作った動機 libvirt の仕様を理解していなかった結果、大量の時間を溶かすことがあったので記録したい。具体的には、仮想マシンに対してRDPのためにポート転送を設定しようとしたが、libvirtが作成する、defaultネットワークに属している、virbr0ブリッジはnftablesをいじっても言うことを聞かないほど、ガチガチに守られていて使うべきではないという結論に至った。 今回はそこに至るまでの経緯と、実際に機能する事を確かめた対処方法について記録する。機能する対処方法の概要としては、libvirt以外に、手動でブリッジを専用に作成し、それに対してfirewalldでNATやDNATを構成し、仮想マシンにそのブリッジを使うように設定する事をする。 機能した対処方法 仮定 仮想マシンを動かしているホストマシンは、firewalldのpublicゾーンを使用している ホストマシンは、ブリッジに対して192.168.150.1/24のIPを持つ 仮想マシンのIPは手動で192.168.150.25/24を割り当て、ゲートウェイにはホストマシンに向けて192.168.150.1と設定する sysctl -w net.ipv4.ip_forward=1が設定されており、カーネルが異なるインタフェース間のパケットの行き来を許可していること ブリッジを作成 sudo brctl addbr virt sudo ip link set virt up sudo ip addr add 192.168.150.1/24 dev virt 仮想マシンを作成したブリッジを使うように設定 firewalld でNATとDNATを構成する # ゾーンとポリシー(NAT用)を作成 sudo firewall-cmd --new-zone=virt --permanent sudo firewall-cmd --zone=virt --add-interface=virt --permanent sudo firewall-cmd --zone=virt --new-policy=nat --permanent sudo firewall-cmd --policy=nat --add-ingress-zone=virt --permanent sudo firewall-cmd --policy=nat --add-egress-zone=public --permanent sudo firewall-cmd --policy=nat --add-masquerade --permanent # ポート転送設定(DNAT) sudo firewall-cmd --zone=public --add-forward-port=port=33890:proto=tcp:toport=3389:toaddr=192.168.150.25 --permanent sudo firewall-cmd --zone=public --add-forward-port=port=33890:proto=udp:toport=3389:toaddr=192.168.150.25 --permanent # NATが機能するようにマスカレードと転送を設定 sudo firewall-cmd --zone=public --add-masquerade --permanent sudo firewall-cmd --zone=virt --add-forward --permanent sudo systemctl restart firewalld 問題至るまでの経緯 今までの構成を見直す 今まで仮想マシンへのRDPアクセスは、無理やりVPN経路を通じて同じLAN内に仮想マシンを参加させることで動かしていた。接続が不安定であり定期的にVPNが接続できなくなったり、ネットワークトポロジ的にも循環経路を形成しかねないように見受けられた。VPNを介さずにホストマシンを直接介させることで、仮想マシンに対してRDPを行うために、今回は仮想マシンのRDPポートである、3389に対してポート転送を行う事を考えた。 ...

この記事を作った動機 Linux 環境にて簡単に Web アプリを作ろうとしたところ、以下のようになって開発サーバを立ち上げられない事態になり、開発が続行できなくなったということがあって、だいぶ時間を溶かしたので記録を取る。 npm create vite@latest # ... # npx でも症状は同じ npm run dev # npm notice run rss-listing@0.0.0 dev # npm notice run vite # sh: 行 1: vite: command not found 簡単な結論 npm を使ったプロジェクトを立ち上げる際は、フォルダのパスに特殊文字が含まれていないか注意する。:がパスに含まれていた場合、npm はそれを自動的にエスケープするなどの処理をせずに、PATHを登録してしまう。npm の機構によって動的にPATHが正しく登録できないと、npm でインストールされたパッケージのバイナリやスクリプトが必要なタイミングで実行できず、開発を続行できない。BASH の PATH の解釈が不正なところで途切れて、npm の動作に必要なバイナリやスクリプトへのパスが通らず、動作が破綻する。問題の具体例は以下のとおりである。 問題のパスの例 # /home/useName/work/free/2026-08-18-09:16:14-1787012174/ProjectName/node_modules/.bin 問題のパスが npm(npx) によって、PATH に登録される例 # /home/useName/work/free/2026-08-18-09:16:14-1787012174/ProjectName/node_modules/.bin:/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin:/opt/miniconda3/condabin:/usr/local/bin # 実際にはもっと長く続くが例として途中でちょん切っている。 BASH での解釈のされ方の例 # /home/useName/work/free/2026-08-18-09 # 意図しないところでパスがちょん切れる # 16 # 意図しないところでパスがちょん切れる # 14-1787012174/ProjectName/node_modules/.bin # /home/linuxbrew/.linuxbrew/bin # /home/linuxbrew/.linuxbrew/sbin # /opt/miniconda3/condabin # /usr/local/bin # ... なおこのような問題は、Windows など最初から、":" の文字がフォルダ名などに特殊文字として登録できないファイルシステムを使う環境では起こらないかもしれない。私が、普段の環境で使っているのは、Ext4 というファイルシステムであり、":“がファイル名やフォルダ名に含めることができ、問題が起こったものだと思われる。npm 関連のリポジトリにこれについて Issue を作ったり Pull Request を作るべきかは謎であるが、私はその点に関して自信は何もないので、結局何もしないだろう。 ...

この記事を作った動機 最近、なんか公開鍵認証で鍵を登録したのにパスワードを求められたり、あるいは完全に特定のPCにおいて、SSH ログインが動作しているPCと設定が同じであるにもかかわらずログインできなかったりと、色々振り回されていることについて、いい加減対応しようと思い調べた。それで色々手こずったので、記録を残したい。 結論としては、SSH クライアントなど OpenSSL 周りはどんどん新しくなっていき、古い認証用バイナリは削除され、使えなくなることが時間の問題であることが分かった。SSH ログインによる ILO4 制御を諦めたほうが良いという結論になった。今まで SSH で管理してきたという背景からは、CLI で動く SSH であることが望ましかった。しかし、現実的な妥協点が、Selenium を使って ILO4 の Web インターフェースを自動化するか、RESTfulAPI を使って curl コマンドで ILO を HTTP により操作するということに至った。 環境 HPE Proliant Gen9 シリーズに搭載されている、ILO4 について。 ILO4 のバージョン iLO Feb 06 2023 2.82 ILO4 は LAN 内で動作しており、グローバル空間に直接つながっていない閉鎖的な環境下であり、SSH の暗号化がそれほど重要でない場面を想定 具体的な経緯など 組み込み機器にある SSH サーバはその用途に最適化されており、新しい規格についていけないところがある。いくらオプションを指定してももはや私が常用している Linux 環境の SSH クライアントではログイン不能であった。今までは、SSH クライアントに以下のオプションをつけることでゴリ押ししてログインできていたが、最近のアップデートの影響かできなくなったぽいことも、問題に本格的に取り組もうと思った動機であった。 KexAlgorithms=+diffie-hellman-group14-sha1 HostKeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa 上記設定が通用した OpenSSL のバージョンと、通用しなくなったと思われるバージョンを以下に示す。 通用するとき openssl -v OpenSSL 3.5.2 5 Aug 2025 (Library: OpenSSL 3.5.2 5 Aug 2025) 通用しないとき openssl -v OpenSSL 3.6.3 9 Jun 2026 (Library: OpenSSL 3.6.3 9 Jun 2026) 試したことについて RESTfulAPI と Curl コマンドを使う方法 (今回採用した手法) 結局のところ、HTTP を介して行われる、RESTfulAPI を直接 curl コマンドで叩くのが現実的であるということになったが、自分でスクリプトを書いたわけではない。とにかく ILO4 経由でサーバの電源をリモートで気軽に入れたいだけだったため、ローカルLLM (Gemma4-12B-qat) に直接書かせた。最初はまあ動かない物を出してきたが、ネットから ILO4 RESTful API Reference のドキュメントを引っ張り出して、全部ではなくAuthentication and Sessionsあたりのセッションの文字列をヒントとして与えたところで、動作するスクリプトを手に入れることができた。パスワードなどの認証情報(機密情報)も与えて、とりあえず簡単に動くスクリプトを作るように指示できるのは、学習データに入力内容が使われるおそれも心配しなくていいローカル LLM 環境ならではであるようにも思う。 ...

このページは、まだ未完成です。。。 nicotalk＆キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html （2024年5月16日） この記事を作った動機 最近、Google (Gmail) とかに深く関係があるのは嫌であることや、中央集権的な SAAS サービスへの不信がある。そこで、自前のメールサーバを持ちたいと思い、Mailcow を使おうとしたので不完全でいいので作業過程の記録を取りたい。 前提条件 Arch Linux 環境で作業を行い、Mailcow 公式サポートはない状態である 専用の物理 PC を割り当てる クリーンインストールで、Gnome デスクトップ環境や最低限のパッケージが入った、Arch Linux 環境 スリープを無効化している。-> gnomeの設定のメモ ⚙ firewalld は導入していないこと -> Prepare your system - mailcow: dockerized documentation できれば yayコマンド を導入する NetworkManager を使っている。 DNS サーバにクラウドフレアを使っている。 設定要件 自分の LAN (VPN) 環境のみからメールの送信を受け付け、グローバル IP 空間からはメールの送信を受け付けない メールの受信についての対策は、Mailcow 標準に頼りたい 利用者は自分や自分が許可した少数の身内のみ メールサーバ自体は直接グローバル IP 空間には晒さず、VPN や LAN のネットワーク空間を転送するようにして利用する。 ネットワーク構成 ネットワーク構成としては、通常のメールサーバではグローバル空間に配置してファイヤウォールに必要な分だけ慎重に穴を開けるなどのスタンスを取ると考えられるが、今回のはセキュリティーの観点から、そうはしなかった。 基本的には、メールサーバは直接グローバル空間には晒さず、かつNAT環境下にある自宅の専用に用意したサーバを使うという観点から、別の専用にグローバル空間とつながっていて固定IP持っている中継サーバ(VPS)で、ポート転送などを行うという形態を取った。また、セキュリティの観点から メールを送受信したり、サーバを管理できるユーザは、VPNによって自宅のLAN内にアクセスできる人間のみとし、グローバル空間からは、SMTPポートだけ、晒して、メールは送受信できるようにしつつ、外部の人間は今回構築するメールサーバに対して、リレーとして使ったり、送信を命令することはできないようにしている。メールを送信できる人は、メールサーバと同じLANに属しているユーザだけであり、メールの受信はどこからでもスパムでないこと、不正でないことを前提に、スパムフィルターで弾かれなかったものが受け付けられるという形態を取る。 中継には VPS を使い、メールサーバとVPS間は専用に用意したVPNネットワークで接続される。これにより、NAT超えも実現しながら、メールサーバを直接グローバル空間に晒さずに済むというものである。注意点としてはメールサーバ側のルーティングや、VPS側のファイヤウォール、転送設定がを間違っていると、セキュリティリスクになる点を留意する。 イメージ用の図いろいろ ネットワーク構成の概要 大まかなルート構成 VPSにおけるポート転送と特別なルーティング(nftables)で成立 通常のSMTPとして成立するルート 外部のメールサーバからの見え方 メール送受信のためのフロントエンドアクセスが出来る範囲 SMTP 関連パケットのルーティングについて メール受信時の経路 メール送信、SMTP における応答通信時における経路 不正な SMTP パケットの経路 ネットワーク設定 VPS プロバイダの設定 VPS の設定 メールサーバ本体の設定 説明用の仮定 メールアドレス xxxx@your.domain.comのようにする。 メールサーバについて mx.your.domain.comにホストすることにする。 IPアドレスを160.251.xxx.xxxとして仮定する。 Mailcow のインストール docker 環境の導入 # 必要なパッケージのインストール (jq は mailcow の依存関係) yay -Sy docker docker-compose jq # sudo pacman -Sy docker docker-compose jq # サービスの有効化 sudo systemctl enable --now docker # 必要であれば管理用ユーザを docker グループに追加し、権限を付与する sudo usermod -aG docker [targetUser] # 念のため再起動 sudo systemctl reboot IP アドレスの固定 今回は、NetworkManager を Gnome 環境に組み合わせた状態なので、Gnome の GUI から設定を行った。 ...

この記事を作った動機 最近、XPS 13 2in1 (intel 8th) を使っていて、バッテリーが完全に放電しきった状態で放置していることがあった。それで、通常であれば、CMOS 電池が設定内容を保持していて、UEFI の変数などのデータを保持しているはずだが、今回は違った。PC を充電器に繋ぎ、起動すると CMOS リセット時に見られる挙動である何度か再起動をするということになった。ようやく動いたかと思ったら、普段の設定とは異なって、Dual Boot 構成にしていた Windows がのそのそと起動し始めた。あまりのストレスに PC を投げ出したくなったが、結局色々調べて振り回されたことがあったので、記録したい。 経緯 PC が完全に2日程度放置していて、放電しきっていることに気づく。 Windows が起動しようとしてイライラする Linux 環境を立ち上げようとして、UEFI の設定画面でエントリを作成し起動を試みるも、“no resume device found"と言われ起動しない GURB の設定を編集しresume=と書かれているところを消すも、症状が改善せず。 起動するために USB を用意するもDD コマンドによる起動可能な USB 作成において説明される問題により、一度失敗する ローカルLLM である Gemma4 に投げるも、通常のターミナル環境を起動できないから困っているにもかかわらず、ターミナルを使えだの的はずれなことばっか出力してきて爆発しそうになる。例えばresume=noneにしたら上手くいくと出力してくるが、機能しなかった。 DD コマンドによる起動可能な USB 作成により、最終的に正しく起動する USB メモリを作成し、ようやくライブ環境の端末が起動する ドライブモードが RAID になっていることに気づき、AHCIに設定する しかし奇妙なことに最初ライブ環境を起動したとき、肝心の Linux 環境が入っている NVME SSD が見えず、もう一度 CMOS がリセットされた状態にして、再トライすることになる もう一回 AHCI に設定する ようやくライブ環境から SSD が見えるようになり、initramfs から resume の hooks を吹き飛ばすことと、GRUB の resume 設定をなしにして起動設定を再生成させる ようやく PC が正常に Linux 環境に起動するようになる。 今回の問題を起こした主犯であると思われる、CMOS 電池について調べる。 ポイント “no resume device found” で Linux 環境が起動しない 完全には確かめられていないが、どうも AHCI でもともと動かしていた物を、CMOS リセットが起こった時点で、RAIDになっていたために、それで起動しようとした結果起動できなかったということっぽい？しかし、USB のライブ環境に入れるようになってから、AHCI にドライブのモードを設定することは試したため、本当にそれが問題かは謎である。Linux 環境なら元からドライバは入っていそうなものだし、考えられることとしては、RAID モードであるときと、AHCI モードであるときで、パティーションの UUID が異なってしまうのかな？とは考えた。 ...

この記事を作った動機 Intel Arc で音声からの文字起こしができる Whisper を動かせることが分かったので記録したい。Whisper は PyTorch を使っているが、それを XPU に対応したものに差し替えることで動作が確認できたことに関して、具体的に作業内容を記録したい。 Whisper を使った文字起こしでは、Vibe を使うことでもできるが、Nvidia の CUDA 環境で無い限り、Intel Arc 環境においては、Vulkan を使ってしまう。PyTorch 環境においては XPU を使わなければ、Intel Arc の GPU 性能を使い切れていない気がすると思ったのもある。 ただ実際に試してみると、今のところそこまで早いとは言えず、むしろ Vulkan で動かしているときより遅い気もした。設定次第なのかもしれないが、そこまでは詳しく試していない。 環境の前提 Intel Arc を使っている Conda 環境を導入済み Linux 環境 記事の作業内容のまとめ conda create -n whisper conda activate whisper conda install pip pip install -U openai-whisper pip uninstall torch pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/xpu Whisper のインストール conda 環境を専用に作る conda create -n whisper conda activate whisper conda install pip whisper を pip でインストール 一旦 Nvidia 環境用の pytorch などがインストールされてしまうが、一旦はインストールを終わらせる。 ...

この記事を作った動機 LibreChat を使っているうちに、色々躓いたことがあったので記録したい。躓いたことでなくてもまとめておきたいことは書きたい。 前提条件 環境構築をしたディレクトリが以下のパスになっている LibreChat の Docker 関連のファイルが以下のディレクトリにある事を前提に進める。通常であれば、各個人に合わせて作業して良い。私の場合はあくまで以下のパスにあるというだけである。 ~/LibreChat LLM サーバの構成と、LibreChatの関係 以下の図のような関係になっている事を前提にする。 MainDesktop エンドポイント エンドポイントまでのアドレスとポート番号の仮定 http://192.168.x.a:8080/v1 詳細な役割の説明 純粋に llama.cpp を動かして1つのモデルを読み込んでいる LLM サーバ専用(Gemma-4-31Bを動かす専用)に割り当てた PC である。LibreChat はここではホストしていない。Intel ARC の XPU 環境であり、LM Studio ではそのポテンシャルを引き出せないため、llama.cpp を専用にコンパイルしてセットアップしてある。OpenAI 互換 API 経由で利用可能にしてある。 DataServer エンドポイント エンドポイントまでのアドレスとポート番号の仮定 http://192.168.x.b:1234/v1 詳細な役割の説明 LM Studio を使って LLM を動かしている。こちらは、MainDesktop と異なり、NVIDIA の CUDA 環境であるため、LM Studio でポテンシャルを引き出すことができることから、LM Studio を使っている。LM Studio 標準の開発者機能から、OpenAI 互換 API 経由で利用可能にしてある。基本的に LM Studio の LLM サーバーが、LibreChat の要求に答えて選択されたモデルを自動的にロードし動かしてくれるため、いろんなモデルを動かすために使う。 その他諸々 Linux 環境である docker、docker-composeパッケージが入っている 全ては LAN 内で行われ、グローバル空間からのアクセスはできないようにしてある環境である。外出先からの利用はすべて VPN を通じて行う。 基本的な操作 設定ファイル保存場所 ~/LibreChat/librechat.yaml 設定反映方法 (librechat.yaml) 私の場合は、~/LibreChatにおいて以下のスクリプトをrestart.shとして配置し、実行することでlibrechat.yamlの変更内容を反映できる事を確認した。docker グループに入っていないユーザは、管理者権限を付与してコマンドを実行することで docker を操作できる。 ...

このページは、まだ未完成です。。。 nicotalk＆キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html （2024年5月16日） この記事を作った動機 Intel Arc A770 LE を使っているが、NVIDIA の RTX や H100 などと異なり、標準でのサポートが薄い。そのため、フルで性能を引き出したい場合は、自分で LLM なら llama.cpp などを OneAPI を使ってコンパイルする必要がある。 LLM に関しては、当初は Intel Arc の環境において LM Studio を利用していたが、Vulkan でしか少なくとも現状では動作させることができなかった。Ollama についても試したが、どう頑張っても Apple の メタルプラットフォーム向けにしかコンパイルが動作せず、どうしよもない感じであった。そこでそれらのバックエンドである、llama.cpp を直接コンパイルして動かすことが考えられ、フロントは別に LibreChat を独立して用意する事が考えられた。 標準でも Vulkan の互換モードで動作し、使えないということはないが、多少性能が失われる。ただ、SYCL など向けに、Intel Arc を最大限使えるようにしようとすると、自分でコンパイルする必要がある。専用に用意しなければ現状では llama.cpp などは CPU しか利用できないとして Intel Arc をそもそも認識しないという挙動になった。またコンパイル自体や、コンパイル後のバイナリの扱いについて、特別な扱いが必要である。 Intel が公式で llama.cpp などのバイナリを配布していたりするが、バージョンが古く新しいモデルが動かないなど、弊害が生じる場合があった。 これらのことから、Intel Arc 向けに今回は、llama.cpp を SYCL を使えるようにコンパイルすることにした。また、PKGBUILD も作成し、手動で手順を踏まなくても、ある程度自動で Arch Linux や同じ系列の OS を使っていれば、環境が整うように工夫した。 Gemini Fast 3 を作業補助として使い、動くか確認しながら作業をした。ただそれだけだと、情報が十分まとまっておらず、環境を再構築する必要が生じたときなどに困難が想像されたため、記録を残して現状を整理したい。 なお、特にコンパイルや SYCL 周りの環境変数などは、LLM が吐き出したものをそのまま使っているだけの部分が多く色々間違っていたりする可能性がある。あくまで私の環境でやってみて動くかというのを基準にして書いている。 ...

この記事を作った動機 Android 端末において SoftEther VPN で稼働しているサーバに接続しようとすると、L2TP/IPsec を使った方法と、OpenVPN を使った方法の2つの接続方法がある。しかし、新しいバージョンの Android (12以降) において標準的に利用できる VPN には既に L2TP/IPsec は含まれておらず接続できない。また、OpenVPN を使った方法では、接続には成功するものの、そこに至るまでの設定が分かりづらかったり、技術的に一筋縄では行かないところが多々あった。これら経緯から、やったことについて記録を残したい。 ネットワーク構成 全体像 今回は、192.168.x.0/24 として描かれているネットワークに属するクライアントを Android スマホに見立てる。 今回問題になった特徴について 私の環境では通常のVPNネットワークと異なり、VPNに接続した先にあるネットワークを介して、更に別のネットワークにパケットを転送するPCがあって、そこを介してやり取りするという特徴があり、今回問題になった。 記録 VPN 接続したときのスマホのルーティングテーブルの様子 基本的に OpenVPN 関連で特別なルーティング設定をしても Android OS 側は直接制御を持っていないように見受けられる。以下のように192.168.1.0/24へのルーティングは、OpenVPN 側で正しく動作していても以下のように直接は確認できない。 adb shell cofud:/ $ ip route 10.0.0.0/8 dev ccmni1 proto kernel scope link src 10.150.92.221 192.168.30.12/30 dev tun0 proto kernel scope link src 192.168.30.13 cofud:/ $ exit 使うべきアプリ OpenVPN Connect ではなく、OpenVPN for Android を使うべき。 Android ではアプリを介してしか詳細な制御ができず、OpenVPN Connect は限られた設定項目しか利用できない問題があった。ルーティングや MTU、MSS、DNSなどについて細かく設定したい場合は、OpenVPN for Android などの別のアプリが必要であった。OpenVPN Connect などのアプリは、基本的に詳細な設定ができず、かつどのように読み込ませた".ovpn"などの設定が実際反映されているか確認が難しかったり色々困難があった。 ...

この記事を作った動機 Linux 環境において、VPN 環境についてトラブルシュートしていたところ、設定ミスが発生した。その原因として、viaという単語を正しく解釈できておらず、VPN クライアントの設定ミスでパケットをクライアント内のネットワークでループさせていたということがあった。今回の記事では、そのことについて軽くまとめたい。 説明 簡易的な解釈 iproute2 における via というキーワードは、ゲートウェイ設定(静的ルーティング、Next Hop)を表す。ルーティングされる対象のネットワーク via ゲートウェイ のような書き方になる。ゲートウェイとして、クライアント自身を設定してしまうとローカルでループしてパケットが期待どうりにネットワークに排出されない通信障害になる。 例えば、クライアントが VPN 接続先以外のネットワークから VPN 接続をすることを想定する。VPN クライアントは仮想インターフェース(vpn_vps)に、192.168.30.100/24 を持っていると仮定し、VPN サーバの仮想ハブが 192.168.30.2 をL3仮想スイッチルーティング用に持っている場合を想定する。この場合、192.168.30.0/24 のネットワークを経由して、192.168.0.0/24 にパケットを送りたい場合は、192.168.30.2 をゲートウェイを設定する。192.168.30.100/24 などクライアント自身を指定すると、通信がローカルでループし、VPN クライアントはそもそもパケットを外部のネットワークに排出せず、通信障害になる。 一見すると 192.168.0.0/24 via [VPNクライアント自身のIP] とかくと、VPNクライアント自身のIPを経由して外部に 192.168.0.0/24 宛てのパケットをルーティングするという解釈もできそうだが、少なくとも Linux 環境の iproute2 の設定においては、その解釈は間違っていそうである。あくまで via というキーワードが示しているのは、次にパケットをどのコンピュータに送るべきか、外部のルーティングが可能なコンピュータの IP を指定するという意味合いなようである。クライアント自身を設定してしまうと、クライアント自身にルーティングしてしまうようである。 また、Linux 環境の iproute2 における設定では、明確に外部のゲートウェイとなる PC の IP を指定しなくても、パケットを送り出したいインターフェースだけ指定するという、曖昧な設定もできるようである。192.168.0.0/24 dev vpn_vps のようにして、192.168.0.0/24 宛てのパケットを、vpn_vps という NIC からとにかく送り出すという設定はできるようである。 # いろんな書き方の例 # VPNクライアントとして接続されているルータPCにルーティングする仮想L3スイッチのIPを 192.168.30.2/24 として仮定している ip route add 192.168.0.0/24 via 192.168.30.2 dev vpn_vps ip route add 192.168.0.0/24 dev vpn_vps ip route add defalt via 192.168.30.2 dev vpn_vps 前提とするネットワーク構成図に関する説明 単語の説明 Home Network 自宅のネットワークなど私的に運用される LAN Foreign Network 大学や仕事場所、コンビニやファミレスなどにある公共の場所にある LAN 各ネットワークに関する説明 192.168.0.0/24 家庭用ルータではなく、主に nftables によって転送が管理されていて、カーネルで転送許可をしてある Linux ルータPCで管理されている自宅のネットワーク 192.168.30.0/24 固定 IP を持った VPS 上で動いている SoftEther VPN Server (DHCP サーバが有効) における仮想ハブのネットワーク 192.168.x.0/24 大学や仕事場所、コンビニやファミレスなどにある公共の場所のネットワーク 192.168.0.1/24 192.168.30.2/24 192.168.x.1/24 各ネットワークにおけるデフォルトゲートウェイ や DHCP、場合によっては DNS サーバーなど一通りのルーティングなどのネットワークに必要な機能を備えた装置の IP やルーティングを行う仮想L3スイッチの IP 192.168.30.13/24 SoftEther VPN Server を動かしている VPS がクライアントとして仮想ハブのネットワークに参加しているときの IP 192.168.30.100/24 Foreign Network から VPN 接続して仮想ハブに参加している VPN クライアントの仮想 NIC における IP NIC 名の説明 vpn_vps Foreign Network から VPS 上にある VPN の仮想ハブにアクセスする際に、VPN クライアントが使う仮想インターフェース名 その他説明 ルータPC Home Network で使われている、家庭用ルータの代わりに、スイッチとセットで nftables で転送や NAT を構成し、ip-hole や kea で DNS や DHCP サーバとしても機能するようにした Linux PC のこと。VPS 上で動いている VPN サーバのネットワークにもクライアントとして参加し、192.168.30.0/24 と 192.168.0.0/24 の間を転送する。異なるネットワーク間を転送する際、ARPプロキシ(L2ルーティング)は有効にしていない。 VPN サーバー 今回登場する VPN サーバーは直接 Home Network からは動作せず、VPS 上に専用に用意したものである。192.168.30.0/24 のネットワークを接続した VPN クライアントに提供する。仮想 L3 スイッチの設定により、192.168.0.0/24 宛てへのパケットを、192.168.30.0/24 に接続していてネットワークの越境が可能な転送設定をしてある VPN クライアントであるルータPCに仕向けるように設定してある。 説明の図 各ルーティング状況に関する説明 パケットがクライアント内部でループするイメージ 上記の図のような状況において、トラブルシュートでは以下のような厄介な挙動が見受けられた。 ...