Networking

この記事を作った動機 最近 SSHFS やら TCP を使った通信において、VPN を経由した通信(ping において time=40ms 前後)が通信経路的には、100Mbps 程度のスループットが出るはずであるが、実際には、10Mbps 程度をうろついてめちゃくちゃに遅いということがあった。その症状はランダムであり、場合によってはそこそこ速度が出る場合もあれば、全然出ない場合もあるということがあった。 当初は、SoftEther VPN のコネクション数をいじったりしていたが、あまり効果が見られない場合があり、最終的に TCP の輻輳制御などに問題があるのではないかと思った。ただ設定をいちいち細々と調べるのはめんどくさかったので、ローカルのLLMに話題を投げてみたところ、実際に効果が見受けられる設定が出てきたので、それをとりあえず記録しておきたい。 設定内容 (/etc/sysctl.d/tcp.conf として保存) 以下の設定を/etc/sysctl.d/tcp.confとして保存したあと、既存の TCP コネクションが古い設定で動き続けるのを防ぐため、再起動する。輻輳制御アルゴリズムなどをデフォルトから変更している。 net.core.default_qdisc=fq net.ipv4.tcp_congestion_control=bbr net.ipv4.tcp_window_scaling=1 net.core.rmem_max=16777216 net.core.wmem_max=16777216 net.ipv4.tcp_rmem=4096 87380 16777216 net.ipv4.tcp_wmem=4096 65536 16777216 設定が反映されたか確認 sysctl net.core.default_qdisc sysctl net.ipv4.tcp_congestion_control sysctl net.ipv4.tcp_window_scaling sysctl net.core.rmem_max sysctl net.core.wmem_max sysctl net.ipv4.tcp_rmem sysctl net.ipv4.tcp_wmem # net.core.default_qdisc = fq # net.ipv4.tcp_congestion_control = bbr # net.ipv4.tcp_window_scaling = 1 # net.core.rmem_max = 16777216 # net.core.wmem_max = 16777216 # net.ipv4.tcp_rmem = 4096 87380 16777216 # net.ipv4.tcp_wmem = 4096 65536 16777216 もともとの設定 私の Arch Linux 環境で、インストール時からネットワーク設定に特段変更を加えていない機材から設定を読み出すと以下のような結果が得られた。輻輳制御アルゴリズムがbbrではなくcubicになっていたりするなど、色々設定が異なることがわかる。詳しいことは LLM に提案させて試しただけなので分かっていない。 ...

この記事を作った動機 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に対してポート転送を行う事を考えた。 ...

この記事を作った動機 最近、なんか公開鍵認証で鍵を登録したのにパスワードを求められたり、あるいは完全に特定の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 から設定を行った。 ...

この記事を作った動機 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 を操作できる。 ...

この記事を作った動機 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に仕向けるように設定してある。 説明の図 各ルーティング状況に関する説明 パケットがクライアント内部でループするイメージ 上記の図のような状況において、トラブルシュートでは以下のような厄介な挙動が見受けられた。 ...

この記事を作った動機 dhcpcd を使って管理している PC があるが、最近その挙動について何度も DHCP して IP を取得しては、新しいものを取得するという動作をして、他の PC が接続できなくなるほど、IP プールを勝手に枯渇させるということがあった。 特定インターフェースについて、そもそも DHCP とかで勝手に設定しないように指定したつもりであったが、機能していないことが分かった。動くまで調べ、機能しているように見えるところまで持ってきたのでそれについて記録する。ただしばらく動かしてみないと実際機能しているかわからないので、すぐわかる範囲での暫定的な記録となる。 設定方法 /etc/dhcpcd.confの最上位に、denyinterfaces [DHCPしないインターフェース名1] [DHCPしないインターフェース名2] ...というように記述する。基本的に DHCP したり静的に IP などを取得し設定するインターフェースの設定より上に書かないといけないっぽいことが今回調べて分かった。denyinterface getting ignored - Raspberry Pi Forums に書かれているように、dhcpcd は設定ファイル内の順次自体が大事なように見受けられる。設定例はブログに乗せるために...として省略している部分がある。 機能しているっぽい設定例 # cat /etc/dhcpcd.conf # A sample configuration for dhcpcd. # See dhcpcd.conf(5) for details. denyinterfaces eno2 enp0s20u11 ... interface eno1 static ip_address=192.168.1.x static routers=192.168.1.x static domain_name_servers=8.8.8.8 機能していないっぽい設定例 # cat /etc/dhcpcd.conf # A sample configuration for dhcpcd. # See dhcpcd.conf(5) for details. ... interface eno1 static ip_address=192.168.1.x static routers=192.168.1.x static domain_name_servers=8.8.8.8 ... denyinterfaces eno2 enp0s20u11 問題となっているPCなどの構成情報 関係のありそうな構成情報の列挙 Arch Linux Firewalld dhcpcd nftables SoftEther VPN 今回登場するPCの説明 ルータPC 家庭用ルータに置き換えて、nftables と kea によってルータ化した PC である。基本的な機能性は家庭用ルータと変わらないように意識し、USB NIC と内蔵 NIC の2つからなる。今回説明に出てくる、具体的なインターフェース名に紐づく物理 NIC とは関係ない。 ...

