Networking

DN42とは ルータの実験等のために作られた仮想NW（オーバレイネットワーク）のこと 公式ホーム wiki紹介 公式 github まあ正直、FRRとかって実際のインターネットではなかなか触る機会ないよね。 なんで、wireguardとかopenvpnとかで仮想ネットワーク作ってそこでFRRとか動かそうよって話だよな。 と言うことで勉強のためにDN42に参加しよう。実際にASも取得して見ちゃおうよ。楽しそうね。 色々メモ コレをみると、どうやらDN42のNWレンジが決まっていそうだぞ。 full dn42 ranges (172.20.0.0/14, fd00::/8) 172.20.0.14ということは、ホスト部が32-14=18bitなので、2^18つまり、262144このIPがこのネットワークには存在していそうだ。 すでにどこまで割り当てられているのだろう。調べたい。 それっぽい dn42 is a large, dynamic VPN that employs Internet technologies (BGP, whois database, DNS, etc.). Participants connect to each other using network tunnels (GRE, OpenVPN, WireGuard, Tinc, IPsec) and exchange routes using the Border Gateway Protocol. Network addresses are assigned in the 172.20.0.0/14 range with private AS numbers (see registry), as well as IPv6 addresses from the ULA range (fd00::/8) - see FAQ. ...

はじめに TailscaleはWireGuardベースのメッシュVPNを簡単に構築できる。 一方、通常はTailscale社のコントロールプレーンを利用する。 今回はオープンソースの Headscale をVPS上に構築し、端末の登録・管理を自分のサーバーで行う。 実際に構築した環境では、MacとiPhoneの接続に成功し、最初はDERPリレー経由だった通信が、その後IPv4・IPv6の直接P2P通信に切り替わった。 Headscaleは制御サーバーであり、通常の端末間データ通信を中継するVPNハブではない。直接接続できない場合はDERPリレーを利用する。なお、今回利用したDERPはHeadscale自身でホストしたものではない。 構成 項目 内容 サーバー Xserver VPS / Ubuntu 22.04.5 公開ドメイン headscale.ingenboy.com Headscale v0.28.0 Docker Docker Engine + Compose v2 HTTPS Nginx + Let’s Encrypt (Certbot) macOS Tailscale Homebrew版 v1.104.4 端末 MacBook Pro、iPhone Tailnet IP Mac 100.64.0.1、iPhone 100.64.0.2 通信経路は以下のとおり。 Mac / iPhone ── HTTPS ──> Nginx :443 ── HTTP ──> Headscale :8080 │ (制御・端末管理) └──────── WireGuard P2P ──────── 相手の端末 └─ P2P不可ならDERPリレー VPSでは既存のNginxが80/443番ポートを利用しているため、Headscaleコンテナの8080番ポートを ホストの127.0.0.1:18080 にだけ公開した。これならHeadscaleのHTTPポートをインターネットへ直接公開せずに済む。 ...

いつもnatの設定を忘れてしまうのでここに残しておきたい ss@kong:~$ sudo sysctl -w net.ipv4.ip_forward=1 && \ sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -d 192.168.10.0/24 -o enp9s0 -j MASQUERADE && \ sudo iptables -A FORWARD -i tun0 -o enp9s0 -s 10.8.0.0/24 -d 192.168.10.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT && \ sudo iptables -A FORWARD -i enp9s0 -o tun0 -s 192.168.10.0/24 -d 10.8.0.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT backupのトンネルの方はこっち rr@kong:~$ sudo sysctl -w net.ipv4.ip_forward=1 && sudo iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -d 192.168.10.0/24 -o enp9s0 -j MASQUERADE && sudo iptables -A FORWARD -i tun1 -o enp9s0 -s 10.10.0.0/24 -d 192.168.10.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT && sudo iptables -A FORWARD -i enp9s0 -o tun1 -s 192.168.10.0/24 -d 10.10.0.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT net.ipv4.ip_forward = 1 これ、一応意味書いておくか。 ...

