お知らせ

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

OCNバーチャルコネクト環境でIPv6サーバーを公開した時にやったことを派生させて更に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. ルーターを再起動
    • reboot
  4. LuCIに入る
  5. Network→Interfacesを開く
  6. Add new interfaceから、Nameをwanppp、ProtocolをPPPoEとしたインターフェースを作成する
    paste-image-2025-8-22_21-17-30-262.png
  7. General SettingsタブのDeviceにONUと疎通しているポートを指定し、PAP/CHAP usernameとPAP/CHAP passwordにISPの接続情報を入れる
    paste-image-2025-8-22_21-21-59-731.png
  8. Advanced Settingsタブを開き、Use gateway metricを10、Override IPv4 routing tableをpppoe (300)にする
    paste-image-2025-8-22_21-32-25-150.png
  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を選択し保存する
    paste-image-2025-8-22_21-34-55-256.png
  5. lan⇒wanのゾーン設定のEditボタンを押す
  6. Allow forward to destination zones:にwan_pppoeを追加し、保存する
    paste-image-2025-8-22_21-38-35-472.png
  7. Network→Interfacesを開く
  8. wanpppインターフェースのEditボタンを押す
  9. Firewall Settingsタブを開き、Create / Assign firewall-zoneにwan_pppoeが設定されていることを確認する。設定されていなかったら設定する
    paste-image-2025-8-22_21-41-43-664.png

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

  1. 引き続きLuCI上で作業する
  2. Network→Routingを開き、IPv4 Rulesタブを開く
  3. General SettingsタブのIncoming interfaceをlanに、SourceをサーバーのIPにする
    paste-image-2025-8-22_21-45-47-319.png
  4. Advanced Settingsタブを開く
  5. Tableにpppoe (300)を設定し、保存する
    paste-image-2025-8-22_21-46-59-928.png

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にして、保存する
    paste-image-2025-8-22_21-59-16-456.png

疎通確認

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

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

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

#!/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レベルでは出来たものの、画像が出なくなるという頭が痛い問題に出会った。

paste-image-2025-8-23_2-35-19-483.png

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

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

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

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

本記事はここ昨今のOpenWrtセットアップシリーズの続きである。

OCNバーチャルコネクトのIPoEでIPv4 over IPv6のMAP-E環境だと、IPv4ではWell-known portsが開けない。しかし、IPv6であれば、理論上全部のポートが使えるはずで、それであればサーバーを建てられるのではないかと考えたので、やってみた記録。

確認環境

環境 内容
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

前提条件

IPv4環境下でのHTTPSアクセスが可能で、かつ以下のセットアップが終わっているものとする。

今回の要件

ルーターのファイアウォールでサーバーマシンのみ穴をあけ、それを塞ぐ。つまりNATの再現を行うことで、関係ない端末が攻撃されないようにする。

やり方

サーバーとDNSの設定

  1. nginxの設定を開きlisten [::]:443を追加して再起動
    1. sudo service nginx restart
  2. サーバーマシンのIPv6を控える
    ip -6 addr | grep 'global dynamic' | perl -ale '$F[1] =~ /^([^\/]+)/; print $1;'
    
  3. Value DomainのDNS設定を開きAAAAレコードに、先ほど控えたIPv6アドレスを登録する

ルーターのファイアウォールに穴をあける

  1. LuCIに入りNetwork→Firewall→Traffic Rulesを開く
  2. Addボタンを押し、次の要領で入力して保存
    General Settings

    項目
    Name 適当につける
    Protocol TCP│UDP
    Source zone wan
    Destination zone lan
    Destination address さっき控えたサーバーのv6IPアドレス
    Destination port 開けたいポートを半角スペース区切りで入れる

    Advanced Settings

    項目
    Restrict to address family IPv6 only
  3. 穴をあけたIP以外が外部から疎通しないことを確認

  4. 穴をあけたIPが外部から疎通することを確認

備考

OCN光のIPoE(MAP-E)方式のIPはv4, v6ともに基本的に変動しない