この記事を作った動機 named が名前解決時に参照する上流の DNS サーバのアクセスについて、SSL/TLSの暗号化を適用する設定をしたので、それについて記録したい。前提としてすでに named の設定が済んでいて通常の非暗号化状態の8.8.8.8#53などにおいて、動作していることを想定する。 設定方法 /etc/named.confを編集する tls tls-forwarder optionsブロックの外に記述するtls [設定名]からなる、TLS 設定である。 ca-file デフォルトでインストールされている証明書を使っている。 remote-hostname DoH 先の DNS サーバのホスト名を設定する。今回は Google DNS を使うので、dns.googleとした。 forwarders [DNSサーバのIP] port [DoH先のポート番号] tls [tls設定名]という形で設定する。通常の DoH ポート番号は853であり、HTTPSの443ではない。 設定例 tls tls-forwarder { ca-file "/etc/ssl/certs/ca-certificates.crt"; remote-hostname "dns.google"; }; ... options { ... forwarders { 8.8.8.8 port 853 tls tls-forwarder; 8.8.4.4 port 853 tls tls-forwarder; }; ... }; ... 動作確認 tcpdumpを使って確認する。以下は Google DNS が動いている様子を確認するために、8.8.8.8 の IP のホストの 853 番にアクセスしているか確認する例である。 ...

この記事を作った動機 Linux PC をルータ化するの話が長くなりすぎたので分けた。ここでは、簡易的にDHCPサーバを Linux 上で立てる方法について、簡易的にまとめることにする。難しいことはせず簡単に設定したので、不十分である可能性がある。今回は以下の項目について、今回立てるDHCPサーバでできることを目指した。 IPv4 で動作し、IPv6は今回取り扱わない デフォルトゲートウェイを設定する DNS サーバを設定する IPを新しく接続されたコンピュータに対して割り当てる また、Linux PC をルータ化する でマスカレードやらの設定が終わっていてすでにネットワークが機能している状態を想定している。ネットワークの構成については、今回テストに使ったものは以下のような構成である。192.168.0.0/24のネットワークについて、DHCPサーバを構成することを目指す。 手順 パッケージのインストール yay -Sy kea # sudo pacman -Sy kea /etc/kea/kea-dhcp4.conf設定をする # commentで示されるコメント部分は以下の例から取り除かないと多分動かない。また以下はほとんど Kea - ArchWiki の設定をコピーして私のテスト環境用に設定をちょっといじっただけである。 { "Dhcp4": { "interfaces-config": { "interfaces": [ "eno1" ], # DHCPサーバを動かしたい LAN 側のインターフェースを指定する "dhcp-socket-type": "raw" }, "subnet4": [ { "id": 1, "subnet": "192.168.0.0/24", # 管理するネットワークを指定する "pools": [ { "pool": "192.168.0.10 - 192.168.0.199" } ], # あたらしく接続されたクライアントに割り当てるIPの範囲を指定する "option-data": [ { "name": "routers", "data": "192.168.0.3" # デフォルトゲートウェイにしたいサーバを指定する }, { "name": "domain-name-servers", "data": "192.168.0.3" # DNS サーバを指定する } ] } ] } } kea-dhcp4サービスを有効化、起動する sudo systemctl enable --now kea-dhcp4 DHCPでネットワーク設定を自動取得できるか試す スイッチ越しにクライアントを接続し設定なしでインターネットなどが利用できることを確認する。 ...