背景 複数拠点（A, B, Cなど）を OpenVPN 経由で接続し、 **2系統のVPNトンネル（10.8.0.0/24 と 10.10.0.0/24）**を経由して経路冗長化したい。（openvpnサーバは独立した2マシン） そんなニーズから検証を始めました。 各拠点はそれぞれローカルLAN（例: 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24）を持ち、 それらを OSPF (FRRouting) で自動経路学習させて、 VPNトンネル越しに相互通信できるようにしたい、という構成です。 やりたかったこと OpenVPNで各拠点を接続（多拠点site-to-site VPN） FRR (OSPF) を使って動的ルーティング トンネルごとにコストを設定して経路選択 できれば route-nopull で手動ルーティングを制御 目標は「OpenVPNトンネルを2本走らせて、FRRで経路選択を任せる」ことでした。 これを実現するにあたり、色々とハマったので知見をまとめておこうと思います。 OpenVPNのルーティングの構造 OpenVPNはユーザランドで動作し、/dev/net/tun デバイスを通じて通信します。 Linuxカーネルはtunデバイスにパケットを出す そこから先は**OpenVPNプロセス（ユーザランド）**が受け取り、独自の内部ルーティングテーブルで転送を行う つまり、Linuxのルーティングテーブル（ip route）とは別世界で動いています。（ここが非常に大事です。openvpnサーバないのルーティングテーブルがちゃんと設定されていないと、クライアントから届いたパケットをどのクライアントに転送すればいいかがわかりません。ちなみに、openvpnのルーティングテーブルは/var/log/openvpn-status.logから確認可能です） push と route-nopull の関係 OpenVPNサーバはクライアントに対して push “route …” を送ることで、 クライアントのOSにもユーザランドにもルート情報を注入します。 一方、クライアント設定で route-nopull を有効にすると、 その push 情報をすべて拒否します。 frrでルーティングをさせたい場合には、route-nopullにしておかないと、0.0.0.0/1と128.0.0.1/1がOSのルーティングテーブルに登録され、すべてのパケットが特定のnicから出るように設定されてしまうので注意が必要（server側で**push “redirect-gateway def1 bypass-dhcp”**が入っている場合） FRR(OSPF)を組み合わせても解決しない理由 FRRでOSPFを走らせると、 VPNトンネル越しに相手拠点のLAN情報（例: 192.168.x.x/24）が学習されます。 これにより、OSレベルのルーティングテーブルは更新されます。 しかし！ OpenVPNサーバはそのOSルートを全く参照しません。 OpenVPNプロセスは独自に「このLANはどのクライアントの背後にあるか」を iroute で知っていなければ、パケットをどこに転送すべきか判断できません。 自分の場合は、openvpnサーバの/etc/openvpn/ccd以下に書くルーティングファイルの情報が間違っており、クライアント1 -> サーバはパケットが届いていたが、サーバがクライアント2宛のパケットをうまく転送できずdropしてしまっていたのが原因ですね。 ...

背景 自宅で動かしている Ollama + GenAI モデル（例えば phi4:14b）を、インターネット越しに使いたくなった。OpenVPN で穴を開けた上で、Nginx を使って自宅マシンへのプロキシを構成。 [ インターネット ] ↓ VPSのnginx (443) ↓ OpenVPN経由のプライベートIP (100.64.x.x) ↓ 自宅のGenAIサーバ (Ollama) 確かに便利ではあるが、「誰でも使える状態」にしてしまうのは少し怖くなった。 なので、Basic認証 を導入して、ユーザーとパスワードを知らないとアクセスできないようにした。 Nginx に Basic認証を追加する手順 認証用パスワードファイルを作成する まず、htpasswd コマンドを使って .htpasswd を作成。 sudo apt install apache2-utils # 初回のみ sudo htpasswd -c /etc/nginx/.ollama_htpasswd user1 2. Nginx の設定に認証を追加 /etc/nginx/nginx.conf server { listen 443 ssl; server_name hoge.ingenboy.com; ssl_certificate /etc/letsencrypt/live/ollama.ingenboy.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/ollama.ingenboy.com/privkey.pem; add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'Origin, Content-Type, Accept'; location / { # Basic 認証を有効にする auth_basic "Restricted Area"; auth_basic_user_file /etc/nginx/.ollama_htpasswd; proxy_pass http://100.64.1.41:11434; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } 3. 反映 sudo nginx -t && sudo systemctl reload nginx 4. 確認 curl -v https://ollama.ingenboy.com → 401 Unauthorized ...