結論から言うと引っ越しでもしない限り、v4が固定なのは知っていたが、v6も固定らしい。

v6のアドレスが変わる気配がないので、OCNのテクニカルサポートに聞いた結果、PPPoEは変動IPv4でルーター再起動時にIPが変わるが、IPoEであればIPv4, IPv6ともに半固定で通常は変わらないとのことだった。

つまりVLANやip6tablesがなくてもサーバーを公開できると言う事でOCN様々と言う事である。

IPv4アクセスをどうするか?

現状は2案検討している。

  1. どっかにペラのページを置いておき、「IPv6でアクセスしてください」みたいなお知らせページにしておく
  2. SNSなどのOGP対策で、簡単なプロキシを組んでおき、OGPだけ出るようにしておく

2のケースだとレンサバにv6側サイトのOGP取得用のCGIを置いておくとか、v6側サイト更新時にOGP付きのペラのHTMLを置いておくなどが検討できると思う。

Cloudflare Tunnelを使わない理由

以前Claudflare CDNを使った時の悪印象を引きずっている部分が大きいが、基本的にオンプレミス至上主義だからというのが答えにはなる。

以前Claudflare CDNを使おうとするとドメインをClaudflare側に持ち込む必要があったのだが、この時にさくらのレンタルサーバーのSPFレコードが正常に扱ず、メールが使えない事態になった。また他にも、管理画面のUIがお世辞にもよくなく、言葉を選ばず言えばクソである点もある。

Cloudflare Tunnelでも同様のことになるかどうかは不明だが、前述の内容以外にも個人的にはCloudflareのWAF機能やhCAPTCHAがユーザーとして嫌いなのもあり、全体的にCloudflareに対してよい印象がないところが大きい。勿論、余計なレイヤーを増やすことによる運用コストの増大もあるので、実務的にもない方がいい。

VPNにリバプロを書けるのも検討したが、レガシーに縋っていても仕方がなく、今のところはIPv6に注力する方向にしようとしている。世界のv6以降に末端からでも貢献出来たらいいなくらいの気持ちでやっていくのだ。

関連記事

OCNバーチャルコネクトはIPv6を使う限り全ポート使えるはずなので、これを利用してサーバーを立てる。

確認環境

  • OpenWrt 24.10.0
  • OCNバーチャルコネクト
  • Windows 11 Pro 24H2
  • Ubuntu 22.04.5 LTS
  • nginx 1.26.1

手順

ルーター側だけでなくサーバー側も対応が必要。ファイアーウォールの穴をあけていても、IPv6でlistenしてないと受けられない。

ここでは一旦80番ポートを開けるものとして進める。

ルーター側の設定

設定ファイルを編集する方法
  1. vi /etc/config/firewallで以下の行を追加
    config rule
            option name 'Allow-Server-IPv6'
            option src 'wan'
            option dest 'lan'
            option proto 'tcp udp'
            option dest_port '80'
            option family 'ipv6'
            option target 'ACCEPT'
    
  2. service firewall restartでfirewallを再起動する
LuCIでやる方法
  1. Network→Firewall→Traffic Rules
  2. Addから次の要領でルールを追加
    General Settings

    項目
    Name 適当な名前
    Protcol TCPとUDPにチェック
    Source zone wan
    Destination zone lan
    Destination port 開けるポートをスペース区切り

    Advanced Settings

    項目
    Restrict to address family IPv6 only
  3. 保存してSave & Apply

サーバー側の設定

ufwやWindowsファイアーウォールの穴は開いているものとする。IPv6向けに穴が開いている必要があるが、通常、ufw addやWindows ファイアーウォールの追加では勝手にv6の穴が開くはずなので意図的に塞がない限り追加時に開いていると思われる。

  1. nginxの設定を開きlisten [::]:80を追加する
  2. 外部から疎通確認して通ればOK

備考

疎通検証に使える簡易サーバー

PHP

php -S "[::]:80"でIPv6向けの簡易サーバーをサクッと立てられるので疎通検証をするときに便利。

Node.js

http-serverだとhttp-server -p 80 -a "[::]"でいける。serveは未対応っぽい。

