Firewalld

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

この記事を作った動機 私が使っている家庭用ルータの挙動が怪しく、時々特定 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を見る限り設定できる模様である。 ...

この記事を作った動機 libvirtを使った仮想環境で、ファイヤウォールの設定をしないと、仮想マシンがネットにつながらないので、その記録をするだけ。 やり方 仮想マシンとのインタフェースを確認する ip a # ... # 8: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP group default qlen 1000 # link/ether 52:54:00:2d:fb:f7 brd ff:ff:ff:ff:ff:ff # inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 # valid_lft forever preferred_lft forever # ... ファイヤウォールを設定する インタフェース名が、virbr0 であることを想定する。 sudo firewall-cmd --permanent --direct --passthrough ipv4 -I FORWARD -i virbr0 -j ACCEPT sudo firewall-cmd --permanent --direct --passthrough ipv4 -I FORWARD -o virbr0 -j ACCEPT # sudo firewall-cmd --permanent --direct --passthrough ipv4 -I FORWARD -i [ネットワークインタフェース名] -j ACCEPT # sudo firewall-cmd --permanent --direct --passthrough ipv4 -I FORWARD -o [ネットワークインタフェース名] -j ACCEPT sudo systemctl restart firewalld 参考にしたサイトとか Firewall blocks internet on bridge in KVM virtual machine - English / Network/Internet - openSUSE Forums https://forums.opensuse.org/t/firewall-blocks-internet-on-bridge-in-kvm-virtual-machine/138737 (2025年8月2日)