背景 VPNを使ってトラフィックを中継する際、すべての通信をVPN経由にしたい──そんなときに現れるのが謎のルート 0.0.0.0/1 と 128.0.0.0/1。 一見すると「なんだこの中途半端なルートは？」と思われがちですが、これはOpenVPNが採用する非常に巧妙なテクニックです。本記事では、その目的、動作、実際のルーティングテーブルを紐解きながら、この仕組みの裏側を解説します。 ルーティングとは？ip route の基本 Linuxのルーティングテーブルは ip route で確認できます。このテーブルは、「どのIPアドレス宛の通信を、どのネットワークインターフェースから、どのゲートウェイ経由で送るか」という配送ルール一覧です。 $ ip route 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100 default via 192.168.1.1 dev eth0 この場合、 192.168.1.0/24 に属する通信は eth0 から直接送られる それ以外（つまりインターネットなど）は 192.168.1.1（ゲートウェイ）を経由して送られる パケットを受信すると、カーネルはルートテーブルの上から順に一致するエントリを探し、一番一致度が高い（= プレフィックスが長い）ルートに従って出力先を決定します。 つまり、 どの通信もまずは「最も具体的な（最長一致の）ルート」を優先する これがVPNのルーティング操作にも大きく関わってきます。 defaultルートとは？ default ルート（または 0.0.0.0/0）とは、どのルーティングエントリにも一致しない宛先のパケットをどこに送るかを決めるルールです。いわば「最後の砦」。 # 例: よくある default ルート default via 192.168.1.1 dev eth0 この例では、「どのルートにもマッチしなければ 192.168.1.1 に送れ」となっています。 通常、インターネットへの出口（ISPや上位ルータ）に向かうために使われます。 A (100.64.1.61) ↓ B (100.64.1.27) — VPN Client ↓ C (162.x.x.x) — VPN Server ↓ D (192.168.40.10) ↓ E (192.168.40.130) AからD・Eに通信を通したい。しかし同時に、Aのインターネット通信もVPN（サーバC）経由で出したい。 ...

#背景 VPNを使って拠点間通信（Site-to-Site Routing）を構成していると、 思ったようにパケットが届かないケースがあります。今回は以下の構成で発生した通信不通トラブルと、その解決方法を共有します。 🔧 ネットワーク構成 [A] 100.64.1.61 (100.64.1.0/22) ↓ [B] 100.64.1.27 (OpenVPNクライアント) → VPN → [C] OpenVPNサーバー → [D] 192.168.1.4 (192.168.1.0/24) 目標：AからD（192.168.1.4）への通信を通すこと。 ❗ 問題の症状 BからDには通信可能（VPN経由で192.168.1.4が見える） AからDへの通信は届かない しかしDからAへの通信（返信）は可能 🧠 原因 Aは 192.168.1.0/24 サブネットに属していないため、この宛先へのパケットをデフォルトゲートウェイに送ってしまっていた。 つまり、「行きのルート」が不在だったわけです。 ✅ 解決策：Aに静的ルートを追加 一時的にルートを追加する場合は以下のコマンドを実行： sudo ip route add 192.168.1.0/24 via 100.64.1.27 これで、Aは目的地 192.168.1.4 へのパケットをVPN中継ノードBに送るようになります。 UbuntuでNetplanを使用している場合、/etc/netplan/xxx.yaml を以下のように修正します： network: version: 2 renderer: networkd ethernets: enp3s0: dhcp4: false dhcp6: false addresses: [100.64.1.61/22] routes: - to: default via: 100.64.1.1 - to: 192.168.1.0/24 via: 100.64.1.27 nameservers: addresses: [100.64.1.1, 8.8.8.8, 8.8.4.4] ちなみに、netplan applyをやって疎通できなくなると困ることってありますよね。 そんな時のためにこれがあります ...

