IPv6

WAN6 は IPv6 アドレスを取得済みだが、OpenWrt でインターネット上の IPv6 に ping すると、直ちに次のエラーが返る： ping: sendto: Network unreachable 調査の結果、現場には mwan3 と一致するマーク付き unreachable ルールが1つ存在していた。そのルールを削除すると IPv6 が復旧した。このケースから、デフォルトルートが存在していても、実際のトラフィックがそれを使うとは限らないことが分かる。 本稿では実際の調査を記録する。インターネット上のソースアドレスはドキュメントの例示アドレスに置き換えている。デバイス名、ルール優先度、mark は自分のデバイスに合わせて確認すること。アンインストールコマンドは opkg を使用する OpenWrt 向けである。 デフォルトルートが存在しているのに、なぜまだ到達できないのか 最初の調査ではデフォルトルートが存在しないことを疑ったが、その後の出力にはソースアドレス条件付きのデフォルトルートがすでに表示されていた： default from 2001:db8:1234:5600::4 via fe80::1 dev eth1 proto static metric 512 pref medium default from 2001:db8:1234:5600::/64 via fe80::1 dev eth1 proto static metric 512 pref medium 調査中は一時的に通常のデフォルトルートも追加した： ip -6 route add default via fe80::1 dev eth1 metric 1024 それでも ping は直ちに Network unreachable を返した。この時点でデフォルトルートをさらに追加しても効果が已经没有なるため、実際の経路選択とポリシールールを確認する必要があった。 ...

Armbian に sing-box TUN をデプロイした後、少し分かりにくい問題が発生しました：IPv6 の ping は通るのに、auto_redirect を有効化すると IPv6 の HTTPS 接続がタイムアウトする的情况です。 调查结果、障害の原因は IPv6 の公網ルートやプロキシノードではなく、Linux のループバックインターフェース lo に ::1/128 アドレスが存在しないことでした。本稿では、その切り分け Processes .Ordinal and 修正方法を記録します。 環境 Linux：Armbian、ARM64、6.18 系カーネル sing-box：1.14.x ネットワーク管理：Netplan + NetworkManager 透過プロキシ：TUN、auto_route: true、auto_redirect: true IPv6：上位ネットワークから自動設定され、インターフェースにはグローバル IPv6 アドレスと RA によるデフォルトルートが設定済み プライバシーを保護するため、実際の公衆アドレス、MAC アドレス、ルーターアドレス、ドメイン名、およびカスタム内部ルーティングテーブル番号は省略しています。以下の例にある ULA アドレスとテスト対象は説明용です。 障害的现象 IPv6 HTTPS を直接テストします。 curl --noproxy '*' -6 -v --connect-timeout 5 \ --resolve 'cloudflare.com:443:[2606:4700::6810:85e5]' \ https://cloudflare.com/ sing-box を有効化した後： * Trying [2606:4700::6810:85e5]:443... * Connection timed out after 5002 milliseconds curl: (28) Connection timed out 比較テスト： ...