Jailで遊んでみる （FreeBSD 13.1R、2023/01/09） [FreeBSD]
FreeBSD jailで遊んでます。めっちゃ面白いです。
1点、jailを作るとネットワークアドレスが以下のように割り当てられます。（親と同じように/24にすることも可）
このとき、192.168.10.11のホストから192.168.10.12にpingをうつと、loopbackインタフェース経由で、かつ192.168.10.12 → 192.168.10.12という通信になるんですね。言われてみればルーティングテーブルもそうなってるし、ちょっと納得。
1点、jailを作るとネットワークアドレスが以下のように割り当てられます。（親と同じように/24にすることも可）
root@MyFreeBSD:~ # ifconfig
re0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=201b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,WOL_MAGIC>
ether 11:22:33:44:55:66
inet 192.168.10.11 netmask 0xffffff00 broadcast 192.168.10.255
inet 192.168.10.12 netmask 0xffffffff broadcast 192.168.10.12このとき、192.168.10.11のホストから192.168.10.12にpingをうつと、loopbackインタフェース経由で、かつ192.168.10.12 → 192.168.10.12という通信になるんですね。言われてみればルーティングテーブルもそうなってるし、ちょっと納得。
タグ：jail
有料VPN（NordVPN）のホワイトリスト設定 その4（2023/01/08） [Linux]
なお、ホワイトリストの機能不具合（？）がなぜ一般に広く報告されないかと言うと、たいていホームユースでは1サブネットしかないでしょうし、当然ホワイトリストの対象も地足の直収セグメントになると思われます。
その場合、明示ルーティングを設定しなくても、ルーティングテーブルには地足という自動生成のルーティングエントリが載りますので、a1の要件が自動的に満たされるからではないかと思ってます。
192.168.10.0/24 dev eno1 proto kernel scope link src 192.168.10.100 metric 100
■ip rule
a1.明示的ルーティングが設定されているもの → 通常（main）ルーティングテーブル参照
a2.「0xe1f1」とタグが付いていない通信 → VPN用ルーティングテーブル参照
a3.通常（main）ルーティングテーブル参照
その場合、明示ルーティングを設定しなくても、ルーティングテーブルには地足という自動生成のルーティングエントリが載りますので、a1の要件が自動的に満たされるからではないかと思ってます。
192.168.10.0/24 dev eno1 proto kernel scope link src 192.168.10.100 metric 100
■ip rule
a1.明示的ルーティングが設定されているもの → 通常（main）ルーティングテーブル参照
a2.「0xe1f1」とタグが付いていない通信 → VPN用ルーティングテーブル参照
a3.通常（main）ルーティングテーブル参照
有料VPN（NordVPN）のホワイトリスト設定 その3（2023/01/08） [Linux]
そもそもNordVPNがどうやってVPN通信を実現しているのか謎です。まあ私、Linux全く詳しくなく素人ですし。そんな変な作り込みはやってないとは思うのですが、、、
ここにほぼ答えが書いてありましたね。
https://ro-che.info/articles/2021-02-27-linux-routing
すごく簡単に説明すると、iptables、ip rule（ポリシルーティング）、ip route（宛先ルーティング）の複合的要素で構成されていて、原理原則として、ip rule → iptables → ip routeの順に評価されます。各エントリの中身も若いものから順に評価されていきます。
■ip rule
a1.明示的ルーティングが設定されているもの → 通常（main）ルーティングテーブル参照
a2.「0xe1f1」とタグが付いていない通信 → VPN用ルーティングテーブル参照
a3.通常（main）ルーティングテーブル参照
■iptables
b1. NordVPNのホワイトリスト通信を：許可
b2.任意の通信を「0xe1f1」とタグ付け（CONNMARK）
b3.任意の通信を許可
■ip route（main）
c1.通常ルーティングテーブル
■ip route（VPN用）
c2.nordlynxトンネルへ投げる
以下は私の理解および個人的な解釈ですが、VPN対象通信はどのように評価（マッチ）されるかと言うと、
a { a2 } → b { b2, b3 } → c { c2 } →
→ VPNカプセル化され再評価 → a { a3 } → b { b2, b3 } → c { c1 }
という動きに見えます。
一方、NordVPNホワイトリストの非VPN通信はどのように評価（マッチ）されるかと言うと、
a { a2 } → b { b1 } → c { c2 } → ？
となり、非VPN通信にも関わらず、nordlynxトンネルへ投げられてしまいます。実際にtcpdumpでパケットキャプチャをすると、非VPN通信がトンネルインタフェース側で観測されました。
この理解だと、非VPN通信は「a2」の評価をされてしまってはダメなので、「a1」でip ruleの評価を終わらせてあげる必要があるようです。つまり、
NordVPN ホワイトリスト通信用の明示的ルーティングが必要と言うこと
です。
というわけで、明示的ルーティングを設定すると、ちゃんとホワイトリストが機能するようになりました。
ここにほぼ答えが書いてありましたね。
https://ro-che.info/articles/2021-02-27-linux-routing
すごく簡単に説明すると、iptables、ip rule（ポリシルーティング）、ip route（宛先ルーティング）の複合的要素で構成されていて、原理原則として、ip rule → iptables → ip routeの順に評価されます。各エントリの中身も若いものから順に評価されていきます。
■ip rule
a1.明示的ルーティングが設定されているもの → 通常（main）ルーティングテーブル参照
a2.「0xe1f1」とタグが付いていない通信 → VPN用ルーティングテーブル参照
a3.通常（main）ルーティングテーブル参照
■iptables
b1. NordVPNのホワイトリスト通信を：許可
b2.任意の通信を「0xe1f1」とタグ付け（CONNMARK）
b3.任意の通信を許可
■ip route（main）
c1.通常ルーティングテーブル
■ip route（VPN用）
c2.nordlynxトンネルへ投げる
以下は私の理解および個人的な解釈ですが、VPN対象通信はどのように評価（マッチ）されるかと言うと、
a { a2 } → b { b2, b3 } → c { c2 } →
→ VPNカプセル化され再評価 → a { a3 } → b { b2, b3 } → c { c1 }
という動きに見えます。
一方、NordVPNホワイトリストの非VPN通信はどのように評価（マッチ）されるかと言うと、
a { a2 } → b { b1 } → c { c2 } → ？
となり、非VPN通信にも関わらず、nordlynxトンネルへ投げられてしまいます。実際にtcpdumpでパケットキャプチャをすると、非VPN通信がトンネルインタフェース側で観測されました。
この理解だと、非VPN通信は「a2」の評価をされてしまってはダメなので、「a1」でip ruleの評価を終わらせてあげる必要があるようです。つまり、
NordVPN ホワイトリスト通信用の明示的ルーティングが必要と言うこと
です。
というわけで、明示的ルーティングを設定すると、ちゃんとホワイトリストが機能するようになりました。
有料VPN（NordVPN）のホワイトリスト設定 その2（2023/01/08） [Linux]
そもそもNordVPNがどうやってVPN通信とホワイトリストを実現しているか、ですね。
Windowsだとブラックボックスですが、Linuxってわりと原始的な機能を組み合わせて実現しているイメージなので、ちゃんと解析すれば原因が分かるのではないでしょうか。
今ある材料としては、
んー、ここからどうやってホワイトリストを分離して、VPN通信を実現しているのか謎です。
Windowsだとブラックボックスですが、Linuxってわりと原始的な機能を組み合わせて実現しているイメージなので、ちゃんと解析すれば原因が分かるのではないでしょうか。
今ある材料としては、
root@Zorin16:~$ uname -a
Linux Zorin16 5.15.0-57-generic #63~20.04.1-Ubuntu SMP Wed Nov 30 13:40:16 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
root@Zorin16:~$ 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
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
altname enp3s0
inet 192.168.10.100/24 brd 192.168.10.255 scope global noprefixroute eno1
valid_lft forever preferred_lft forever
4: nordlynx: <POINTOPOINT,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.5.0.2/32 scope global nordlynx
valid_lft forever preferred_lft forever
root@Zorin16:~$ ip r
default via 192.168.10.254 dev eno1 proto static metric 20100
169.254.0.0/16 dev eno1 scope link metric 1000
192.168.10.0/24 dev eno1 proto kernel scope link src 192.168.10.100 metric 100
root@Zorin16:~$ iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere multiport dports 4011
ACCEPT all -- 192.168.20.0/24 anywhere /* nordvpn */
ACCEPT all -- anywhere anywhere connmark match 0xe1f1 /* nordvpn */
DROP all -- anywhere anywhere /* nordvpn */
ACCEPT udp -- anywhere anywhere multiport dports mdns
ACCEPT tcp -- anywhere anywhere multiport dports 4000
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 192.168.20.0/24 /* nordvpn */
CONNMARK all -- anywhere anywhere mark match 0xe1f1 /* nordvpn */ CONNMARK save
ACCEPT all -- anywhere anywhere connmark match 0xe1f1 /* nordvpn */
DROP all -- anywhere anywhere /* nordvpn */
root@Zorin16:~$ ip rule
0: from all lookup local
32764: from all lookup main suppress_prefixlength 0
32765: not from all fwmark 0xe1f1 lookup 205
32766: from all lookup main
32767: from all lookup defaultぐらいなんですよね。んー、ここからどうやってホワイトリストを分離して、VPN通信を実現しているのか謎です。
有料VPN（NordVPN）のホワイトリスト設定 その1（2023/01/07） [Linux]
NordVPNのバージョンは3.15.3です。
家庭内ネットワークをちょっと改造した結果、サブネットが2つに分かれてルーティングが必要になってしまいました。まあそれはルータのルーティング設定で問題ない訳ですが、ちょっとLinuxクライアント機の動きがおかしいのです。
NordVPNを動かすLinux子機と家庭内NASサーバが異なるセグメントになってしまったのですが、NordVPNにはホワイトリストの設定があり、VPN通信対象外にできるポートやサブネットを指定することができます。
この設定で192.168.100.0/24などと対象外セグメントを指定できるのですが、Linux子機と家庭内NASが相互に接続できなくなってしまいました。
今までは接続可能でした。
正確にはNordVPNのバージョンアップをして接続できなくなってしまったのか、サブネットを分けたことで接続できなくなってしまったのか分かりません。ただ、Webで検索しても不具合の話は見つからないので、おそらくもともとそういう状態だったのでしょう。
一つ言えるのは、サブネット分割する前は双方同一セグメントでしたし、そのあたりも関係しているのでしょうね。
家庭内ネットワークをちょっと改造した結果、サブネットが2つに分かれてルーティングが必要になってしまいました。まあそれはルータのルーティング設定で問題ない訳ですが、ちょっとLinuxクライアント機の動きがおかしいのです。
NordVPNを動かすLinux子機と家庭内NASサーバが異なるセグメントになってしまったのですが、NordVPNにはホワイトリストの設定があり、VPN通信対象外にできるポートやサブネットを指定することができます。
この設定で192.168.100.0/24などと対象外セグメントを指定できるのですが、Linux子機と家庭内NASが相互に接続できなくなってしまいました。
今までは接続可能でした。
正確にはNordVPNのバージョンアップをして接続できなくなってしまったのか、サブネットを分けたことで接続できなくなってしまったのか分かりません。ただ、Webで検索しても不具合の話は見つからないので、おそらくもともとそういう状態だったのでしょう。
一つ言えるのは、サブネット分割する前は双方同一セグメントでしたし、そのあたりも関係しているのでしょうね。
自宅無線APのリプレイス（2023/01/01） [ネットワーク機器]
うちの無線APは、Buffalo WSR-1166DHPを使ってます。
11ac対応だし、ちゃんと繋がるし何の不満もありません。ただ先日、駿河屋で中古のCDを買おうとしたら、「パソコン周辺機器」みたいなカテゴリーがあった訳です。興味本位で「ルーター」と検索してみたら、ブロードバンドルーターがいくつもヒットしました。
中古なのでちょっと怖い気持ちもありましたが、比較的新しいモデルがあるのと、さすがに駿河屋さんはちゃんとした会社なので、壊れていたり、そもそもパスワード紛失でログインできないようなガラクタはないだろうと思って、探してみました。
まあ、言ってWSR-1166DHPは2014年のモデルですからね。
壊れてはいませんが、さすがにレガシーに分類してもよい機器ですね。
調べてみると「WSR-2533DHP3-BK」が3500円ぐらいでありました。これは2020年の現行モデルで、新品の実売も8000円ぐらいです。もともとCDを買うのに一定金額以上買わないと送料を請求されますので、ちょうどいいやと思って買ってみました。
…と、届いたのが年末。
ちゃんと使えました。中古でもなんの問題もありません。
ただ、WSR-1166DHPもそうですが、CISCOルータでDHCPでIPアドレスを払い出そうとすると固定IPアドレスが払い出せない問題があります。これはWSR-2533DHP3-BKでも一緒でしたね。
PCなど一般端末はClient-IDの頭に「01」が付くのですが、Buffaloの無線APに関しては頭の「01」が付きません。これが原因で、一般端末と同じように固定IPアドレスを払い出そうとしてもうまくいきません。
答えを言ってしまうと、client-identifier指定ではなく、hardware-address指定でうまくいきます。
11ac対応だし、ちゃんと繋がるし何の不満もありません。ただ先日、駿河屋で中古のCDを買おうとしたら、「パソコン周辺機器」みたいなカテゴリーがあった訳です。興味本位で「ルーター」と検索してみたら、ブロードバンドルーターがいくつもヒットしました。
中古なのでちょっと怖い気持ちもありましたが、比較的新しいモデルがあるのと、さすがに駿河屋さんはちゃんとした会社なので、壊れていたり、そもそもパスワード紛失でログインできないようなガラクタはないだろうと思って、探してみました。
まあ、言ってWSR-1166DHPは2014年のモデルですからね。
壊れてはいませんが、さすがにレガシーに分類してもよい機器ですね。
調べてみると「WSR-2533DHP3-BK」が3500円ぐらいでありました。これは2020年の現行モデルで、新品の実売も8000円ぐらいです。もともとCDを買うのに一定金額以上買わないと送料を請求されますので、ちょうどいいやと思って買ってみました。
…と、届いたのが年末。
ちゃんと使えました。中古でもなんの問題もありません。
ただ、WSR-1166DHPもそうですが、CISCOルータでDHCPでIPアドレスを払い出そうとすると固定IPアドレスが払い出せない問題があります。これはWSR-2533DHP3-BKでも一緒でしたね。
PCなど一般端末はClient-IDの頭に「01」が付くのですが、Buffaloの無線APに関しては頭の「01」が付きません。これが原因で、一般端末と同じように固定IPアドレスを払い出そうとしてもうまくいきません。
Router#show ip dhcp binding
Bindings from all pools not associated with VRF:
IP address Client-ID/ Lease expiration Type
Hardware address/
User name
192.168.1.209 01aa.aaaa.aaaa.aa Jan 01 2023 09:48 PM Automatic
192.168.1.210 01bb.bbbb.bbbb.bb Jan 01 2023 10:24 PM Automatic
192.168.1.221 cccc.cccc.cccc Jan 01 2023 09:39 PM Automatic // Buffalo APエントリ答えを言ってしまうと、client-identifier指定ではなく、hardware-address指定でうまくいきます。