事始め site2site routingができるようになり、vpn_clientのネットワーク内のサーバとvpn_server間で通信ができるようになったわけだが。 今回、新たにもう一つvpn_clientをつなぎ、新しいローカルネットワークをこのVPNネットワークに参加させようとしたわけだ。 しかしこれがうまくいかない。 環境の整理 ネットワークA : 100.64.0.0/22 ネットワークB : 192.168.1.0/24 で、以下のような設定をvpn_serverに書き込むわけです。 port 1194 proto udp dev tun ca ca.crt cert server.crt key server.key dh dh.pem crl-verify crl.pem ifconfig-pool-persist ipp.txt server 10.8.0.0 255.255.255.0 # client側から通信させたい、server側のLanセグメントを指定 push "redirect-gateway def1 bypass-dhcp" push "route 10.8.0.0 255.255.255.0" push "dhcp-option DNS 8.8.8.8" # server側から通信させたい、client側のlanセグメントを指定 client-config-dir /etc/openvpn/ccd route 100.64.0.0 255.255.252.0 route 192.168.3.0 255.255.255.0 #fragment 1400 #mssfix tun-mtu 1400 client-to-client keepalive 10 120 comp-lzo user nobody group nogroup persist-key persist-tun status /var/log/openvpn-status.log log /var/log/openvpn.log log-append /var/log/openvpn.log verb 3 duplicate-cn これをやればA -> vpn_server B -> vpn_serverにつながると思っていた。 ...

事始め openVPN + nginxを使うことでhttpリクエストをリバースプロキシして自宅ネットワークから配信することはできるようになった。 しかしこれあくまでもL7レイヤーの話であり、http以外は無理だという話だ。 例えば、kafkaのトピックにデータを登録するにはhttpではなく独自のプロトコルを使う必要がある。つまり、nginxではだめだということ。 どうするかというと、L3レイヤーでトラフィックの宛先を変えてあげる必要がある。 関連 ovpnを使ってsite2site routing iptalbesを使ってポートフォワーディングする方法 # 10001番ポートのトラフィックを 100.64.1.61:10001 に転送 iptables -t nat -A PREROUTING -p tcp --dport 10001 -j DNAT --to-destination 100.64.1.61:10001 # フォワードを許可 iptables -A FORWARD -p tcp -d 100.64.1.61 --dport 10001 -j ACCEPT # 外部に返すためのMASQUERADE（オプション） iptables -t nat -A POSTROUTING -d 100.64.1.61 -p tcp --dport 10001 -j MASQUERADE という感じですね。 今更だけどopenvpnがフリーソフトなのって普通にやばい こちら

GSLBを自前で持つ方法 はい、まずインターネット上でドメインを持つ必要がありますよね。 ドメインの取得は、icannに登録された事業者しかできないんですよね。 だから、完全に自前は厳しいです。 ってことでいつも通りムームドメインとかでドメインを取得する必要がありますね。 で、このムームードメイン上でnsレコードを張って、その実態を自分のサーバにすればいいって話なんですよ。そうです。そこです。 そうすれば最終的にAレコードを張るのは自分で管理しているサーバになります。レコードを返すのも自分のサーバになるわけですね。 素晴らしいです。 nsレコードを張る方法として、二つあるんです。（おそらく） サブドメインとしてnsレコードを張る方法と、 そのドメインすべてにnsレコードを張る方法。 後者は、「取得したドメインで使用する ※上級者向け」ってところでやる必要がありそう。 ちなみに、完全に理解してしまったことが一つある。 dnsを登録すると、おそらく必ずnsレコードも登録される。 digではデフォルトでaレコードしか返さないようになっているが、例えばnsをつけるとnsレコードを返すようになります。 root@x162-43-53-234:~/MyFreshWebsite# dig ns ingenboy.com ; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> ns ingenboy.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15003 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;ingenboy.com. IN NS ;; ANSWER SECTION: ingenboy.com. 3600 IN NS dns01.muumuu-domain.com. ingenboy.com. 3600 IN NS dns02.muumuu-domain.com. ;; Query time: 20 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) ;; WHEN: Wed Jan 29 16:04:35 JST 2025 ;; MSG SIZE rcvd: 95 こんな感じです。これがムームードメインになっていますね？？はい、そうですね。 ...