Networking

このページは、まだ未完成です。。。 nicotalk＆キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html （2024年5月16日） この記事を作った動機 まだ書いていない。 関連のある記事 Linux PC をルータ化する 使った画像とか File:Tux.svg - Wikimedia Commons (lewing@isc.tamu.edu Larry Ewing and The GIMP, CC0, via Wikimedia Commons) https://commons.wikimedia.org/wiki/File:Tux.svg (2026年2月26日) Windows 7(Vista) デフォルトのアイコン ルーター PCのアイコン Pi-hole – Network-wide Ad Blocking のロゴ https://pi-hole.net/ (2026年2月26日) 参考にしたサイトとか Pi-hole – Network-wide Ad Blocking https://pi-hole.net/ (2026年2月26日)

この記事を作った動機 私が使っている家庭用ルータの挙動が怪しく、時々特定 IP にアクセスできなくなったり、NAT 越えして VPN 接続する際に接続ができなかったりするときがあるなど、安定性に欠けることがあることが分かった。 そこで、使っていないミニ PC に Linux 環境をインストールし、そこで何かしら設定をすれば、ルータ化できるのではないかという話が、Gemini にいろいろ投げつけると出てきたので、実際にそれができるのか検証も兼ねて、自分で設定し試してみた。 そもそも私自身がネットワークについて授業でレポートを作るためなど、単位を取るために軽く触った程度で、実際に自分で使うために運用して体験してみたり、試す実戦経験に疎いところがある。その点も兼ねて今回実際に検証してみて、難しいと思うことに関しては自分なりにノートを取ってみることにしたというのが、この記事を書いた動機である。 今回の設定がうまくいかない場合、再起動後にルータとして機能しない に書いているように、nftables自体がFirewalldの動作に干渉しているかもしれないので確認する。 設定のまとめ 今回の話のネットワーク構成の前提 いきなり本番環境で動かすのはリスクが高すぎるので、既存の家庭用ルータが形成するLANをWANとして見立てて、そこにぶら下げるようにして今回ルータ化するPCを配置し、実際に動作するか検証する形にした。 設定の全体像 sudo firewall-cmd --list-all --zone=LAN; sudo firewall-cmd --list-all --zone=WAN # LAN (active) # target: ACCEPT # ingress-priority: 0 # egress-priority: 0 # icmp-block-inversion: no # interfaces: [LAN側のインターフェース名] # sources: # services: mdns ssh # ports: 3389/tcp 3389/udp # protocols: # forward: yes # masquerade: no # forward-ports: # source-ports: # icmp-blocks: # rich rules: # WAN (active) # target: DROP # ingress-priority: 0 # egress-priority: 0 # icmp-block-inversion: no # interfaces: [WAN側のインターフェース名] # sources: # services: # ports: # protocols: # forward: no # masquerade: yes # forward-ports: # source-ports: # icmp-blocks: # rich rules: sudo sysctl net.ipv4.ip_forward # net.ipv4.ip_forward = 1 ip a # 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 # link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 # inet 127.0.0.1/8 scope host lo # valid_lft forever preferred_lft forever # inet6 ::1/128 scope host noprefixroute # valid_lft forever preferred_lft forever # # 2: [LAN側のインターフェース名]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 # link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff # inet 192.168.0.3/24 scope global [LAN側のインターフェース名] # valid_lft forever preferred_lft forever # inet6 fe80::725a:fff:fe3f:8c93/64 scope link proto kernel_ll # valid_lft forever preferred_lft forever # ... # 4: [WAN側のインターフェース名]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default # qlen 1000 # link/ether yy:yy:yy:yy:yy:yy brd ff:ff:ff:ff:ff:ff # inet 192.168.1.19/24 brd 192.168.1.255 scope global [WAN側のインターフェース名] # valid_lft forever preferred_lft forever # inet6 fe80::3695:dbff:fe2b:1a6d/64 scope link proto kernel_ll # valid_lft forever preferred_lft forever インストールするパッケージ yay -S firewalld net-tools dhclient 具体的なコマンド操作 # 起動時にfirewalldが起動するようにする sudo systemctl enable --now firewalld # すでに有効化していたり、一時的に立ち上げた状態にしたい場合 # sudo systemctl start firewalld # NetworkManagerは手動でfirewalldに設定した項目を上書きする可能性があるので使わない # sudo systemctl disable NetworkManager # public ゾーンに紐づけられているインターフェースを確認し引きはがす sudo firewall-cmd --list-all sudo firewall-cmd --remove-interface=[publicに紐づけられているインターフェース名] --permanent # 新しいゾーン LAN と WAN を作成し、 # LAN側にしてスイッチに接続するインターフェースと、WAN側にして上流の外部ネットワークに接続するインターフェースを紐づける sudo firewall-cmd --new-zone=LAN --permanent sudo firewall-cmd --new-zone=WAN --permanent sudo firewall-cmd --zone=LAN --add-interface=[LAN側のインターフェース名] --permanent sudo firewall-cmd --zone=WAN --add-interface=[WAN側のインターフェース名] --permanent # 各ゾーンのパケットの扱いを設定 sudo firewall-cmd --zone=LAN --set-target=ACCEPT --permanent sudo firewall-cmd --zone=WAN --set-target=DROP --permanent # LANゾーンにおいて転送、WANゾーンにおいてマスカレード設定の有効化 firewall-cmd --zone=LAN --add-forward --permanent firewall-cmd --zone=WAN --add-masquerade --permanent # 設定を反映 sudo systemctl restart firewalld Systemd で起動時に実行する内容 (root,initRouter.sh) ※ 保存してスクリプトを作成し終わったら、chmod +x [filename]で実行権限を付与することを忘れないこと。 ...

