Networking

背景 複数拠点（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 こんな感じです。これがムームードメインになっていますね？？はい、そうですね。 ...

事始め 会社ではL7プロキシの運用・開発をしている。 複数のEP（ドメイン）を持っている。 複数のドメインをひとつのL7プロキシ（単一のIP）でさばいている。 さて、これはいったいどの様に実現しているのか？というのが今回の議題。 IPアドレスはDNSによって単一のドメインと紐づけられる。と自分は認識していたが、これが誤りだった。 そして、自分は、会社に入るまでホストヘッダーという概念を全く分かっていなかった。 HTTPにはホストヘッダーというものがあり、これによって単一IP上に複数のドメインを保持することができるようになる。 そして、ポイントはやはり、HTTPはL7レイヤーであり、IPはL3レイヤーであるというところに落ち着くと思う。 前提 DNSでのIPアドレスとドメインの紐づけは一対一ではなく、一対多であった。ここがすごく大事なところでした。 そして、自分はホストヘッダーについて理解していなかった。 nginxを使ってバーチャルサーバを立てる chatgptから 単一の物理サーバー上で複数のウェブサイトやアプリケーションをホストするために使用される機能です。それぞれのバーチャルサーバーは、異なるドメイン名やサブドメインに対応して、個別に設定されたリソース（例えばウェブページやアプリケーションのファイル、SSL証明書、ログファイルなど）にアクセスを提供します。 Nginxでは、これらのバーチャルサーバーを「サーバーブロック」として設定ファイルに記述します。以下は、Nginxでのバーチャルサーバー設定の基本的な例です： server { listen 80; server_name example.com www.example.com; location / { root /var/www/example.com/html; index index.html index.htm; } error_page 404 /404.html; location = /404.html { root /var/www/example.com/html; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /var/www/example.com/html; } } ホストヘッダーの役割 chatgptより HTTPのホストヘッダーは、HTTPリクエストを送信する際に非常に重要な役割を果たします。このヘッダーは、クライアントがリクエストを送信する際に、どのホスト（ドメイン名またはIPアドレス）とポートに対してリクエストが意図されているかを指定するために使用されます。特に、一つのサーバーが複数のドメインをホスティングしている場合（仮想ホスティング）、ホストヘッダーがないとサーバーはリクエストがどのウェブサイトに対してなのか判断できません。 HTTP/1.1ではホストヘッダーは必須とされています。これは、HTTP/1.0と異なり、サーバーが複数のドメインをホストしている状況が一般的になったためです。リクエストにホストヘッダーが含まれていない場合、サーバーは400 Bad Requestのエラーを返すことが多いです。 DNSのAレコード 複数のサブドメインが同じサーバーのリソースを指す場合、それら全てに同じIPアドレスを割り当てることが一般的です。 例えば、次のように設定することができます： www.example.com → 192.0.2.1 mail.example.com → 192.0.2.1 ftp.example.com → 192.0.2.1 これらのサブドメイン全てに同じAレコードのIPアドレス（192.0.2.1）を指定することで、一つのサーバーが異なるサービス（ウェブ、メール、FTPなど）を提供することができます。これは特に、ホスティングサービスが複数のウェブサイトを単一の物理サーバーで管理する場合などに便利です。また、メンテナンスやアップグレードが必要な場合にも、一箇所で変更を行うだけで済むため効率的です。 ...

Real world httpに書いてあることを殴り書きしていきます 開発環境 の前に、lanのipアドレスを書いておきたいです。 100.64.1.27 : alpha 100.64.1.61 : evn 100.64.1.48 : delta (K8SクラスタへのGWです) deltaの役割 前に、DHCPサーバとルータを作成する記事を書いた。 こちらの記事だね。 で、deltaはDHCPサーバ兼ルータという立ち位置です。

LBのあれこれ 参考文献 https://qiita.com/masaozi3/items/838060d7339aef01bc2e