疎通確認に使えるcurl例

IPv6はURL形式が特殊なのでアドレス部分を[]で囲んだ書式で投げる。これはブラウザで確認する場合でも変わらない。

例:

curl -v "http://[aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhhh]:80/"

複数ポートの開き方

option dest_portに値を半角スペース区切りで追加すればよい。

例:

option dest_port '80 443 8080'

連番で開ける場合は公式ドキュメントによると、'1024:65535'のような書式にすれば、連番で開けられるようだ。

例:

option dest_port '8000:8999'

特定端末向けだけにポートを開けたい場合どうするか(未解決)

設定にoption dest_ipを追加し、これで制御できると思うがIPv6が変わる特性上、基本的に難しいと思う。勿論、端末側でIPの変更を検知しOpenWrtの設定を書き換えるバッチを組むなどは出来ると思うが、ややこしい。

VLANを使って隔離するとかできればよいのかもしれないが、具体案は検討できていない。

IPv6のOCNバーチャルコネクト環境ではwell-known portsが利用出来ずWebサーバーを公開するのに支障がありますが、今回はそれを乗り越えるための手法を紹介します。

自宅サーバーにhttps://service.example.com/のようにポート指定なしのサブドメインでアクセスできるようにするのがゴールです。

構成

自宅サーバーの手前にCDNを挟み、CDNを経由して接続させるようにします。要するに手前にリバプロを生やしておくわけです。

user-cloudfront-foreign_server.png

前提

前準備

DNS レコードに次のドメインを作っておく

用途 ドメイン レコード データ
CDN 用のドメイン cdn.example.com A サーバーの IP
公開用のドメイン service.example.com A サーバーの IP

自宅サーバーを公開可能な状態にする

叩き台程度ならserveを使うのが手っ取り早いですが、Node.jsでサーバー立てるのもありだと思います。今回は叩きなのでHTTPにしていますが本番運用するときはHTTPSにしましょう。

以下サンプル

const http = require('http');

const port = 12345;

const server = http.createServer((req, res) => {
    res.writeHead(200, { 'Content-Type': 'text/plain' });
    res.end('Hello world!');
    console.log(req.headers.host, req.socket.remoteAddress);
});

server.listen(port, () => {
    console.log(`Running at http://localhost:${port}`);
});

手順

  1. CloudFrontを開く
  2. 「ディストリビューションを作成」
  3. 「オリジンドメイン」にcdn.example.comを設定
  4. 「プロトコル」を選ぶ
  5. cdn.example.comの「ポート」を設定する
  6. 設定までスクロール
  7. 「代替ドメイン名 (CNAME) - オプション」で「項目を追加」しservice.example.comを入力
  8. 「カスタムSSL証明書 - オプション」で「証明書をリクエスト」
  9. 「パブリック証明書をリクエスト」
  10. 「完全修飾ドメイン名」にservice.example.comを入力し「リクエスト」
  11. 「証明書を表示」
  12. DNSレコードに「CNAME名」で「CNAME値」を追加
  13. 「保留中の検証」が終わるのを待つ
  14. 「カスタムSSL証明書 - オプション」で作成した「ACM証明書」を選択
  15. 「ディストリビューションを作成」
  16. service.example.comのDNSレコードをCNAMEにし、データを「ディストリビューションドメイン名」に変更
  17. https://service.example.com/にアクセスできればOK

参考資料

トラブルシュート

ディストリビューションを削除したい

  1. ディストリビューションの一覧で消したいのにチェック入れて無効化
  2. しばらく待つ
  3. 消したいのにチェック入れて削除

参考:ディストリビューションを削除する (docs.aws.amazon.com)

後書き

副次的効果ですがCDN挟んでキャッシュされてるお陰で連続アクセスしてもサーバーまでリクエスト来ないので感動しました。

CloudFrontには他にも様々な機能があるみたいなので活用できれば便利そうです。

ここ最近回線速度が異様に遅かったので早くなるかな?と思って申し込んでみました。結果としては早くなったと思います。

OCN は IPv6 標準対応