この記事を作った動機 LinuxクライアントからWindows側にRDP接続などをするとき、いちいちIPアドレスを直接入力しているのは気持ち悪いと思っていた。今まではそれでいいやと放置していたが、最近いい加減どうにかしようということで、具体的な解決を試みようと思って、案の定手間取ったので記録する。 具体的には、mDNSを使って、Linuxクライアント側から、WindowsクライアントのプライベートIPアドレスを割り出したいということをしていた。基本的には以下のポイントがあった。 ファイアウォールの設定で、mDNSを受け付けるようになっているか？ Linuxクライアントに必要なパッケージがインストールされ、必要なデーモンが動いているか？ 接続先対象としてのWindows側のホスト名は間違っていないか？ Linux側から名前解決を試みるとき、.localのTLDをつけ忘れていないか？ 環境 前提としては、個人的なLAN内での利用を想定している。今回は、パブリックネットワーク向けのセキュリティー重視という観点では書いていない。 また重要な前提として、接続先と接続元は、同じプライベートネットワークに属していることとする。 接続先 (Windows) Windows 11 24H2 を使っている 接続元 (Linux) NetworkManger を使っている systemd-resolved を使っていない、無効にしている GNOME 環境 arch linux 環境 仮定 今回は説明のために以下の仮定をしている。Linux側に関しては、/etc/hostnameにすでに適切なホスト名が設定されているという前提である。 Windows側 ホスト名: WinHost IPアドレス 192.168.1.33 Linux側 ホスト名: LinuxHost IPアドレス 192.168.1.55 設定手順 Windows側 (接続される側、mDNSで名前解決される側) ファイアウォールの設定を確認する 今回はmDNSだけでなく、そもそも接続されているか確認するために、pingも通るように設定する。 ネットワーク探索が無効になっていないか確認する Linux側 (接続を試みる側、mDNSで名前解決をしようとする側) パッケージのインストール yay -S avahi nss-mdns # pacman -S avahi nss-mdns デーモンの有効化 sudo systemctl enable --now avahi-daemon.service /etc/nsswitch.confを設定する 以下はAvahi - ArchWikiを参考に設定した一部の例である。今回は IPv4 を対象として、mdns4_minimalを指定した。試してはいないが、mdns_minimal、mdns、mdns6_minimal(IPv6)としても、Avahi - ArchWikiを見る限り設定できる模様である。 ...

このページは、まだ未完成です。。。 nicotalk＆キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html （2024年5月16日） この記事を作った動機 最近 Microsoft 社のネイティブの RDP クライアントや MS Store で配布されている純正 RDP クライアントや Windows に標準搭載されている RDP クライアントプログラムに不満があるというのがあった。 ちょっと前までは、Windows 環境では標準搭載されている RDP クライアントプログラムを使っていた。Windows に対してのRDP接続では自動的にクライアントとRDP接続先が、画面の解像度やスケーリング情報をやり取りしていたため 問題なしとしていたし、 RDP 接続先としての Linux 環境側も X11 の設定を使い、手動で解像度を変えることで対応していて、それでいったん良しとしていた。 しかし、Linux 環境に RDP 接続する場合において、GNOME 49 の本格的な X11 環境が廃止があり、簡単に画面の解像度を変更できなくなったため、そうとは行かなくなった。 それで、私の環境でも NVIDIA 製 GPU を使っていても、Wayland にしないと、更新後 gdm サービスが立ち上がらないということになってしまったため、NVIDIA が提供する X11 上で動作する設定画面が使えなくなった。EDID という、ディスプレイの情報をローレベルで強引に書き換えるなどしなければ、自由な解像度で RDP 接続先としての Linux 環境が使えなくなってしまった。 こうして、いろんな我慢が積み重なり、そろそろいい加減何とかしようと思って、 Guacamole を見つけ、試していたというのがあった。私の今の理解だと、Guacamole とは、apache から出ている Tomcat 上で動作し、ブラウザでアクセスすることで使うことができる RDP VNC その他もろもろのクライアントとして使うことができる Web アプリという認識である。 とりあえず現状ではすべてについて記録を一気にとるのは現実的ではなかったので、とりあえず、書きやすいところや、記録に残しておきたいところを優先的に先に記録を残してみることにした。 Guacamoleが動作している様子 ログイン画面 接続先選択画面 動いている様子 ...

