お知らせ

現在サイトのリニューアル作業中のため、表示が崩れているページが存在することがあります。

コネクタを傷めないための備忘録。

死ぬほど硬いのでなかなか抜けなかったり、挿したつもりが刺さっていなかったりする。

抜き方

こう刺さっている場合、手前の凹の出っ張り部分に爪楊枝を差し込み、てこの原理で持ち上げるとロックが外れるので、この状態で紐を真っすぐに引っ張る。

引っ張るだけで抜ける場合は別にやらなくてよい。

挿し方

まず刺さっているかどうかの確認方法。確認環境はUbuntu 24.04.3 LTS。

  1. ethtool enp1s0f0np0の出力に以下の内容が含まれることを確認
    Speed: Unknown!
    Duplex: Unknown! (255)
    Link detected: no
  2. 以下のコマンドでカーネルレベルで抜けていることを確認
    sudo dmesg | grep -i 'mlx5' | grep -i 'Cable unplugged'
    
  3. NICのコネクタのランプが点灯していなければ挿しなおす
2025/09/09 09:56 ネットワーク::IPv6

確認環境

NICはともに一つのみ。

  • Windows 11 Pro 24H2
  • Ubuntu 24.04.3 LTS

Windows

NICのIPv6アドレス(GUA)を取得する

コントロールパネルから取得
  1. コントロールパネル→ネットワークと共有センターを開く
  2. イーサネット→詳細を開く
  3. IPv6アドレスと書かれているのがGUA
コマンドプロンプトで取得

ipconfigを叩き、「IPv6 アドレス」と書かれているものがGUA

Powershellで取得
(ipconfig | Select-String -Pattern "IPv6 アドレス(?: .)+: (.+)").Matches.Groups[1].Value

Ubuntu

# perl版
ip -6 addr | grep 'global dynamic' | perl -ale '$F[1] =~ /^([^\/]+)/; print $1;'

# awk版
ip -6 addr | grep 'global dynamic' | awk '{ split($2, a, "/"); print a[1] }'

SPF+が取れないか、GE-PON F GE-PON-ONU タイプD<1>を分解してみた。もし取れたらSPF+ポートが有効活用できるうえ、邪魔なONUを撤去できるからだ。

ただまぁ結論としては無理だった。

結論としてはSFP+は入っておらず、光ファイバが基板に直付けされていた。

ONUに刺さっているLCケーブルをSFP+をはめ込んでSFP+コネクタのMACアドレスを書き換えれば、ONUとして動く可能性もあるが、色々問題がありそうなのでやめておこうと思う。

OCNバーチャルコネクト環境でIPv6サーバーをポート443で公開した時にやったことを派生させて更にIPv4にも対応させるプラン。

OCNバーチャルコネクトのIPoEでIPv4 over IPv6のMAP-E環境だと、IPv4ではWell-known portsが開けないが、PPPoEを使って取得したIPv4であれば開けるので、これとIPoE側のIPv6の併用でデュアルスタックでWell-known portsの開放を行い、サーバーを運用できるようにするのが目的だ。

確認環境

環境 内容
ISP OCN光
ISP契約 OCN 光 with フレッツ マンション・スーパーハイスピード 隼・プラン1・西日本
ISP接続方式 OCNバーチャルコネクト(IPoE, MAP-E)
RouterOS OpenWrt 24.10.0
ServerOS Ubuntu 24.04.3 LTS
HTTPD nginx 1.26.1
ドメインレジストラ Value Domain

今回の要件

やり方

サーバー側の準備

ufwではv4にも穴が開いている状態とする

  1. nginxの設定を開きIPv4向けにlisten 443 ssl;を追記して保存する
  2. nginxを再起動する

PPPoEインターフェースの作成

  1. SSHでOpenWrtに入る
  2. /etc/iproute2/rt_tablesを開き次のようにpppoeの行を追加、保存
    #
    # reserved values
    #
    128     prelocal
    255     local
    254     main
    253     default
    300     pppoe
    0       unspec
    #
    # local
    #
    #1      inr.ruhep
    
  3. 反映する
    • service network restart
  4. LuCIに入る
  5. Network→Interfacesを開く
  6. Add new interfaceから、Nameをwanppp、ProtocolをPPPoEとしたインターフェースを作成する
  7. General SettingsタブのDeviceにONUと疎通しているポートを指定し、PAP/CHAP usernameとPAP/CHAP passwordにISPの接続情報を入れる
  8. Advanced Settingsタブを開き、Use gateway metricを10、Override IPv4 routing tableをpppoe (300)にする
  9. Saveボタンを押して保存する
  10. wanインターフェースのEditを押す
  11. Advanced Settingsタブを開き、Use gateway metricを1にする
  12. Saveボタンを押して保存する

ファイアーウォールの作成

  1. 引き続きLuCI上で作業する
  2. Network→Firewallを開く
  3. ZonesのAddボタンを押す
  4. Nameをwan_pppoeにし、MasqueradingとMSS clampingにチェックを入れ、Covered networksでwanpppを選択し保存する
  5. lan⇒wanのゾーン設定のEditボタンを押す
  6. Allow forward to destination zones:にwan_pppoeを追加し、保存する
  7. Network→Interfacesを開く
  8. wanpppインターフェースのEditボタンを押す
  9. Firewall Settingsタブを開き、Create / Assign firewall-zoneにwan_pppoeが設定されていることを確認する。設定されていなかったら設定する