OCNは以下のプランではIPoEによるIPv6接続に標準対応しているとしています。

  • OCN光
  • OCN forドコモ光
  • OCN光withフレッツ

但し契約時期による条件あり

但し標準提供されるのは以下の条件に限られており、それ以外のユーザーは何かしらの手続きが必要である可能性があります。

  • 2017年7月25日以降にOCN光をご利用開始したお客さま
  • 2017年9月1日以降にOCN forドコモ光をご利用開始したお客さま
  • 2018年6月15日以降にOCN光withフレッツをご利用開始したお客さま

条件外のユーザー(ドコモ光)はどうすれば?

2017/08/31 以前に OCN for ドコモ光を利用開始したユーザーについて

OCN のお知らせ詳細なるページで「メールに記載のURLからフォームへアクセスしお手続きをお願いいたします。」と案内されていますが、2019/12/17現在このフォームは消滅しており利用することができません。

NTT 西ユーザーなら自分で NTT に申し込めば行ける?

OCN のお知らせ詳細では以下のような案内があるためNTT のサイトから申し込んでみることにしました。申込みから一時間ほどで利用できるようになります。書いてある通り無料です。

しかしこれだけではv6通信はできませんでした。やはりOCN側が対応している必要があるようですね。

IPoE 提供には NTT 西日本のフレッツ・v6 オプション(無料)が必要となるため、お客さまに代わり OCN が NTT 西日本へ代行申込をいたします。
サポートにメールをすると今でも申し込み手続きが可能

上述の通り、申し込みフォームは既にありません。何故なくなったのかは知りませんがきっとなにか深い大人の事情でもあるのでしょう。

しかし私はなんとしてでも無料で煩雑な手続きもせず追加機材も用意せずIPv6を使いたかったのでOCNのQ&Aを読み漁り、それっぽいワードでググりまくり、OCNメールを開き「【重要】OCN IPv6インターネット接続機能(IPoE)」の提供について」というメールを何度も読み返し「本件に関するお問い合わせ先」なるリンクに気がついたので、その先にあったお問い合わせフォームからメールに記載のフォームが使えないがIPoEによるIPv6接続を利用できないか?と問い合わせをしてみました。

サポートに問い合わせした結果、24hほどで以下のようなメールが届いたので適当に埋めて返信

そして IPv6 開通!

上記メールに返信をしてから48hほどで以下のようなメールが来たのでルーターを再起動したところ無事IPv6に繋がりました。やったー!

20220412031052.jpg

WSR-1166DHP4で利用できた!

IPv6対応ルーターも増えてきて値段もだいぶお手頃になってきたので、本当に繋がるかどうかもよくわからないまま買ったルーターでしたが、無事繋がりました。

上述のメールの案内に書かれている通りルーターを再起動したところネットが不通になり、ルーターのコンパネにアクセスしてみると回線識別画面になっていました。

20220412031136.jpg

ぼちぼち安くてそこそこ小さいのでおすすめです。アンテナ生えてないからコンパクト。

バッファロー11ac対応866+300Mbps無線LANルータ(親機単体)(ブラック) WSR-1166DHP4-BK

OCN バーチャルコネクト!

20220412031208.jpg
20220412031228.jpg

もしや…!と思ったらキタコレ!(漣風に

しかしコケる

ファッ!?

まぁネットワークにエラーはつきもの、リトライです。

20220412031148.jpg

IPv6接続成功!

リトライしたらフツーに行けました。良かった。

20220412031208.jpg
20220412031228.jpg

ちゃんとIPv6で繋げてます。因みにv4でも繋がります。v4のIPを振っている自宅サーバーにもv4環境からアクセスできました。出てるのはこのブログのIPなので隠す意味は特にないのですが、一応…w

20220412031242.jpg

契約情報もちゃんと更新されてます。

20220412031251.png

速度の変化

直近の測定値を見ると大分早くなったような気がします。劇的に早いというわけではないと思いますが、実用上は必要十分だと思います。流石に光で100Mbps切ってるのは問題なので…。(ADSLかよ