この記事を作った動機 ある時、ChatGPT を使っていて、うまく設定が読み込めないという時があったときにそれについて調べてみたら、DNS 周りのキャッシュがおかしい説というのがあり、named のキャッシュを消そうとしてやり方がわからなかったので、自分用に記録するだけ。 設定する 少なくとも私の環境では、最初から rndc コマンドは使えるようになっておらず、設定が必要だった。rndc-confgen を使うことで、コンフィグは生成できるので、出てきたものをそれぞれ、named.conf と rndc.conf に貼り付ければとりあえずは動いた。 まだ設定がないときの rndc コマンドの挙動 sudo rndc status # rndc: no server specified and no default rndc status -s localhost # rndc: no server specified and no default rndc-confgen で設定を生成する # sudo rndc-confgen [sudo] share のパスワード: # Start of rndc.conf key "rndc-key" { algorithm hmac-sha256; secret "secretString"; }; options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; }; # End of rndc.conf # Use with the following in named.conf, adjusting the allow list as needed: # key "rndc-key" { # algorithm hmac-sha256; # secret "secretString"; # }; # # controls { # inet 127.0.0.1 port 953 # allow { 127.0.0.1; } keys { "rndc-key"; }; # }; # End of named.conf 設定を貼り付ける /etc/rndc.conf (なければ作成する) key "rndc-key" { algorithm hmac-sha256; secret "secretString"; }; options { default-key "rndc-key"; default-server 127.0.0.1; default-port 953; }; /etc/named.conf (追記する) key "rndc-key" { algorithm hmac-sha256; secret "secretString"; }; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; }; }; systemd で named を再起動する sudo systemctl restart named キャッシュを削除する sudo rndc flush 参考にしたサイトとか rndc 鍵 (rndc.key) の作成 - hijiri-0404’s blog https://hijiri0404.hatenablog.com/entry/2015/03/05/000245 (2025年10月2日) domain name system - DNS on Redhat - rdnc: no server specified and no default - Server Fault https://serverfault.com/questions/231749/dns-on-redhat-rdnc-no-server-specified-and-no-default (2025年10月2日) BIND のキャッシュを消去する (CentOS 5.5): Linux の使い方 https://ez-net.jp/article/28/KPrxdINA/6oV8mNixA7et/ (2025年10月2日)

この記事を作った動機 なんか、キャリアネットワークをデザリングを経由して使って、さらにVPN接続を介した通信のうち、HTTPとSSHだけが繋がらないということがあった。 それで対策としてMTUを小さく設定することをしたのでそのことを記録するだけ。 ちなみになぜMTUが大きすぎるとだめなのかわかっていないが、多分大きすぎるサイズのパケットはなんとなくどこかで落とされている気がする。 VPNや多段NAT構成だとルーティングされているうちに、ヘッダが積み重なって、ネットワークのパケットのサイズが大きくなりすぎたりするのかもしれない。 ネットワークの構成 サーバーやLAN内のルータ マンションのNAT キャリアネットワーク スマホ（デザリング） PCとか 状況 A -> キャリアネットワークのときで、直接マンションのNATを超えたとき B -> キャリアネットワークのときで、VPSなどの固定IPを持ったサーバーを経由したとき C -> 光回線などの固定回線で、直接マンションのNATを超えたときと、VPSなどの固定IPを持ったサーバーを経由したときの両方について含まれる 状況別の表 A B C Ping ✅ OK ✅ OK ✅ OK SMB(ファイル共有) ✅ OK 確かめていない ✅ OK DNS ✅ OK ✅ OK ✅ OK SSH ❌ Failed ✅ OK ✅ OK HTTP(HTTPS) ❌ Failed ❌ Failed ✅ OK MTU設定方法(要管理者権限) デフォルトで設定されているMTUのサイズ 1500 今回うまくいったMTUのサイズ 1000 一時的な設定(とりあえずすぐ設定したいとき) ip コマンドを使う sudo ip link set dev [ネットワークアダプタ名] mtu [設定したいMTUサイズ] ip コマンドを使う例 # 例 # ip a # ... # 4: vpn_vpnhome: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000 # link/ether 5e:76:29:d3:1b:85 brd ff:ff:ff:ff:ff:ff # inet 192.168.1.203/24 scope global vpn_vpnhome # valid_lft forever preferred_lft forever # sudo ip link set dev vpn_vpnhome mtu 1000 # ip a # ... # 4: vpn_vpnhome: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1000 qdisc fq_codel state UNKNOWN group default qlen 1000 # link/ether 5e:76:29:d3:1b:85 brd ff:ff:ff:ff:ff:ff # inet 192.168.1.203/24 scope global vpn_vpnhome # valid_lft forever preferred_lft forever 永続化設定(networkmanagerを使っているとき) sudo nmcli connection modify [ネットワークアダプタ名] 802-3-ethernet.mtu [設定したいMTUサイズ] # vpn_vpnhome の MTU サイズを 1000 に変更 # sudo nmcli connection modify vpn_vpnhome 802-3-ethernet.mtu 1000 追記 2025年8月1日 なんか何となくブックマークをあさっていたら、TU，MSS の計算と最適化の便利な手段をまとめるというサイトにたどり着いた。それで、さらにリンクをたどって、Visual packet size calculator — Daniil Baturinというところに行くと、こんな記述が目に止まった。 ...