- 投稿日:
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 |
今回の要件
- OCNバーチャルコネクト環境でIPv6サーバーを公開した時にやったことに追加でIPv4も開通させる
- IPv4はPPPoEで取得できるものを使う
- サーバーマシン以外の端末に影響を与えない
やり方
サーバー側の準備
ufwではv4にも穴が開いている状態とする
- nginxの設定を開きIPv4向けに
listen 443 ssl;
を追記して保存する - nginxを再起動する
PPPoEインターフェースの作成
- SSHでOpenWrtに入る
/etc/iproute2/rt_tables
を開き次のようにpppoeの行を追加、保存# # reserved values # 128 prelocal 255 local 254 main 253 default 300 pppoe 0 unspec # # local # #1 inr.ruhep
- ルーターを再起動
reboot
- LuCIに入る
- Network→Interfacesを開く
- Add new interfaceから、Nameをwanppp、ProtocolをPPPoEとしたインターフェースを作成する
- General SettingsタブのDeviceにONUと疎通しているポートを指定し、PAP/CHAP usernameとPAP/CHAP passwordにISPの接続情報を入れる
- Advanced Settingsタブを開き、Use gateway metricを
10
、Override IPv4 routing tableをpppoe (300)
にする
- Saveボタンを押して保存する
- wanインターフェースのEditを押す
- Advanced Settingsタブを開き、Use gateway metricを
1
にする - Saveボタンを押して保存する
ファイアーウォールの作成
- 引き続きLuCI上で作業する
- Network→Firewallを開く
- ZonesのAddボタンを押す
- Nameを
wan_pppoe
にし、MasqueradingとMSS clampingにチェックを入れ、Covered networksでwanppp
を選択し保存する
- lan⇒wanのゾーン設定のEditボタンを押す
- Allow forward to destination zones:に
wan_pppoe
を追加し、保存する
- Network→Interfacesを開く
- wanpppインターフェースのEditボタンを押す
- Firewall Settingsタブを開き、Create / Assign firewall-zoneに
wan_pppoe
が設定されていることを確認する。設定されていなかったら設定する
サーバーだけをPPPoEのIPv4通信の対象にする
- 引き続きLuCI上で作業する
- Network→Routingを開き、IPv4 Rulesタブを開く
- General SettingsタブのIncoming interfaceを
lan
に、SourceをサーバーのIPにする
- Advanced Settingsタブを開く
- Tableに
pppoe (300)
を設定し、保存する
NATを設定する
- 引き続きLuCI上で作業する
- Network→Firewallを開き、Port Forwardsタブを開く
- Addボタンを押す
- Nameに適当な名前を付け、Restrict to address familyを
IPv4 only
、Source zoneをwan_pppoe
、External portを443
、Internal IP addressを転送先のサーバーIP、Internal portを443
にして、保存する
疎通確認
- Network→Interfacesを開き、wanpppのIPv4を拾う
- ドメインレジストラの設定でAレコードにこれを登録
- 適当な外部サーバーからcurlを投げて中身が返ってきたらOK
curl -4 -v https://example.com
IP変動対策にDDNSを設定する
/etc/hotplug.d/iface
に40-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レベルでは出来たものの、画像が出なくなるという頭が痛い問題に出会った。
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の設定
- nginxの設定を開き
listen [::]:443
を追加して再起動sudo service nginx restart
- サーバーマシンのIPv6を控える
ip -6 addr | grep 'global dynamic' | perl -ale '$F[1] =~ /^([^\/]+)/; print $1;'
- Value DomainのDNS設定を開きAAAAレコードに、先ほど控えたIPv6アドレスを登録する
ルーターのファイアウォールに穴をあける
- LuCIに入りNetwork→Firewall→Traffic Rulesを開く
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 穴をあけたIP以外が外部から疎通しないことを確認
- 穴をあけたIPが外部から疎通することを確認
備考
OCN光のIPoE(MAP-E)方式のIPはv4, v6ともに基本的に変動しない
結論から言うと引っ越しでもしない限り、v4が固定なのは知っていたが、v6も固定らしい。
v6のアドレスが変わる気配がないので、OCNのテクニカルサポートに聞いた結果、PPPoEは変動IPv4でルーター再起動時にIPが変わるが、IPoEであればIPv4, IPv6ともに半固定で通常は変わらないとのことだった。
つまりVLANやip6tablesがなくてもサーバーを公開できると言う事でOCN様々と言う事である。
IPv4アクセスをどうするか?
現状は2案検討している。
- どっかにペラのページを置いておき、「IPv6でアクセスしてください」みたいなお知らせページにしておく
- 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番ポートを開けるものとして進める。
ルーター側の設定
設定ファイルを編集する方法
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'
service firewall restart
でfirewallを再起動する
LuCIでやる方法
- Network→Firewall→Traffic Rules
Addから次の要領でルールを追加
General Settings項目 値 Name 適当な名前 Protcol TCPとUDPにチェック Source zone wan Destination zone lan Destination port 開けるポートをスペース区切り Advanced Settings
項目 値 Restrict to address family IPv6 only 保存してSave & Apply
サーバー側の設定
ufwやWindowsファイアーウォールの穴は開いているものとする。IPv6向けに穴が開いている必要があるが、通常、ufw add
やWindows ファイアーウォールの追加では勝手にv6の穴が開くはずなので意図的に塞がない限り追加時に開いていると思われる。
- nginxの設定を開き
listen [::]:80
を追加する - 外部から疎通確認して通れば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を経由して接続させるようにします。要するに手前にリバプロを生やしておくわけです。
前提
- Google Domainsを利用している
- ルートドメインを保有している
- AWSのアカウントがある
前準備
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}`);
});
手順
- CloudFrontを開く
- 「ディストリビューションを作成」
- 「オリジンドメイン」に
cdn.example.com
を設定 - 「プロトコル」を選ぶ
cdn.example.com
の「ポート」を設定する- 設定までスクロール
- 「代替ドメイン名 (CNAME) - オプション」で「項目を追加」し
service.example.com
を入力 - 「カスタムSSL証明書 - オプション」で「証明書をリクエスト」
- 「パブリック証明書をリクエスト」
- 「完全修飾ドメイン名」に
service.example.com
を入力し「リクエスト」 - 「証明書を表示」
- DNSレコードに「CNAME名」で「CNAME値」を追加
- 「保留中の検証」が終わるのを待つ
- 「カスタムSSL証明書 - オプション」で作成した「ACM証明書」を選択
- 「ディストリビューションを作成」
service.example.com
のDNSレコードをCNAMEにし、データを「ディストリビューションドメイン名」に変更https://service.example.com/
にアクセスできればOK
参考資料
トラブルシュート
ディストリビューションを削除したい
- ディストリビューションの一覧で消したいのにチェック入れて無効化
- しばらく待つ
- 消したいのにチェック入れて削除
後書き
副次的効果ですが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に繋がりました。やったー!
WSR-1166DHP4で利用できた!
IPv6対応ルーターも増えてきて値段もだいぶお手頃になってきたので、本当に繋がるかどうかもよくわからないまま買ったルーターでしたが、無事繋がりました。
上述のメールの案内に書かれている通りルーターを再起動したところネットが不通になり、ルーターのコンパネにアクセスしてみると回線識別画面になっていました。
ぼちぼち安くてそこそこ小さいのでおすすめです。アンテナ生えてないからコンパクト。
バッファロー11ac対応866+300Mbps無線LANルータ(親機単体)(ブラック) WSR-1166DHP4-BK
OCN バーチャルコネクト!
もしや…!と思ったらキタコレ!(漣風に
しかしコケる
ファッ!?
まぁネットワークにエラーはつきもの、リトライです。
IPv6接続成功!
リトライしたらフツーに行けました。良かった。
ちゃんとIPv6で繋げてます。因みにv4でも繋がります。v4のIPを振っている自宅サーバーにもv4環境からアクセスできました。出てるのはこのブログのIPなので隠す意味は特にないのですが、一応…w
契約情報もちゃんと更新されてます。
速度の変化
直近の測定値を見ると大分早くなったような気がします。劇的に早いというわけではないと思いますが、実用上は必要十分だと思います。流石に光で100Mbps切ってるのは問題なので…。(ADSLかよ