サーバーだけをPPPoEのIPv4通信の対象にする

  1. 引き続きLuCI上で作業する
  2. Network→Routingを開き、IPv4 Rulesタブを開く
  3. General SettingsタブのIncoming interfaceをlanに、SourceをサーバーのIPにする(例:192.168.1.5/32
  4. Advanced Settingsタブを開く
  5. Tableにpppoe (300)を設定し、保存する

NATを設定する

  1. 引き続きLuCI上で作業する
  2. Network→Firewallを開き、Port Forwardsタブを開く
  3. Addボタンを押す
  4. Nameに適当な名前を付け、Restrict to address familyをIPv4 only、Source zoneをwan_pppoe、External portを443、Internal IP addressを転送先のサーバーIP、Internal portを443にして、保存する
  5. 最後にこれまでの内容をSave & Applyする

疎通確認

  1. Network→Interfacesを開き、wanpppのIPv4を拾う
  2. ドメインレジストラの設定でAレコードにこれを登録
  3. 適当な外部サーバーからcurlを投げて中身が返ってきたらOK
    curl -4 -v https://example.com
    

IP変動対策にDDNSを設定する

/etc/hotplug.d/iface40-pppoeというファイルを755で作り、以下の内容を記述する。

#!/bin/sh

[ -n "$DEVICE" ] || exit 0
[ "$ACTION" = ifup ] || exit 0
[ "$INTERFACE" = wanppp ] || exit 0

vdpw=ここにDDNS更新用のパスワード
pppoeaddr=$(ip -4 addr show pppoe-wanppp | head -2 | tail -1 | awk '{print $2}')
logger -t "DDNS - PPPoE IP" $pppoeaddr
# hoge.example.comに対して更新リクエストを飛ばす例
logger -t "DDNS - DOMAIN: hoge" $(wget -O - "https://dyn.value-domain.com/cgi-bin/dyn.fcg?d=example.com&p=$vdpw$&h=hoge&i=$pppoeaddr")

# When making requests for multiple domains, wait 60 seconds between each request

このスクリプトはhotplugイベントが発生したときにファイルパス順に呼ばれるスクリプトらしい。

ひとまずデバイスでなく、インターフェイスが起動したときで、かつインターフェース名がwanpppの時に実行されるように組んである。

注意点として、このエンドポイントはレートリミットがシビアで、60秒以内に送ると503を返してくるようなので、複数回投げる場合はsleep 61とかして間隔をあけると良さそうだ。数が増えてきたらバリュードメインAPIのDNS設定APIを利用した方が早いだろう。

ただしこのAPIはTTLの制御に難があり、処理方法によっては3600秒に固定される罠が潜んでいるので注意が必要だ。

トラブルシュート

curlで「Connection refused」や「接続が拒絶されました」と出る

  • /var/log/ufw.logにログがあればufwで穴をあける(まずこれはない)
  • ファイアーウォールかルーティングかNATの設定のどこかがおかしいので見直す。

雑感:かなり苦しい

IPv4, v6のデュアルスタックに出来たのはいいが、幾つかの端末で繋いだところIPv4側に流れるケースがあった。メインのv6でなく、オプションのv4に行くという状況はやや残念だ。

構成的にもマルチセッションという微妙な形態で、v4とv6でインターフェースが二系統あり、セキュリティもNATとFWがあり、なかなか複雑な状態になってしまった。

Mastodonにおいてはv4IPのインスタンス(兵庫丼)との疎通はTLレベルでは出来たものの、画像が出なくなるという頭が痛い問題に出会った。

Misskey.ioからは疎通できず、こちらからはユーザープロフィールまではアクセスできるがフォローを押しても音沙汰がない。

結論としてはリッチなアプリケーション通信を伴う用途において、この方式は向かない気がした。恐れくこれはルーターより外側がIPoEとPPPoEで別系統になっている関係で、通信が混乱して上手くいかないパターンがあるのではないかと感じている。

DDNSも制約が厳しいし、Value DomainのAPIはあるだけマシではあるものの、超絶使いづらい問題もあり、この環境においてのデュアルスタックはあきらめようと思った。

まぁいい勉強にはなったので、そのうち何かに活かせるだろう、きっと。

R86S U1を買ってOpenWrtをインストールしてから今までずっとSPF+ポートが認識されていなかったので認識可能にした。

確認環境

  • R86S U1
  • OpenWrt 24.10.0

前提条件

  • インターネット環境があること

手順

  1. 認識されているかどうか確認し、何も出てこなければ次のステップへ
    dmesg | grep mlx4
    
  2. ドライバをインストール
    opkg install kmod-mlx4-core
    
  3. 再び認識されているかどうかを確認する
    dmesg | grep mlx4
    

なぜこれをしようと思ったか?

最初はeth0, eth1との排他制御かと考えていたが、RJ45とSPF+でNICが分離している構造上ありえないので、有効化できるはずだと思ったためやってみた。ポートはあればあるほど都合がいいし、RJ45が使えればSPF+に対応してない機器もつなげて便利なので。

有効化したSPF+ポートをLANに繋ぐ方法

機材不足で未検証だが、基本的にはOpenWrtでR86S U1のeth2ポートをLANに繋ぐ方法でLANに繋ぐものが出来ると思う。

参考までに有効化したSPF+ポートはeth3, eth4として認識されていることを確認している。これはdmesg | grep mlx4すると分かる。