IPoE/PPPoE併用時(など)に一つの端末から同時に複数の接続経路を利用する

概要

先日公開した当ブログの記事フレッツ光関連の設定について(ドコモ光、ひかり電話、IPoE/IPv4 over IPv6とPPPoEの併用など) - turgenev’s blogや、その他の多くの記事にもある通り、光回線においては適切なプロバイダを選べば、あるいは複数のプロバイダと契約するなどすれば、混雑時でも速度が安定しているIPoE (IPv4 over IPv6)方式と、速度は劣るもののポート開放が自由に行えるPPPoE方式という2通りの方法(接続経路)でインターネットを利用することができるようになります。

この状態は、物理的に配線をつなぎ替えたりWi-FiSSIDを切り替えたりしなくても接続端末側でIPやデフォルトゲートウェイを変更することで両方の経路を利用することができるという意味では両方の経路を「併用」することが可能になっていますが、IPやゲートウェイの変更を行うと接続が一時的に切断され、それを境に一方から他方へと完全に切り替わるため、単一の端末から両方の経路を真に「同時」に利用することはできません。

これを解決しようというのが今回の記事です。この部分に関して解説しているサイトはあまりないのですが、応用すれば結構面白いことができそうで、やる価値はあると思います。例えば、PPPoE経由でサーバーとして公開したいマシンでもブラウザではIPoEでインターネットが使えますし、指定したドメインへの通信のみPPPoE経由にするプロキシサーバーを立ててスマホから利用するといったことも(多分)可能になるはずです。

補足

実際によく利用されるであろう例としてIPoEとPPPoEの併用を挙げていますが、この記事の方法はインターネット側に出ていく複数の経路を同時利用したい全ての場合に応用可能です。例えばPPPoE接続を複数併用する場合でも、ホームルーター光回線を併用する場合でもやることは全く同じです。また接続先が3つ以上あっても同様のやり方で対応できます。

宛先IPによる振り分け

まず基本として、宛先IPによって使用する経路を変更することができます。これはとても容易で、普通のルーターには「静的ルーティング設定」のような項目があるので、そこで宛先IPを指定して、該当するものを別のルーターに丸投げすることができます。例えば、端末側ではIPoE用のルーターデフォルトゲートウェイにしておいて、IPoE用のルーターの静的ルーティング設定でxxx.xxx.xxx.xxxへの通信を全てPPPoE用ルーターに丸投げするようにすれば、端末からxxx.xxx.xxx.xxxへの通信は全てPPPoE経由になります。

また、これはWindowsLinuxのルーティング設定からも可能です。これも多くの解説があるので調べてください。

しかし、これは通常はLAN間の通信に使われる方法で、インターネットへの通信に用いるには欠点があります。というのも、一般にはサイト(ドメイン)が同じでもIPが常に一定であるとは限らず、そうすると目的のドメインだけに確実にPPPoE経由でアクセスすることは難しくなります。

また、一つのIPにIPoEとPPPoEを経由して同時にアクセスすることもこの方法ではできません。

解決策: 一つの端末にIPアドレスを2個割り当てる

そこで、解決策として、一つの接続端末に2個のIPアドレスを割り当てた上で、ポリシーベースルーティングという機能により使うIPアドレスによって使う経路を変えるという方法を取ります。例えば、一つのPCが192.168.1.8と192.168.1.9という2つのIPアドレスを持つようにして、192.168.1.8からインターネット側に行くときはIPoE用のルーター、192.168.1.9側から行くときはPPPoE用のルーターを使うというように設定することができます。

こうすれば、(詳細な設定は後で述べますが)特定のドメインにむけて確実にIPoEあるいはPPPoE経由でアクセスできますし、一つのドメインに同時にIPoEとPPPoEで接続することも可能です。また、ポリシーベースルーティングでは、プロトコルやポート番号を指定した通信の振り分けも可能になります。

ちなみに、「ポリシーベースルーティング」の厳密な定義(どこまでできれば「ポリシーベースルーティング」といえるのか)はいまいちよく理解してないです。

必要なもの/不要なもの

上記の「一つの接続端末に2個のIPアドレスを割り当てる」という機能は、WindowsLinuxにはありますが、(root化したAndroidなどを除く)スマホやゲーム機などにはありません。また、「ポリシーベースルーティング」の機能は、(後述しますが)Windowsには無いようです。従ってこの記事ではLinuxUbuntu)を使用します。実質的にはipコマンドを使うだけなので、LinuxであればRHEL系あるいはそれ以外でも同様にできると思います。Macはわかりません。あとroot権限は必要です。

ただ、先ほど述べたように、Linuxほどの機能を持たない端末であっても、プロキシが使えれば、(そしてもちろん、正しく設定したLinuxが起動していれば、)Linuxを経由することで両方の接続を同時に利用することが可能です。

この記事では接続端末側のLinuxが「ポリシーベースルーティング」を担当しますが、これをルーターにやらせるという方法もあります。しかし、これはどのルーターにも備わっている機能ではなく、数万円するような業務用ルーターYAMAHA製など)が必要になる可能性があります。そのかわりに、「一つの接続端末に2個のIPアドレスを割り当てる」ことはできるが「ポリシーベースルーティング」はできないというような端末(例えばWindows)しかない場合でも本記事の内容が実現できるようになります(多分)。本記事では扱いませんが、対応したルーターがあるならこちらを採用するのも良いでしょう。

また、他の記事ではこの記事と同じ目的で物理的にネットワークカード(NIC)をPCに増設しているものもありますが、この記事のやり方であれば必要ありません。

以上をまとめると、この記事のやり方はroot権限が使えるLinuxUbuntu)を必要としますが、高価なルーターや追加の物理NICは不要です。ルーターNICは数千-数万円しますが、LinuxWindows PCさえあればタダで入れられますからコストは安く済みます。

IPアドレスの追加

ではまず、IPアドレスの追加を行います。

現時点の環境は、192.168.1.1がDHCPサーバー兼用のIPoEルーター、192.168.1.2がDHCP無効のPPPoEルーターで、Linux端末側にはDHCPで192.168.1.8が割り当てられていてデフォルトゲートウェイは192.168.1.1になっている(=IPoEが使われている)とします。

使っているデバイスNIC)の名前はenp3s0とします。「eno1」「wlp2s0」など環境によって違うと思うので適宜書き換えてください。

この状態で下記のコマンドを実行します。

sudo ip addr add 192.168.1.9/24 dev enp3s0 label enp3s0:1

すると、enp3s0に対して192.168.1.9という追加のIPアドレスが割り当てられ、そのIPアドレスをenp3s0:1という名前で参照できるようになります(labelはあってもなくてもあまり変わりませんが)。ip addr showで確認してください(出力結果を記録していなくてすみません)。

ここまでの内容はWindowsでも同等のことができます。また物理NICの追加も必要ありません。

ルーティングテーブルの追加

この状態ではまだ192.168.1.9を指定してインターネットにアクセスしても192.168.1.8と同じルーティングテーブルが使われてしまいます。一つのルーティングテーブルにはデフォルトゲートウェイは一つしか設定できないので、全く別のルーティングテーブルが必要です。

そこで、/etc/iproute2/rt_tablesを編集して、240 pppoeという行を追加します。全体は以下のような感じになると思います。

#
# reserved values
#
255    local
254    main
253    default
0    unspec
#
# local
#
#1    inr.ruhep
240    pppoe

240という数値は1-252の間だったら何でも大丈夫です。ただ200-250くらいを使うのが多いかなとは思います。240とpppoeの間は既存ファイルの内容に倣うとタブスペースなのですが半角スペースでも問題なく動くようです。

これでpppoeという名前の新たなルーティングテーブルが使えるようになりました。

新たなルーティングテーブルの編集

では、こうして作成したpppoeテーブルにデフォルトゲートウェイを追加します。

sudo ip route add default via 192.168.1.2 dev enp3s0 table pppoe

このように、PPPoE用ルーターIPアドレスと使用するデバイス(enp3s0)、テーブル(pppoe)を指定してip route addを実行します。なお、以下のコマンドの「table pppoe」の部分はすべて「table 240」と数値で指定しても変わりません。

必要があれば他の静的ルーティング設定も追加してください。

結果はip route show table pppoeで確認できます。このような1行だけの出力が出るかと思います。

default via 192.168.1.2 dev enp3s0

ルーティングテーブルの選択ルール(ポリシー)を追加

最後に、「192.168.1.9を使用するときにはpppoeというテーブルを使用する」というルールを追加します。これは以下のコマンドでできます。

sudo ip rule add from 192.168.1.9 lookup pppoe

これにより、192.168.1.9を使用するときにはpppoeテーブルが使われます。

さらに細かい条件で指定したければ、備忘録: 【Linux CentOS 7】特定のパケットのみ別のルーティングテーブルを用いて転送する方法(ポリシールーティング)routing - How to create a protocol-based default route using iproute2 - Server Faultみたいな感じで、条件に一致するパケットにmarkを付けておいて、そのmarkに応じて振り分けるという方法もあります。

注意

ここまでで設定は完了です。

ただし、自分の環境では設定変更の直後はPPPoE用ルーターへのpingがしばらく通らず、結果としてPPPoE経由でのインターネット通信もできない状態になることが多くありました。

おそらく、PPPoEルーター(ちなみにBuffaloのWSR-1166DHPL2という安物です)の直下にPCをつないでいるせいで、PCが2つのIPアドレスを持っている状態にうまくルーターが対応できていないのではないかと思われたため、ルーターに接続されている別のスイッチングハブを経由してPCを接続したところ、症状はやや改善しました。しかしこのあたりはやはり同じNICに二つのIPを追加している弊害という感じがするので、どうしても避けたければNICを追加したほうがよさそうです。USBに刺せるものもありますし。

あと、記事では紹介していませんが、出ていくIPではなくポートやプロトコルで振り分けるような場合は、そもそもIPを複数にする必要がないかもしれません。それならばこのような問題は起こりません。ポートによる振り分けは、外部からのアクセスのみPPPoE経由にしたいような場合に有用ですが、内部からのアクセスはエフェメラルポートの中でどれが割り当てられるかわからないため制御が難しくなります。

経路を同時利用してみる

実際に両方の経路を同時利用できるか調べましょう。手軽なのはWAN側IPアドレスを表示してくれる「確認くん」のようなツールを使う方法です。まずは以下のように普通にcurlコマンドでugtop.comのトップページを取得してみます。

curl https://ugtop.com

すると、以前と変わらずIPoE側のIPアドレスが書かれているはずです。では次に、追加した192.168.1.9を明示的に指定してみます。

curl --interface 192.168.1.9 https://ugtop.com

これで先ほどとは異なるPPPoE側のIPが表示されれば成功です。なお、--interface enp3s0:1というふうにlabelの名前で指定することもできます。

ちなみに、MyDNSの更新はcurlでできるので、IPoEを利用しながら、PPPoEのIPアドレスを通知するということが可能になります。

digでIPアドレス取得

ちなみに、IPアドレスを取得する目的であれば、DNSを使うほうが安定しており、応答も高速です。

グローバルIPアドレスをコマンド(curl/dig等)で確認する方法 | 株式会社ビヨンド

digコマンドで自分のグローバルIPアドレスを取得(IPv4・IPv6) | 小林ノート

などに例があります。opendnsを使うのであれば、

dig -4 myip.opendns.com @208.67.222.222 +short

dig -4 -b 192.168.1.9 myip.opendns.com @208.67.222.222 +short

で、IPoE/PPPoEのグローバルIPが取得できます。出力も1行だけなので見やすいです。

このbというのは「bind address」の略で、簡単に言えば外と通信するときに使うアドレスみたいな意味です。他のコマンドでも、IPを明示的に指定するときはたいていinterfaceあるいはbind address的な名前のオプションを使うことになると思います。

両側からポート転送してみる

次は、IPoE側/PPPoE側の両側からのポート転送を試してみましょう。といってもここまでが正しくできていれば何も難しくありません。例えばLinux上で25565ポートにMinecraftが起動しているとしたら、IPoE側からはWAN側ポート20000→LAN側192.168.1.8:25565、PPPoE側からはWAN側ポート30000→LAN側192.168.1.9:25565というように、IPoE用/PPPoE用のアドレスをそれぞれ使って転送設定をすれば、IPoEのアドレスの20000ポートとPPPoEのアドレスの30000ポートの両方からMinecraftに接続できるようになります。192.168.1.9から来た(=PPPoE側から来た)パケットへの応答は192.168.1.9から出ていくので、さっきのルールによってPPPoE側を通ることになり、正しく通信できるというわけです。さっきのルールがないと、返事がIPoE側から出ていってしまうので通信が成立しません。

念の為ですが、bind addressを0.0.0.0に設定(sshトンネルなら-gオプション)して、アプリケーション側で192.168.1.8:25565と192.168.1.9:25565の両方をlistenするように設定することが必要です。Minecraftでは最初からそうなっています。

設定を永続化する

ひとしきり遊んだところで話題を戻しますが、このままだとLinuxを再起動したときにip addr addとip route addの設定が消えてしまうので、設定ファイルに書いて永続化する必要があります。もちろん、/etc/iproute2/rt_tablesの編集内容は消えないのでそこに関しては不要です。

このようなネットワーク関連の設定は、UbuntuDebian系)なら/etc/network/if-up.d/ 以下、/etc/sysconfig/network-scripts/ 以下にスクリプトを作成しておくと、ネットワークが起動するとき(した直後?)に実行してくれます。Ubuntuなら/etc/network/interfaces に直接書く方法もあるようです。基本的にはif [ "$IFACE" = "enp3s0" ]; thenfiで囲んだところに前述のコマンドをそのまま書けばいいのですが、ip ruleに関してはそのままだと実行されるたびに同じルールが何度も追加されてしまうので、明示的にpriorityを指定することを推奨します(例: sudo ip rule add from 192.168.1.9/32 table pppoe priority 5000)。

しかし、手元ではうまくいきませんでした。再起動直後はインターネットに接続できない状態になっており、タスクトレイの有線接続のアイコンからoff→onと一度再起動しないと正常化しませんでした。sleepなどで時間を十分あけるという方法もありそうですが、あまり美しくないので別の方法を調べました。後日試したら普通にできました。ip routeとip addrは書いてたけどip ruleを書くの忘れてたかな…どうやら、networkingを無効化(後述)するとちゃんと動くようです。なんで???

Netplanによる永続化

どうやらUbuntu 17.01以降からはif-upではなくnetplanという新しいシステムを使うように移行してきているということがわかりました。試行錯誤しながらやったらなんか動いたという感じなので細かいことはわかりませんが、こちらも一応できたので、やり方を説明します。

まずnetplanに切り替えるために従来のnetworkingというのを無効化します。そのかわりにsystemd-networkdを有効化します。(networkingを無効化するというのは Ubuntu 18.04 LTS のネットワーク設定がnetplanというものになっているのでその扱い方についてのメモ書き - dshimizu Blog (α版) に書いてあったのですが、あまり他サイトには載っていないので、他にもやり方があるのかもしれません)。

そして、/etc/netplan/(自分のケースでは、古いUbuntuからアップグレードしてきたからか、空フォルダでした)に以下のような99-pppoe.yamlを作成します。

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp-identifier: mac
      dhcp4: true
      dhcp6: true
      addresses:
      - 192.168.1.9/24:
          label: "enp3s0-pppoe"
      routes:
      - to: 0.0.0.0/0
        via: 192.168.1.2
        table: 240
      routing-policy:
      - from: 192.168.1.9/32
        table: 240

このように、enp3s0に対してまず従来と同じくdhcpでの割り当てを追加し、その上でaddressesで明示的に192.168.1.9/24を追加してラベルを付けます(インデントの書き方に注意!)。ラベル表記は比較的最近(2020年頃)サポートされたようです。なお、先ほどのip addr addのときのラベルはenp3s0:xxxという形でないと受け入れられませんでしたが、ここでのラベル設定はtestなど任意の文字列が許容されているようです。

DHCPと固定アドレス割り当てを両方やる例は探してもあまりなく、苦労しました。特に、自分の環境ではdhcp-identifier: macがないとIPアドレスが取得されなかったのでここは注意してください(ルーターにもよったりするのかな?)。なお、別に片方をDHCPにする必要はなく、両方固定IPで全く問題ありません。というかそのほうがいいと思います。このときはaddressesに複数書けばよいです。こちらの設定内容は調べれば色々でてきます。あと、DHCPで2つのアドレスを取得するみたいな方法もあるのかもしれませんがさすがに難しそうな気がしたのでやりませんでした。

次に先ほどのip route addに対応する内容として、240番(pppoe)テーブルに、192.168.1.2をデフォルトゲートウェイとする内容を書きます。さらにその下で、ip rule addに対応する内容として、192.168.1.9から出ていく通信がpppoeテーブルを使うように設定します。

なお、ポリシールーティングの書き方に関しては他にも参考サイトがあります(netplanでポリシールーティングする #Ubuntu - Qiita など)。

これで再起動すればうまくいっているはずです。正確には、上記の設定ファイルの内容を反映させるにはsudo netplan applyだけで十分なのですが、networkingの無効化のために完全な再起動が要る、という感じな気がするので、networkingの無効化後に一度でも再起動を経ているなら、sudo netplan applyをしてみてしばらく経ってもダメだったら一応再起動してみる、くらいのノリがいいかと思います。ちなみに手元では、sudo netplan apply のたびにWARNING:root:Cannot call Open vSwitch: ovsdb-server.service is not running.と言われますが、別に問題なさそうです。/etc/systemd/networkとか/etc/systemd/resolveにファイルを置くみたいなことを書いてあるサイトもありますが自分のところでは不要でした。

あと、ip addr showに出てくるlo:とかに対応する設定を上記のyamlには何も書いていませんが、netplan以降後もそこは変わらずそのまま表示されていたのでこれも別に問題はなさそうです。

正常稼働時のip addr show の結果はこんな感じです。

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.9/24 brd 192.168.1.255 scope global enp3s0-pppoe
       valid_lft forever preferred_lft forever
    inet 192.168.1.8/24 metric 100 brd 192.168.1.255 scope global secondary dynamic enp3s0
       valid_lft 257337sec preferred_lft 257337sec
    inet6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 14048sec preferred_lft 12248sec
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever

IPv6に関してはよくわかっていなくて不安なので一部伏せ字にしてあります。

上記の結果を見るとわかりますが、DHCPで取得されてメインとして使いたい方の192.168.1.8に「secondary」と書かれています。しかし普通にブラウザなどで使う分にはちゃんと192.168.1.8のほうがデフォルトで使われていてとりあえずは問題なさそうです。ここはちょっとよくわかっていません。ip addr addで追加したときはどちらのアドレスにも「secondary」表記は出ていませんでした。

全く同じ問題で悩んでいる人がいて(linux networking - How to add a static secondary IP to a DHCP interface using netplan? - Server Fault)、そこに書いてあるようにDHCPでもらえるアドレスが事前にわかるときはそれを明示的に書いておけばうまくいくようです。設定ファイルを分割して80-dhcp.yaml90-static.yamlみたいにするのは効果がありませんでした。

他にもipコマンドで手動設定したときとは違うところがちょくちょくありましたが、まあ動いているのでいいでしょう。

ただ、この方法にも欠点があり、networkd(さっきのyamlの3行目で指定されているやつ)はGUIフロントエンドがない(探せばあるのかも?)とかWi-Fiに対応していない?(あるいはパスワード含むアクセスポイントの情報をそのまま書かなきゃいけないかもしれない)とか、普段遣いだと従来のNetworkManagerより劣る部分も多々あります。前節最後に書いた通りNetworkManagerを使っても普通に動くことが後に判明してしまったので、特に理由がなければそちらをおすすめします。

HTTPプロキシを立てる

ここまでで設定は完成したので、再び応用編に戻ります。こんどは、PPPoE/IPoEの両方に出ていけるプロキシを立ててみましょう。

まずはhttpプロキシ用に広く使われているsquidを使ってみます。インストール方法など基本的なところは他の記事に譲るとして、/etc/squid/squid.confに以下のように設定します(これも基本的な内容ですが…)。

http_port 3128
http_port 13128
acl ipoe myport 3128
acl pppoe myport 13128
tcp_outgoing_address 192.168.1.8 ipoe
tcp_outgoing_address 192.168.1.9 pppoe

これが設定ファイルの全部というわけではありません。初期状態は「http_port 3128」がどこかに書いてあると思うので、そこに以降の5行を追記する感じでいけると思います。設定内容としては、3128番ポートに来た内容は192.168.1.8から出ていき、13128番ポートに来た内容は192.168.1.9から出ていくという感じになっています。「ipoe」「pppoe」のところは好きに変えて構いません。なお、DHCP前提ですが192.168.1.8を固定した書き方になってしまいました。

あと、ここには書いていませんが、今回のようにインターネット側に行く用途でsquidプロキシを立てるなら、プライベートアドレス(LAN内)へのアクセスはブロックしてもいいかもしれません(万が一外部からアクセスが来てもそれなりに安全)。デフォルトではブロックされていないです。

書いたらsudo systemctl restart squidとして再起動し、curl https://ugtop.com -x http://localhost:13128などのコマンドで動作を確認しましょう。

ポートで分けるのではなく、192.168.1.8:3128ならipoe、192.168.1.9:3128ならpppoe(あるいは逆でも)といった設定もできます。(myportのかわりにmyipを使うことになります)

他の記事としては複数の IP アドレスを使用した Squid プロキシの構成TOAST Instance 1台に複数のグローバルIPを割り当てる | NHN Cloud Meetupも参考にしてみてください。

このHTTPプロキシをProxy SwitchyOmegaやFoxyproxyのようなブラウザ拡張と併用すれば、特定ドメインだけはPPPoE経由でアクセスするようなことが可能になります。あるいはプロキシ内で接続先ドメインによって振り分けることもできる(プロキシはDNSよりも先に使われるので)と思いますが、そこまでは自分のところでは試していないので他サイトをご参照ください。

自分の環境では初期状態だとhttp_access allow localnetの行がコメントアウトされていて他のマシンから接続できませんでしたが、この行を有効にすれば、LAN内の他のマシンからでもプロキシが使えるようになります(localnetの中身はもともとのsquid.confの中に書かれているはずです)。

SOCKSプロキシを立てる

HTTPプロキシに比べるとややマニアックですが、SOCKSというプロキシの仕組みもあります。ssh -Dで立てられることで知られているやつです。パフォーマンスがいいとかSOCKS5だとUDPも通るとか、利点もあるようです。

LinuxだとdanteというSOCKSプロキシのソフトがあります。これも同様に、/etc/danted.confに以下のように設定します。(他にもいろいろな設定はありますが最低限これだけでも動くはずです)

internal: enp3s0 port=3129
external: enp3s0
internal: enp3s0-pppoe port=3129
external: enp3s0-pppoe
external.rotation: same-same

socksmethod: none
clientmethod: none
client pass {
  from: 0.0.0.0/0  to: 0.0.0.0/0
}
socks pass {
  from: 0.0.0.0/0 to: 0.0.0.0/0
}

external.rotation: same-sameを指定することで、アクセスが来たIPと同じIPから出ていくように設定しています(DHCP前提だったのもあってここではラベル名で指定していますが、IPも書けます)。ポートごとに振り分けるやり方があるかはわかりませんでした(多分ない)。このままだと、LAN内からならちゃんと使えますが、IPoEのインターネット側から入ってPPPoE方面のプロキシを使うようなことができません。そうしたいときは、3129番だけでなく13129番とかでもリッスンするようにして、192.168.1.8:13129がPPPoE側、192.168.1.9:3129がIPoE側から出て行くようにポート限定でip ruleを設定すればsquidと同等の使い勝手になります。

from: 0.0.0.0/0  to: 0.0.0.0/0がちょっとガバガバな気もしますが、ルーターで無駄にポートを開放しすぎたりしていなければ外からは入ってこないはずなので問題ないでしょう。

これもsudo systemctl restart dantedで再起動したら、curl https://ugtop.com -x socks5h://192.168.1.9:3129のようにして試してみましょう。http://ではなくsocks5h://としているのに注意してください。LAN内の他のマシンからもちゃんとアクセスできることを確認しましょう。

SOCKSプロキシはdante以外だと3proxyというのもあって、こちらだとsquidのようにポートごとにoutgoing IPを設定することができました。以下のような3proxy.cfgファイルを指定して3proxy 3proxy.cfgとします。ちゃんと動くソフトですが細部のつくりはかなり雑で、3proxy.cfgが存在しなくてもまともにエラーが出なかったりするので注意してください。この「socks」というのは実行ファイル名を指定しているようです。debパッケージでもソースからのビルド(socksにパスは通っていないが3proxyと同じディレクトリにある)でもちゃんと動くのを確認しました。

log 3proxy.log D
socks -p3129 -e192.168.1.8
socks -p13129 -e192.168.1.9

sshの-Dではoutgoing IPを指定することはできません(linux - Bind outgoing SOCKS-server traffic to a specific IP - Server Fault)。uidなどで振り分けることはできるようです(proxy - How can I configure the source ip to use for ssh dynamic forwards - Super User)。

補足: PCから直接PPPoE接続

PPPoEとIPoEを併用する場合、上位のIPoEルーターでPPPoEパススルーをするなどして、PCで直接PPPoE接続をするという方法もあります。PCが直接インターネットに晒されるため、必ず事前にsudo ufw enableなどとファイアウォールを有効にしておく必要があります。これも一応試してみました。

まずpppoe接続は【2022年版】Ubuntu 20.04.4 LTS で PPPoE接続する方法 #Ubuntu - Qiitaのようにpppoeconfを使うとできます(pppoeとかpppconfigとかいうのも見ましたが、どう違うのかあまりわかってないです)。ip addr showで確認すると、ppp0:という新たな仮想的なNICのようなものが追加されてPPPoEの設定ができていることがわかります。

ただし、途中のメッセージにある通り、「defaultroute」というオプションが自動で設定されてしまい、インターネット通信のデフォルトとしてPPPoEを選択するルールが追加されてしまっています(ip route showで確認できる)。そこで、ip route delでそれを消した上で/etc/ppp/peers/dsl-providerに行ってdefaultrouteの行を削除します。これで次回からはPPPoEがデフォルトとして選ばれなくなります。この状態でも、curlの--interfaceなどでppp0を指定することでPPPoE接続が使えるため、2つの接続を併用することができます。

ただし、ppp0に割り当てられるアドレスは変動するので、squidやdantedでIPを指定して恒久的な設定を追加することはできません。実はdantedのほうではIPのかわりにインターフェイスのラベル(enp3s0など)を指定することもできるのですが、そこでppp0を指定してもダメでした。どうやら、全体のデフォルトゲートウェイ(mainテーブルのデフォルトゲートウェイ)がppp0に向いていないとdanteがppp0からインターネットに出ていけないようです(curlはできるのに)。

Linux自体をPPPoEルータ化するようなことも頑張ればできるみたいなので、原理的には何か方法はあるのではないかと思うのですが、Linuxで直接接続したPPPoE接続を選択的に使えるようなプロキシを立てるのは少し難しそうです。別にこれが是非とも必要というわけではなかったので今回はここで諦めました。この記事の方法でやるのであれば、PPPoE接続の数だけルーターが必要そうです。試してはいませんがiptablesのMASQUERADEとかをすれば普通にできるのではないかと思います。

補足の補足: Wi-Fi環境でpppoeconfで設定したら直後はつながるのですが再起動後にWi-Fiに一切つながらなくなりました。Ubuntuでpppoeconfを設定、再起動するとネットワークに繋がらなくなってしまいますと完全に同じ状態です。そこに書いてある通りに/etc/network/interfacesを最初の1行(source /etc/network/interfaces.d/*)以外コメントアウトして再起動したら復活しました。別PCの設定ファイルではこの行が無いこともあり、実際に完全に空のファイルでも動作するようです。

関連記事

需要はあるようで、他にも似たようなことをやっている記事があります。物理NICを追加したりヤマハルーターを使ったりといったコストのかかるものもありますが、参考にどうぞ。

ルータ2台体制によって自宅サーバにIPv4でもIPv6でもアクセスできるようにした – コンちゃんの「無いなら作ればいいじゃない!」 netplanを使ってLinuxにIPを2つ設定していて、この記事にかなり近い内容です。ただし、IPv4をPPPoE、IPv6をIPoEという形で分けているので、サーバーPCでのIPv4通信ではIPoEを使うことができません。

サーバー兼用パソコンでIPoEとPPPoEを併用してみた : salvia NICを増設しています。WindowsとBuffaloルーターの構成なので、PC側のアドレスでのゲートウェイ切り替えはできず、ルーター側の静的ルーティングで振り分けています。接続先ドメインのIPが変わると問題になりそうです。

DS-Lite/PPPoE併用環境で自宅サーバの通信だけPPPoEを通す | 6715.jp YAMAHAルーターを使っています。HTTPサーバーがPPPoEで公開できればいいだけなので、ポート番号で振り分けており、IPの追加はしていません。

CentOSでOCNバーチャルコネクト | QuintRokkこちらも同じくポート番号での振り分けについて最後の方で解説されています。PPPoEはPCから直接つないでいるようです。

IPv6 DS-Lite環境下で特定のポートのサーバを公開する 気まま研究所 NICを増設したりIPv6を無効にしたり仮想マシンを使ったりと色々違っていて完全に理解はできていないのですが、似たようなことをやっているようです。

また、Windowsではこのようなポリシーベースルーティングができないという情報は以下の記事にありました。

networking - Choosing gateway based on Source IP in Windows - Server Fault

Can I have multi Routing Tables in Windows? : networking

まとめ

というわけで、高価なルーターや追加NICがなくても、PPPoEとIPoEのような2種類のインターネット接続を良い感じに同時に使えることがわかりました。

何か誤り・疑問などあればお気軽にコメントをお願いします。

フレッツ光関連の設定について(ドコモ光、ひかり電話、IPoE/IPv4 over IPv6とPPPoEの併用など)

概要

最近、ドコモ光のプロバイダを変更するにあたってかなり色々調べたので、知ったことをまとめておきます。一部、調べ切れていなかったり用語が不正確だったりするかもしれませんがご容赦ください。訂正や質問などはお気軽にコメントいただければありがたいです。

ドコモ光と光コラボについて

光コラボ」というのは、NTT東日本/西日本が提供する「フレッツ光」の設備を各プロバイダが借りて提供している光回線サービスのことです。「コラボ光」という場合もあります。「光コラボ」の例としては「GMOとくとくBB光」「ドコモ光」「SoftBank光」「AsahiNet」などなどたくさんあります。しかし、このうちドコモ光(だけ?)は特殊で、「ドコモ光」の契約に際して、20個くらいある「ドコモ光に対応したプロバイダ」の中から一つを選ぶ必要があります。「ドコモ光」単体だけではインターネットは使えないということです(「ドコモ光」単独プランというのもありますが、これは上記の20個くらいのプロバイダに含まれていないプロバイダでどうしてもドコモ光を使いたいときなどに利用されるもので、いずれにしろ「ドコモ光」だけではインターネットは使えないということになります)。最新の一覧はこれかなと思います。

さらに、この20個くらいの「ドコモ光に対応したプロバイダ」というのは、大半(全部?)が、(ドコモ光とは無関係の)光コラボを提供する事業者でもあります。先ほど挙げたGMOとくとくBB、AsahiNet、その他にはhi-ho、@niftyBiglobeなどがその例です。つまり、ひとくちに「GMOとくとくBBを使う」といっても、光コラボとしてのGMOとくとくBBなのか、ドコモ光対応プロバイダとしてのGMOとくとくBBなのか、という曖昧さが残っているということです。注意しましょう。

「光コラボ」は、どれを選ぶかによって基本料金や割引制度などは様々に異なります。一方、「ドコモ光」の各プロバイダは、「タイプA」「タイプB」という2種類の料金制度のどちらかを採用することになっており、プロバイダ独自の制度が入り込む余地はあまり大きくありません。回線のスペックにそこまで強いこだわりのない一般のユーザーは月額料金が安いタイプAのプロバイダから適当なものを選ぶという場合が多いでしょう。むしろ、「ドコモ光」自体の、ドコモのスマホ料金とのセット割などが、他の光コラボと差別化する重要なポイントになっています。

OCNインターネットについて

「OCNインターネット」というのは、NTTドコモが提供する「ドコモ光対応のプロバイダ」の一つです。「ドコモ光」に対応したプロバイダとしてこれまたドコモが提供するプロバイダがあるというのは変な感じですが、そういうものらしいです。

この「OCNインターネット」は、2023年7月から提供されているもので、前身は「NTTレゾナント」が運営する「OCN」でした(現在はNTTドコモに引き継がれてサービスは継続中だが新規受付は6月いっぱいで終了)。「OCN」は、「ドコモ光」対応プロバイダ(「OCN for ドコモ光」)であると共に独自の光コラボ(「OCN光」)も提供していましたが、「OCNインターネット」はドコモ光対応プロバイダとしてのみの提供で、独自の光コラボの提供はないようです。

またこの2023年6月末のタイミングに伴い、同じくNTTドコモやNTT系会社が運営するドコモ光向けプロバイダである「ドコモnet」と「ぷららplala)」も新規受付を終了しました。このうち「ドコモnet」は従来からドコモ光向けプロバイダとしての提供のみ(=OCNインターネットと似た感じ)だったので(新規受付は)完全終了となりますが、「ぷらら」は独自の光コラボ(「ぷらら光」)も提供しており、こちらは現在も引き続き新規契約を受け付けているようです。

10ギガ

自分はあまり詳しくないので扱いませんが、最近は最大10Gbps出るというサービスもドコモ光含む各光コラボから提供されているようです。遅延が改善するかもわからないのにスループット(一定時間に通信できる量)だけそんなに高くして何か意味があるんでしょうか…?

home 5Gなどのホームルーターについて

これも本筋とは関係ないのですが、光回線を引かなくてもよい高速通信サービスとして普及してきているのがホームルーターです。スループットは高く、通信制限も事実上ほとんどないところが多そうですが、ping値がやや高い(遅延が大きい)のでオンラインゲームにはそれほど向かないという点には注意が必要です。光回線が引かれていない家を数か月間だけ使うとかでなければ光回線のほうがいいのではないでしょうか。

ひかり電話について

ひかり電話」とはNTT東西が提供する光電話のサービスの名称です。IP電話と同じ技術を使用していて、月額料金は比較的安いものの、固定電話と同じく市外局番から始まる番号が使えるようになっています。

各種光コラボも、このNTT東西の「ひかり電話」の設備を借りて光電話サービスを提供しており、「ドコモ光電話」「GMOひかり電話」などのプロバイダによる名称がつけられています。月額500円ほどの有料オプションとなっています。

NTT東のひかり電話のタイプ1/タイプ2について

NTT東日本が(直接的に、あるいは光コラボのプロバイダを通じて間接的に)提供するひかり電話の契約には、技術的には「タイプ1」「タイプ2」という2種類があります。このタイプ1というのはNTT東日本が以前提供していた「Bフレッツ」に由来するもので、西日本にはBフレッツはなかったためタイプの区別はないようです。

回線IDが"COP"から始まるとタイプ1の可能性があります。回線IDが"CAF"から始まる場合はタイプ2です。(COPから始まってもタイプ2である場合もあるようです。【祝】v6プラス開通!【祝】 | 乗らずに見送って。など。)

「v6プラス」の手続きをしたい (お客さまIDが「COP」で始まり、2014 年 9 月以前にひかり電話の契約をしている場合) | 会員サポート | So-net

IPv6接続機能 (IPv4 over IPv6接続) | 「IPv6接続機能」のご案内 | オプション | 各種サービス | プロバイダ・インターネット接続は ASAHIネット

この辺を見ると、2014年以前くらいの古い契約だとタイプ1である可能性が高いということになりそうです。

以後で説明するサービスの中には、ひかり電話がタイプ2でないと利用できないものがいくつかあります(逆はありません)。そこで、場合によってはタイプ2への変更手続きが必要になってきます。なお、タイプ1が音質優先であるとの情報も1件だけありましたが、電話としてのサービス内容は変わらないと書いてあるサイトが大半であり、本当かどうかは疑問です。

タイプ2への変更には基本的に料金はかかりません。回線IDも変更されません。必要な手続きは契約の形態によって異なり、NTT東日本と直接契約している場合は、0120-116116に電話するとタイプの確認および変更ができます。一方、光コラボを通じて間接的にひかり電話を使っている場合は、各プロバイダを通じて変更の手続き・依頼をすることになると思います。ドコモならドコモの携帯から151に電話すると良さそうです。しかしこのパターンに関しては情報が比較的少ないです。

詳しくは後述しますが、自分のケースではひかり電話の契約が「タイプ1」になっており、「タイプ2」への変更が実質的に必要となるサービスをドコモ光を通じて申し込んだことに応じて、ドコモ光側がNTT東日本に対してタイプ2への変更を依頼するという形になったようです。

なお、タイプ2から1に変更できるかは不明です(しようと思う人はいないでしょう)。

光回線ではなく電話関係ですが、タイプ1とタイプ2で違いがありそうな内容について解説した記事があったので一応載せておきます。「マイグレーション回線」の思わぬ落とし穴とは!?ビジネスホンを入れ替え導入する時に確認しておくべきこととは? | ビジネスホンの「ビ」

ホームゲートウェイ(HGW)とはなにか

ホームゲートウェイとは、フレッツ光系の回線の契約に伴ってレンタルすることができるNTT提供のルーターのことで、市販はされていません。しばしばHGWと略されます(当記事でもそうします)。型番は「PR-500KI」のような感じで、最初の2文字が機種タイプの分類(後述の一体型/単体型など)、次が世代を表す数字(数字が大きいほうが新しい)、最後の2文字が製造メーカー(KI…沖電気、MI…三菱電機、NE…NEC日本電気)を表します。数字のところが500だったらまとめて500番台などと(少なくともこの記事では)呼びます。

ひかり電話に対応しているのが大きな特徴で、ひかり電話(あるいは一部のオプションサービス)を契約すれば無料でレンタルできます。そうでない場合も月額300円ほどで借りられるようです。また無線LANWi-Fi)機能は別途月額料金がかかり、性能も良くはないので、必要なら自前でWi-Fiルーターを買ったほうがいいでしょう。

ひかり電話ユーザーの多くにとってはコスト的に有難い存在である一方、機能・操作が制限されている、必ずしも性能が良くない、などの理由で悩みの種になることもあります。

ONU/モデム部分の配線の形態

フレッツ光の配線にはいくつかの形態があり、建物の構造や選択するプランなどにより変わります。しかし、全体に共通して言えるのは完全にプロバイダ側しか手が出せない部分ユーザー側で変えられる部分というのがあり、その境界にはLAN(Ethernet)ポートがあるということです。一応、例外もあるのですがそれについては後述します。で、この「完全にプロバイダ側しか手が出せない部分」を構成する主な部品がONUあるいはモデムです。

配線の形態は大まかに以下のように分類できます。参考までに、接続設定|お客様サポート|インターネット|ソフトバンクなどにも色々な配線図があります。

1. LAN配線方式

この場合最も単純で、家の壁が境界部分であり、壁から直接LANポートが出ています。モデムやONUにあたるものは部屋の外にあり、マンションの管理組合を通さないと手が出せないという感じです。それ以上の分類に関しては詳しくないので省略します。

2. 光配線方式

この場合、壁から光ファイバーケーブルが出ていて、それがONUによりLANポートに変換されます。ここが境界部分となります。ただし、HGWを使っている場合は、ONU一体型の機種(PR-xxx系)がレンタルされていることがあります(一体型でないものは単体型などと呼ばれます)。この機種は内部で物理的にONU部分とルーター部分に分かれており、それを隔てるLANポートはHGWの背面のUNIと書かれた部分に格納されていて、ルーター側からつながっているHGW内部のLANケーブルを外すとポートが使えるようになります。ここが境界部分です。つまり一体型といいつつ必要に応じて分断して使えるということです。この分断操作を行うことは俗に「UNI出し」と呼ばれています。

また、最近のONU一体型の機種だと、「小型ONU」という装置が使われているものがあり、これはLANポートとは異なる形状のポートでONU部分とルーター部分が接続されているため、「UNI出しをすることができません。これが先ほどの「例外」です。

もし、ひかり電話有りでUNIポートを使いたい場合は、最初にひかり電話契約無しで光コラボ/フレッツ光などを契約してONU単体を送付してもらい(←これは必ずLANポートが付いている)、後からひかり電話を契約することで確実に単体型のHGWをレンタルしてもらうという方法があるようです(自宅ラックはCOMPAQ9122 on X: "ついでに… なぜヒトは、まずはじめに「ひかり電話なし」で回線を契約して単体ONUを手に入れてからHGW追加(ひかり電話追加契約)をしないのか。" / Xなど)。

また、YAMAHAなどの市販ルーターでは小型ONUのポート形状に対応しているものがあり、小型ONUには電源が不要で配線がシンプルになるなどのメリットもあることから、逆にレンタル時に小型ONU機種を希望したという例(ドコモ光で小型ONUに交換してもらう方法 | サーバーストーリーなど)もありました。

3. VDSL方式

光配線方式と大体同じですが、壁から光ファイバーではなく電話線が出ていて、それがVDSLモデムによりLANポートに変換されます。ここが境界となります。規格上、速度上限は100MB/sになります。

光配線方式と同じく、HGWを使っている場合は、VDSLモデム一体型の機種(RV-xxx)がレンタルされていることがあります。しかしこの場合、先ほどのUNIにあたるポートは無さそうです。というのも、先ほどの「UNI出し」が公式に説明されている「ひかり電話ルーター」のレンタル契約を解約せずに市販のひかり電話対応ルーターを利用する方法について|ひかり電話|フレッツ公式|NTT東日本では、VDSL一体型だった場合はVDSLモデムに変える必要があると説明されているからです。この理由については完全な推測ですが、VDSLは元が電話線なので、そこからひかり電話を出すためには、一旦LANケーブル(UNI)に変換してからまたルーター部分で電話線に戻すような非効率なことはせず、電話線の段階で分岐させている、とかそういう感じじゃないかなと思います。

VDSLに関しては光配線方式に比べると情報が少なく調べるのが難しいです。速度にこだわるような上級ユーザーはそもそもVDSL方式の家を選ばないからでしょうか?あるいは単純に古いから?とはいえ、適切にプロバイダを選んで適切に設定すれば下り実測70Mbpsくらいは出るわけですから、実用上は十分です(個人の感想です)。

4. その他

VDSLの祖先みたいなADSL方式とかもあるらしいですがよくわかりません。

フレッツ・ジョイントとは

フレッツ・ジョイントというのは、光回線を通じてプロバイダ側からユーザー側にソフトウェアを配信することができるシステムで、メーカーが家電製品などへのソフトウェア配信に使うこともできますが、HGWに機能を配信することもでき、当記事に関係するのは後者のほうです。フレッツ・ジョイントの利用は(ユーザー側にとっては)無料で、申し込みも通常不要で自動で有効になるパターンが多そうですが、契約のしかた・タイミングによっては明示的に要請が必要になる可能性がありそうです。また、フレッツ・ジョイントの利用にはひかり電話がタイプ2である必要があります。

フレッツ・ジョイントでHGWに配信されたソフトウェアについて確認するにはhttp://ntt.setup:8888/t/あるいはhttp://192.168.1.1:8888/t/(192.168.1.1の部分を自分で変更している人はそちらに従う)にアクセスします。

IPv6/IPoE接続とは

フレッツ光におけるインターネットへの接続方式にはPPPoE方式とIPoE方式の2つがあり、このうちPPPoE方式は利用者の多い夜間などは認証を行うサーバーが混雑して速度が低下しやすいとされていることから、近年はIPoE方式も普及してきています(ただし、環境によってはPPPoEのほうが速度が出ることもあるようです)。フレッツ光と完全に独立の設備であるauひかりなどにはIPoE/PPPoEの概念はないらしいです。(でもNURO光にはある?)

このIPoEというのは新しいプロトコルであるIPv6にしか対応しておらず、そのままでは従来のIPv4でしか提供されていないほとんどのサイト・サービスは使えません(例えばGoogleは見られるがYahooは見られない)。しかし、IPv4 over IPv6という方式によりIPv4IPv6のように見せかけることでIPoE上でもIPv4を使うことができるようになります。つまり全てのサイトをIPoEで見ることができるようになります。仕組みについては詳しいサイトが多くあるのでそちらを参照してください。ちなみに「IPv4 over IPv6」は長いので、この記事ではその意味で「IPoE」を使うことが多くなるかもしれません。

ただし、IPv4 over IPv6には従来のPPPoEによるIPv4とは違ってポートの開放が自由にできないという制限があります。これに伴ってVPNが使えない、特定のポートを使うゲームやデバイスが使えない、といった不便が生じます。厳密にはそれ以外にも制限があった気もしますが忘れました。

IPv4 over IPv6の中にはいくつか方式のようなものがあり、それによって制限の内容は異なります。メジャーな方式はMAP-eDS-Liteというものです。さらにMAP-eの中には「v6プラス」「OCNバーチャルコネクト」「IPv6オプション」の3種類があり、DS-Liteの中には「Transix」「クロスパス」「v6コネクト」の3種類があります。さらにこのどちらにも分類されない「IPv6高速ハイブリッド IPv6 IPoE + IPv4」というものソフトバンク系のサービスにあるようです。比較的有名なものを太字にしてあります。また、おそらく廃止に向かっているようで情報が少なくよくわかっていませんが「OCN v6アルファ」もこの一種かもしれません。

MAP-e系のものは一部のポートの開放が可能ですが、DS-Lite不可です。また例えばOCNバーチャルコネクトのほうがv6プラスよりも開放できるポートが多いなど、色々と細かい違いがあります。詳しくは以下をご参照ください。

IPv6(IPoE)のまとめ、乱立する「v6プラス」「Transix」「OCNバーチャルコネクト」を比較する | ネット回線のマニュアル

フレッツ光の「IPv4 over IPv6」MAP-eとDS-Liteは何が違う? | Wi-Fiマニュアル

使えるポートが少ないとNATのセッションによりポートが枯渇して不安定化する?という話(Ubuntu / Debian でIPv4 over IPv6 (OCNバーチャルコネクト, v6プラス), systemdによる設定, ルーター化, VPNおよび自宅サーバー可能な固定グローバルIPv4アドレス #RaspberryPi - Qiita)も一応あるようですが、おそらく通常はあまり問題にならないものと思われます(上記で引用されている記事や、QUICとNATで確かめたいと思うこと (MAP-EでのNATとNAT64) #nat - Qiitaなどを読んだ感じ、ルーター側がちゃんとしていれば大丈夫?)。

どの方式を採用するかはプロバイダによります。例としてドコモ光対応のプロバイダに関する一覧を載せておきます。

https://www.docomo.ne.jp/content/dam/corp/jp/ja/binary/pdf/hikari/support/router_security/ipv4_over_ipv6.pdf

ちなみに、IPv6はPPPoEでも使うことができますが、これについては自分が特に必要性を感じなかったので調べておらず、記事でも触れません。

ルーターのIPoE対応

IPv4 over IPv6を利用するには、対応したルーターを使う必要があります。最近(ここ5年以内くらい)のルーターであればメジャーな方式(v6プラス、OCNバーチャルコネクト、transixなど)には対応している可能性が高いのではないかと思いますが、ちゃんと書いてあるはずなので調べましょう。「IPv6対応」「IPv6パススルー(ブリッジ)対応」とだけ書いてある場合は対応していない可能性もあるので、「IPv4 over IPv6」あるいは「v6プラス」などのサービス名をキーワードと考えましょう。

IPv4 over IPv6の利用時には、セキュリティ対策として、IPv6に関するオプションのところで「NDプロキシ」を選ぶといいようです(正確には、NDプロキシ自体はセキュリティ機能ではないが、低価格帯のルーターだとセキュリティ機能と抱き合わせになっていることが多く、逆に高機能なルーターだと別でセキュリティを設定しなければいけないこともあるらしいので注意)。

また、ルーターによっては、ポート開放の機能自体はあるのにIPv4 over IPv6だとポート開放できないとか、v6プラスだとできるのにOCNバーチャルコネクトだとできないとか、そういう場合もあるようです(例:V6プラスのポート開放 - いおりのパソコン技術メモ)。そこまで詳細にメーカーサイトでちゃんと書かれているかどうかわからないので、心配ならレビューとかで頑張って調べましょう。

HGWのIPoE対応

HGWにおいては型番が300以上のものはIPoEに対応していますが、対応するためのソフトウェアはフレッツ・ジョイントで配信されます(従ってひかり電話がタイプ1だと使えるようになりません)。例えば以下はHGW含む各ルーターのOCNバーチャルコネクトのサポート状況ですが、HGWのところにはフレッツ・ジョイントに関する注意書きがあります。https://www.ntt.com/content/dam/nttcom/hq/jp/business/services/network/internet-connect/ocn-business/option/v-access-ipoe/pdf/bocn_vc_router.pdf

IPv4 over IPv6サービスの中でも、MAP-E系は300以上から対応していますが、DS-Lite系は500番台以上が必要です。

フレッツ・ジョイントはプロバイダがNTT東西に利用料を支払ってソフトを配信するシステムであり、プロバイダによってはそもそもフレッツ・ジョイントを利用しておらずHGWへの配信を行っていない場合もあるようなのでそこも注意が必要です(例: PR-500MIなどDS-lite対応HGWでIPv4 over IPv6接続できない[IPoE][transix][フレッツ・ジョイント] | PCヨーナル)。この場合は市販ルーターを使うことになります。

配信のタイミングなどについては次節でも詳しく書きますが、フレッツ・ジョイントでの配信が行われるとHGWはIPoE接続専用の状態に変わります。元に戻すにはhttp://ntt.setup:8888/t/から「無効」あるいは「一時停止」など(IPv4 over IPv6の各サービスによって異なる)を選択すればいいのですが、ソフトウェアのバージョンが古いなどでできない場合もあります。そのときは、プロバイダ側に連絡して配信を停止してもらい、その後HGWを初期化してから再接続することになります。連絡しなくても、初期化してからWANにつなぐ前にPPPoE情報を削除すれば配信されなくなるという情報もありますが、その状態でも配信されるという情報もあり、自分のところでも軽く試した感じでは一瞬で配信が来てしまいました。

具体的な設定画面の変化としては、まずPPPoEの設定(ID/パスワードなど)がグレーアウトして利用不可になり、さらに「IPv4パケットフィルタ設定」、「静的IPマスカレード設定」(←ポート開放に使う)、「静的NAT設定」あたりも無くなるようです。

以下に色々な報告例があります。

OCNバーチャルコネクトをWiFiルーターからホームゲートウェイに変更 その2 :キャドキール日記

ホームゲートウェイ v6Neo接続設定方法|インターネット プロバイダならオープンサーキット

低速なBフレッツを高速なv6プラスに | メモグ

Diary: OCNでIPv4 over IPv6 (IPoE)が利用できるか調べる

ホームゲートウェイでIPoE/IPv4 over IPv6接続 それでもWiFiルーターは必要 | つながるわー

ポート開放に関する設定がなくなると述べましたが、そのかわり前述のhttp://ntt.setup:8888/t/からポート開放ができるようになります。ただし、細かい注意点もあり、例えば先ほどのV6プラスのポート開放 - いおりのパソコン技術メモでは、「HGWの型番が400番台以降かつフレッツ・ジョイントでソフトウェアのバージョン4.0.0が配信されている場合に限りOCNバーチャルコネクトでのポート開放が可能」(しかしv6プラスのポート開放はそうじゃなかったのにできた)と報告されています(「無効」設定もこの4.0.0から導入されたと思われます)。PR-300HIでポート開放を行おうとしています。 - 数ヶ... - Yahoo!知恵袋にも同様の説明があります。また、ポート開放機能自体もやや自由度が低い感じで、開放するポート番号を範囲指定できず、設定項目は上限64個なのでポートは64個までしか開放できません。ただ、HGWに限らず、Aterm WX1500HPでも同じ状況でした。Buffalo WSR-1166DHPL2では、画面は範囲指定できるような感じになっていますが、実際に範囲指定してみると(利用可能ポート範囲内であっても)動きませんでした。(参考画像)

 

このへんの制限を回避するには他のルーターとかLinuxを使う必要がありそうです。また、MAP-Eのサービスの性質上当然ですが、UDPまたはTCPにしかポート開放は使えません。

セキュリティ機能に関しても注意が必要です。IPoE関連が配信されてきた初期状態だと、「詳細設定」の「IPv6パケットフィルタ設定(IPoE)」が「標準」になっていて、これだと他のフレッツ光の契約者からのIPv6通信を遮断してくれません。そこで、これを「高度」に変更することが推奨されます(おそらく「NDプロキシ」と似たような効果がある)(参考: フレッツv6オプションのパケットフィルタ設定 | masao-Tec-blogなど)。さらに、ひかり電話の契約がない、あるいはタイプ1だったりするとこの機能が完全に無効化されているという報告があります(V6プラスでホームゲートウェイ(HGW)のIPv6パケットフィルタが機能しない件|たらかた など)。実際、自分の環境でも、新HGWをVDSLモデム直下ではなくPPPoEパススルー経由で旧HGWの内側につないでいたときはひかり電話契約がない扱いになるようで、「IPv6パケットフィルタ設定(IPoE)」の項目が出現しませんでした。

IPoEが使えるようになるまで(配信のタイミングなど)

各種IPv4 over IPv6を利用するためのスペック的な「必要条件」についてはここまでで述べましたが、「十分条件」、つまり実際に使えるようになるまでの過程については情報が錯綜しており、自分自身よくわかっていないところが多いです。フレッツ・ジョイントでの配信が始まった2021年頃の情報だと配信まで数日かかるとか一ヶ月かかるような情報もありますが、近年では環境さえ整えば30分以内で届くという話もあります。

また、v6プラス限定の話かもしれませんが、フレッツ・ジョイント以外(HGW以外のルーターを使う場合)でも、プロバイダからの配信のような手続きが存在する(必要である)かのような情報もあります(v6プラスがつながらないときの原因と解決方法 これはわかりやすい)。HGWを使用する場合と市販ルーターを使用する場合とでプロバイダ側で必要な操作が違うというのは間違いなさそうです。以前のniftyだとこの2つに対応してプラン名が分かれていたようです(「v6プラス」と「IPv6接続オプション」の解約・再申込は必要か(@niftyの場合) | Electronic Information Research LaboratoryNifty-V6プラス変更について(IPv6接続オプションではないです) - パソコン修理・データ救出COMSASなど)。ネスクの申し込み欄でもHGWを使うかどうか選択する欄があります。HGWでv6プラスを使っていたがひかり電話の解約に伴って市販ルーターに変更する、などの場合はプロバイダに連絡しないとIPv4 over IPv6が使えなくなるといったこともあるようです(価格.com - 『v6プラスは光電話を契約していないと使えないのですか?』 NEC Aterm WG2600HS2 PA-WG2600HS2 のクチコミ掲示板)。

また、過去に他のプロバイダで契約していたIPv4 over IPv6の情報が残っていて接続できないというケースもあるようです。いずれにしてもユーザー側でわかることが少なすぎるので遠慮せずプロバイダ側に連絡しましょう。

v6プラスとひかり電話タイプ1

ひかり電話タイプ1だとフレッツ・ジョイントが使えないのでHGWでのIPoE接続ができないと述べましたが、HGWを使わなければIPoE (IPv4 over IPv6)自体の利用は可能です。ただし、v6プラスに関しては、フレッツ・ジョイントとは関係なく(=HGWに限らず全てのルーターで)、ひかり電話タイプ1だと使えないという話がありました。OCNバーチャルコネクトは大丈夫なようで、実際に自分のところではおそらくタイプ1になっていたタイミング(「おそらく」の理由については後述)でも使えていました。

ヤン on X: "v6 プラスはひかり電話タイプ2 (/56 で割り当てられる方)しか対応してないのはよく知られているんだけど,OCNバーチャルコネクトの方はフレッツ・ジョイントを必要としないならタイプ1(/64 で割り当てられる方)でも行けるんだよね メリットは UNI 出しが楽なぐらい" / X

HGWの交換

1ギガ→10ギガへのプラン変更など、正当な理由があれば、HGWを無償で交換してもらえます。他の理由(小型ONUにしたい、など)だと有償になることもあるようです。

故障扱いだと同じ機種に交換されることもあるようなので、新機能のための交換の場合は、故障担当の113番ではなく、ドコモ光サービスセンターの15715に電話すると良さそうです(※ドコモの携帯電話でないとこれらの番号にはつながりません)。

自分の場合、IPv4 over IPv6サービスを使いたいからRT-200NEを交換したいという状況で、これは無償になりました。しかし、ポート開放したいから300番台を交換したいとか、transixを使いたいから400番台を交換したいとかだと通るのかどうかだんだん怪しくなってきそうです。NTT東よりは西のほうが通りやすいようです。

オペレーターによって対応も違うようで、自分と同じような理由にもかかわらず「壊れていないので交換はできない」「派遣手数料が必要」などと言われたというケースも見かけました。希望の対応が得られなさそうであれば日を改めてまた電話するのも手かもしれません。

「フレッツ・v6 オプション」について

フレッツ光でIPoE/IPv6を使用するには「フレッツ・v6オプション」というのを契約する必要があります。ただしこれは無料サービスであり、「フレッツ・v6オプション」を必要とするIPoE/IPv6関連のサービスを光コラボのプロバイダに対して申し込んだ場合はプロバイダが代行してフレッツ側に申し込んでくれることが多いようなので(サイトにちゃんと書いてあるはず)、少なくとも最近はユーザーが意識する必要はあまりなさそうです。

IPoEとPPPoEの併用: プロバイダ側の対応

最近の多くのプロバイダでは、IPoE (IPv4 over IPv6)を利用するのに追加料金などはかからず、Web申し込みなどで即日提供される場合が多そうです。ただしIPv4 over IPv6 (IPoE)の提供と同時にPPPoEの提供を停止するプロバイダも多く、そうすると任意ポート開放などのPPPoEの利点が失われてしまうことになります。

仕様上は両方を同時に提供することは可能であり、実際に同時に提供しているプロバイダもあります。ドコモ光に関してはNTT系が運用するプロバイダ(OCN、OCNインターネット、plala、ドコモnet)では併用が可能です。他にBiglobeも可能という情報があります。GMOとくとくBBなどは対応していないようです(ただし「サポート対象外になってもいいと言えば両方提供してくれる」という情報が複数ありました。元 バイク野郎のひとりごと: V6プラスルーターと PPPoE ルーターを併用するのコメント欄など)。ドコモ光以外の光コラボだとSo-net@niftyなどが対応しているという情報があります(@niftySo-netはドコモ光にも対応しているプロバイダですが、そちらでは併用はできないかもしれません)。

そもそもIPoEやPPPoEといった接続方式は一般利用者には馴染みのない用語であるため各プロバイダのサイトでも「IPoEとPPPoEが併用可能(or不可)」という形では言及されていないことが多いですが、不可の場合は「IPoE接続の開通が確認された時点でPPPoEの提供を停止します」のような注意書きがあるはずです。

例えばエディオンネットやhi-hoのIPv4 over IPv6サービスのページを見ると、PPPoEが使えなくなると書かれていることがわかります。また、ahamo光などは最初からIPoEのみで、「OCNバーチャルコネクトに対応したルーターがないとインターネットに接続できません」「PPPoE方式の提供はありません」と書かれています。

IPoEが標準提供されているOCNインターネットでは、IPv4 over IPv6のページには「IPoE接続オプションを利用する場合は、一部のオンラインゲームなどが利用できなくなる場合があります」的な注意書きがありますが、PPPoEが利用できないとは書かれていません。また、OCN IPv6インターネット接続|光回線 | 個人向けOCNお客さまサポートを見ると、IPv4 over IPv6について、「[提供中]の場合でも、対応端末以外を接続した場合は、IPv6がIPoE方式、IPv4はPPPoE方式になります。」との文言があるので、併用可能だと推測できます(実際可能でした)。

なお、以降の節は同一プロバイダでPPPoEとIPoEを併用することを想定して書いていますが、別プロバイダでIPoEとPPPoEをそれぞれ契約して併用する場合でも配線の仕方は同様かと思います。

PPPoEとIPoEの併用: 配線の基本

PPPoEとIPoEを併用するには利用者側でも多少の設定が必要です。基本的には、PPPoEに対応したルーターとIPoEに対応したルーターが1つずつ必要になります。ただしヤマハルーターなど高機能なものは1台で同時に両方に対応できるものもあるようです(筆者が全く詳しくないので他のサイトに譲ります)。

ONU(あるいはモデム)以下の配線の方法は、PPPoE IPoE併用ネットワークでv6プラスを利用しながらサーバー公開│NANDゲートにあるように、①両方のルーターを(ハブで分岐させるなどして)並列に配置する②IPoEルーターPPPoEパススルーに設定して、内側にPPPoEルーターを配置する③PPPoEルーターIPv6パススルーに設定して、内側にIPoEルーターを配置する、という3通りに大まかに分けられます。ちなみに○○パススルーと○○ブリッジは同義語です。どの方法を取ったとしてもIPv4 PPPoEとIPoE(IPv4 over IPv6)でそれぞれポートの開放が可能です(ルーターが非対応でなければ)。

また、いずれの方法であっても、2つのルーターLANポートどうしを接続して、2つのルーターをどちらも同じネットワーク(サブネット)に入れることで、ネットワーク内からは両方のルーターに接続できるようになります。LAN同士を接続しない場合は、PPPoEルーターの配下からはPPPoE、IPoEルーターの配下からはIPoEのみが使えるということになります。

例えば上記の②でLAN同士を接続する場合の配線は以下のようになります。

わかりやすい図はIPv4 over IPv6(IPoE)と IPv4(PPPoE)を併用可能なインターネット環境を整備する - Qiitaなど他のサイトにもあります。

この場合、DHCPは片方のルーターのみで有効にするのが良いでしょう。大体のケースでは、普段のインターネットはIPoEを使い、ポート公開などに使う一部のPCのみPPPoEを使うことになると思うので、IPoEルーターのみにDHCPを設定することが多いでしょう。LANで正しく接続されていれば、例えばWi-Fiルーターであるルーター1でDHCPが無効だとしても、ルーター1に無線で接続したときにはルーター2がDHCPでIPを割り当ててくれます。DHCP無効のほうのルーターに接続するときは手動でIPやデフォルトゲートウェイを設定します(他サイト参照)。ちなみに、IPアドレスの範囲が被らないように正しく設定されていれば、両方のルーターDHCPを設定しても問題はありません(場合によってIPoEになったりPPPoEになったりすることにはなります)。

①②③全てについて、上記でパススルーと書いていない場所は全てパススルーをoffにしましょう。これに加えてLAN同士を接続する場合は、PPPoEルーターIPv6機能自体を完全にoffにしたほうが良さそうです。下手するとループが発生してネットワークがダウンします。

②③に関しては、パススルーじゃない方のルーター(上記なら2)のWAN側とLAN側が同じネットワークにつながれているので特にループが発生しやすく、注意が必要です。Buffaloのルーターは初期設定のままだとWAN側とLAN側のMACアドレスが同じに設定されているので問題になるらしいです。WAN側を変えられるので変えましょう(参考: 疲労コンパイル: v6プラスとIPv4(PPPoE)を併用する(その1)など)。どこで読んだか忘れましたが、WAN側のデフォルト値に+1や+2したMACアドレスもLAN側のWi-Fi用などに使われている(設定画面見ればわかりますが)ので、-1した数値を入れておくのがいい(あるいは念の為もう少し減らしてもいい?)ようです。

また、ルーターによってはちゃんと設定していてもループして不安定になってしまうことがあるようです。たとえば自分のケースでは、上記②において、ルーター1にBuffaloのWSR-1166DHPL2、ルーター2にAterm WX1500HPを使って、さらにLAN側にブリッジモードでELECOMのWRC-1167FS-Bを接続していたのですが、この状態で新規にWRC-1167FS-Bに接続しようとするとつながらず、それと同時に上位のBuffaloも不安定になるという現象が起きました。PCから有線で接続した場合などは問題ありませんでした。また、ELECOMにつなぐ場合でもPCからだとうまく行く場合もありました。Buffaloはそのままで、ELECOMとAtermを入れ替えたらうまく動作するようになりました。その状態でさらにBuffaloとAtermを入れ替えても同じく大丈夫でした。また、最初の状態からELECOMはそのままで、BuffaloとAtermを入れ替えても大丈夫でした。従って、Atermが犯人なのではないかと思います。ちなみに、v6プラス:HGW環境でPPPoEを併用して全ポート解放を自由行う(ルータ併用編) : 駄文置場では、AtermとBuffaloについてはちゃんと設定してもループで不安定化してしまったようだという報告があります。Buffaloについてはこの方がMACアドレスの変更をしていなかったのだとすると自分の結果とも一致します(BuffaloのMACアドレスを初期設定のままやったら自分のところでも不安定化しました)。というわけで、PPPoEルーターとしてはAterm以外を使うことをお勧めします。余談ですがELECOMのこの機種は脆弱性があることが発表されており、アップデートもないので、少なくともWANに晒されるPPPoEルーターにはお勧めしません。

ちなみに、他サイトにはあまり載っていなかったので正当なのか若干不安がありますが、以下のようにルーター1のLAN側からスイッチングハブ(=L2スイッチ、ハブ、HUBなどとも書きます)で2本のケーブルを分岐させてルーター2のWAN・LANに接続してもループなどは起こらず問題なくつながるようです(各種確認でも、ルーター1のLANポートに直接繋ぐかHUBを使うかで動作に差が出ることはありませんでした)。

これはつまり、ルーター1とルーター2の間に2本の完全に独立したLANケーブルが無くてもよく、ルーター1とLANケーブルでつながっているところからはどこでもPPPoEルーターを生やせるということになるので、配線の自由度が増します。IPoEルーターは光コンセント/ONUの近くに置くしかありませんが、PPPoEルーターはそこから有線でつながっている好きな場所に置くことができます。一つ前の配線だとそうはいきません。

②に関して、ルーターによっては、IPoEルーターとしての使用時にPPPoEパススルーができないことがあるらしいので購入時には注意してください(IPoEとPPPoEを併用してみる|天文と気象とその他いろいろ楽天ひかり回線でIPoEとPPPoEを併用 | MYモノコトブログなど)。

PPPoEとIPoEの併用: パススルーのリスクなどについて

上記の③の配線は実はちょっと問題があります。

この場合、②のときの図においてIPoEとPPPoEが逆になり、PPPoEパススルーがIPv6パススルーに変わります。このルーター1のIPv6パススルーは、ルーター2がIPoEで接続するために不可欠なものです。しかし、文字通り全てのIPv6通信がルーター1を素通りできることになるので、LAN側にあるPCなどのIPv6アドレスがわかればインターネット側から誰でもそのPCにアクセスできてしまいます。もちろんファイアウォールなどがあれば簡単に攻撃はできませんが、リスクが上がることは確かです。従ってこの配線は避けた方がいいのではないかと思います。

一方で、PPPoEパススルーを使う②の方法は、状況は似ていますが、こちらは全部のIPv4通信を通すとかではなくてPPPoE通信だけを通すので、外側からアドレスを指定してLANの中にアクセスするとかは多分できません。なのでこちらは多分問題ありません。(あまり詳しく解説しているサイトがなく…)(IPv6パススルーが危ないかもというのは別のサイトにも書いてあります。疲労コンパイル: IPv6パススルーを許可した結果..PPPoE IPoE併用ネットワークでv6プラスを利用しながらサーバー公開│NANDゲートなど)。

①はパススルーする箇所がないのでこのような心配はありません。

ちなみに、PPPoEでの接続はルーターを介さず直接PCから行うこともできます。PPPoEを使いたいPCが一つしかない場合はそれもいいでしょう(PPPoEのセッション数は1とか2に制限されているので、複数あるならルーターにまとめるのがよい)。ただしこの場合はルーターによる防護がないのでIPv6パススルーのときと同様にファイアウォールなどによる対策が必要です。

また、ローカルルーターではなくPPPoEルーターやIPoEルーターとして設定するからには、各ルーターから見るとWAN側はインターネットなので、WAN側にある家の中のデバイスとは通信できない…かと思っていたのですが、IPv4では無理でもIPv6を使えばいけるという情報がありました(IIJmio ひかり: ひかり電話と IPv6(IPoE) + IPv4 over IPv6 (transix) を併用する)。IPv4にしか対応していないデバイスとかだとどうなのかわかりませんが、(IPv6対応の)ルーターで適宜設定すればできるのかもしれません。

例えばこれは③においてルーターのLAN同士をむすぶ線をなくしたものですが、これだとLAN2からLAN1にあるデバイスIPv4でアクセスすることはできなくなります。ちなみにこの設定だとLAN2側は何もパススルーしてくるものはないので安全です。

PPPoEとIPoEの併用: ひかり電話対応: HUBを使う場合

基本は上記のように割と自由にルーターを買ってきて配線すればいいのですが、ひかり電話HGWを使っている場合は注意が必要です。というのも、HGWよりWAN側の部分にはPPPoEやIPoEだけでなくひかり電話に関する通信も通っていて(HGWから電話線が伸びて家の電話機につながっていることからもわかる)、下手にいじるとそちらに干渉して電話が使えなくなってしまうからです。

上記①②③のうち、まず①に関してこの節で述べます。

①の場合、ONU(またはモデム)からHGWに伸びているLANケーブルの間(一体型ならUNIのところ)にハブを入れて分岐させることになるので、ひかり電話に干渉する可能性があります。これに関しては、普通に上手くいく/いったというような報告のほうがどちらかというと多いのですが、HGWと別のルーターとでIPv6通信に関する競合が発生して電話が使えなくなるという話もあり、緊急時の連絡手段でもある電話が使えないのはさすがに困るので自分はやりませんでした。以下に様々な報告を載せます(リプライツリーを読む必要があるものもあります)。

・できるという話

江添亮 on X: "@okada_k うまく動きました。なぜハブを使うことを思いつかなかったのだろう。" / X

Kanji Okada on X: "UNIのEthernetポートを(独立した)HUBに接続し、そのHUBからRTX810とレンタルルーターのWANポートへ接続し、レンタルルーターはひかり電話アダプタ専用として設定すれば、ひかり電話もRTX810によるインターネット接続も両立できる。とだけコッソリ書いておこう。" / X

ヤン on X: "図解できてないな…わかりにくい ひかり電話を使うためにひかり電話ルータを使ってるけどUNI出ししてる https://t.co/M1I7o3fF6r" / X

ヤン on X: "https://t.co/sLInv3b79X これの18ページ 適当に UNI 出ししたのをスイッチングハブで分岐するだけでネットワーク分離できる理由がわかったかもしれない" / X

こて on X: "@yuutosi_hiyuu うちの家だとひかり電話使ってるんだけど、これUNIポートから内部のルーター基板に繋がってる青色のLANケーブル抜いちゃうとひかり電話使えなくなるよね…?" / X

FUJINO Masaaki on X: "UNIを分離して、HUBからルータとひかり電話を振り分ける方法もあるけど、機器を増やしたくないので、まずは何をあらめて、何をもっとも利用したいか仕訳して、ネットワーク構成図を作成しないとあかん。" / X

こたまご🥚a.k.a. ひなたん on X: "@nomuken いけますよー 1. HGWでPPPoEパススルーにして,HGWの下にRTXを置く方法 2. HGWの中に入ってるONUから一旦ケーブルを出してきて,ハブでわけて,HGWとRTXを並列 につなぐ方法 1が一番らくかな" / X

こるで on X: "@WD_DRG ONU+ルーターなら、UNIポート→HUB→市販ルーターって分岐できるよ。HUB→レンタルルータって結線すればひかり電話も使えるし。" / X

Ryan on X: "@exp_noto ひかり電話使いたいんでUNI出しやめました もしかしてUNI出しで電話使えます?" / X

・できないという話

internet - Speaker Deck

くろがねッと☆ on X: "未だに体調は復活せず。ぐったりんぬ。 みかか系でDS-LiteがうまくいかないのはHGWが古くて対応してないからじゃないかな〜と思案中。 UTX100はDS-Lite対応してるらしいが、光でんわ使う場合はHGW経由が基本になるからなぁ。ONUからHUB経由で二股並列接続だとうまくいかないらしいし。" / X

きゅう(TOQ Kyusen-K) on X: "色々ググって、HGWをUNIから外してルーター直付けすれば市販ルーター使える的なの見たけど、それでは電話が使えなくなってしまうんよね。仕方なくHUBで元のHGWも分配して使うとかなると、今度はIPの取り合い起こして繋がらなくなるらしいので、もう諦めて二重ルーター覚悟するしかない。" / X

ArmGadge(あーむがじ) on X: "ひかり電話ルーターのONU部からルーター部の間にスイッチングハブかますと、ひかり電話が使えない。ただ、ルーター部の起動後に一度UNIポートからルーター部に直繋ぎして元に戻すと、何故か使えるようになる。一体どういう挙動なんだ?ひかり電話の仕様に詳しい人おせーて" / X

RYo on X: "@i10ug HGWがフレッツNGN内での識別に使われてるv4とv6両方持っていってつなぐなタイミング等で使えたり使えなかったりした記憶がある... HGWでPPPoEパススルーできるならONU→HGW→ルーターの方が良いとは思います。" / X

ZOOT NATIVEの接続が1日数回、または約3時間おきに切れてしまう場合の対策を教えてください。

使えたり使えなかったりするというのが一番怖いですよね…。

ひかり電話IPv4だけしか通らない状態にしてやると(中途半端にIPv6が使える状態よりもむしろ?)問題なく動くのでIPv6をフィルタしてやるとよいみたいな話もあります。これはかなり大胆なやり方なようです。

2017-02-19: フレッツ光ネクスト (ひかり電話あり) 回線において、ひかり電話と自前の設備を IPoE IPv6 的な意味で仲良くさせる

カフェイン未摂取 on X: "@Ra1nyJun 最後のおまけページみたいにIPv6のフィルタをかけた状態でHUBでHGWにひかり電話ルータも刺してやれば使えますね(たぶん)。その後、直接電話を挿すなら電話買わないといけないし、イーサネット経由でならIP電話もたぶん使えます(これだと設定しないといけないから面倒)" / X

かなぽん on X: "@ysks なんかそうらしいですね…。 ひかり電話自体はIPv4で動いているらしく、HGW上ではDHCPv6-PDがオフにできないので、L2スイッチにてIPv6通信を完全に切る方法があるらしいです🤔🤔 https://t.co/1JoKEQhBbm" / X

あるいは、YAMAHAの製品のようにそれ自体でひかり電話をサポートしている(=HGW(のルーター部分)の完全な代役になれる)ようなルーターを使うという方法もあり、コストはかかりますが明快な方法ではあります。

あとは、上記の手法の組み合わせ?的な感じかもしれませんが、ひかり電話対応のYAMAHAルーターIPv4だけしか通らないようにして利用する?的な記事もあります。

フレッツ光 ひかり電話を使いながら、IPoEのIPv6を自前ルータで直収する方法 - notokenの覚書

また、全然わかっていませんが、DHCPv6-PDを再委譲する?とかいう手法もあり、こちらのほうが技術的により高度ですが安定動作するっぽいです。

paina on X: "@pana_pana_kuma よろしければ,確認させてください。 何かのノードで NGN(網)から DHCPv6-PD で一度 /56 を貰う。そのプレフィックスの一部(/58 とか)を Vendor Specific Information を NGN のまねしてつけて HGW に DHCPv6-PD で投げる。 これで,HGW の電話機能を生かしたまま,HGW を通さず v6 通信できる?" / X

自分にとってはハイリスクローリターンな気がしたのでこれらの手法は試していませんが、併用うんぬん以前にひかり電話HGWとかいうよくわからん低性能っぽい機械を使わされているのが気に食わない(けど固定電話は欲しい)という人はこれらの手法を取ることになります。

PPPoEとIPoEの併用: ひかり電話対応: HGWのLAN側につなぐ場合

一方で、②③のように配線する場合、上位のルーターとしてひかり電話HGWを使うなら、ONU(orモデム)からHGWまでの配線には手を加えなくてすむので、ひかり電話に干渉することはありません。

HGWが300番台以上でMAP-e系を使う場合などは、HGWがIPoEルーターとして使えるので、②を採用できます。つまりHGWが上の図の「ルーター1」になり、その下に市販の「ルーター2」を付ければいいことになります。自分の環境も最終的にはこれになりました。

HGWが200番台の場合、400番台以下でDS-Lite系を使う場合、300番台でもMAP-Eでポートの開放をしたい場合、MAP-Eで64個を超えるポートを開放したい場合などは、(適宜、IPv4 over IPv6の無効化を設定あるいはプロバイダに配信停止を申請した上で)、PPPoEルーターとしてしか使えないので、③を採用せざるを得ず、IPv6パススルーのセキュリティが気になります。この場合は、HGWでPPPoEを無効化してPPPoEとIPv6どちらもパススルーに設定し、HGWの配下でさらに上記の①②③のような配線をするという方法が有効です。以下に①②の場合の図を載せます。これは他サイトにはあまり載っていない方法です。

まず①の場合です。このときはHGWをハブのように見立ててそのLAN部分にルーター1、ルーター2を並列にぶら下げてさらにLAN同士を結ぶという形になります。ただ、壁に1本しかLANケーブルが通っていないとなるとHGWとルーター1とルーター2を近くに配置せざるを得ず、ルーターが両方とも無線だった場合に無線能力が無駄になります。

次が②の場合です。この場合、HGWの直下にまずPPPoEパススルーのIPoEルーターをぶら下げて、その下にPPPoEのルーターをつなぐことになります。PPPoEを2箇所でパススルーしているなどちょっとトリッキーな3重ルーター構成ですが、ちゃんと動きます。前述の通りルーター1からHUBで分岐させてルーター2につなぐ方法も使えるので、ルーターを離して配置しやすいです。自分の環境でも1~2週間ほど、その配線で運用していました。ポートの開放もIPoE/PPPoE共に問題ありません。

もちろん、YAMAHAルーターなどがあれば、ルーターを2つ使わずとも、HGWの下に配置するだけでIPoE/PPPoEの併用ができるようになります。

なお、この節で述べたような配線を採用した場合は、やはりルーターの外側はインターネットなので、HGW(や、HGWのLANポートにつないだ他の機器)にLAN側からIPv4でアクセスすることはできなくなると思います。IPv6ならいけるのかなと思いますが自分では未確認です(前述のIIJmio ひかり: ひかり電話と IPv6(IPoE) + IPv4 over IPv6 (transix) を併用するも参照)。

ポート開放: 制限の回避などについて

IPv4 over IPv6では一部のポートしか開放できないため、特定のポートを使用するように決め打ち(ハードコード)されたゲームなどは動かない場合がありますが、ポート変換によって回避できる場合もあります。

まず、サーバー側(ポート開放する側)では、多くのルーターがポート番号の変更に対応しているので、それで対応できます。すなわち、外にむけて開放するポートは8080でも、そのポートに外からアクセスが来たらローカルのPCの80番にアクセスするようにするといったことができます。(ルーターによっては同じ番号しかできないこともあるので注意)

また、クライアント側でも、例えばWindowsでは

> netsh interface portproxy add v4tov4 listenport=80 listenaddr=0.0.0.0 connectport=8080 connectaddress=example.com

みたいにすればそのPCの80番にアクセスしたときにexample.comの8080番にアクセスしたことになるみたいなのができるようです。ただしこれは全ての場合にちゃんと動くかはわかりません。自分でもあまりわかっていないので詳しくは他サイトをご参照ください。

他にはTCPだったらSSHのポートフォワードなども考えられます(UDPは非対応)。

使っているポート番号が非公開・ランダムだったり、大量のポートの開放が必要だったりするとどうしようもありません。PPPoEを併用しましょう。

あと、補足ですがWindowsでポート開放が確認できないときは、接続しているネットワークが「パブリック ネットワーク」になっているせいだったという場合が結構多いので気を付けてください。

記録: ドコモ光のプロバイダの変更手続き

最初のほうで述べたように、自分はドコモ光のプロバイダをhi-hoから「OCNインターネット」に変更する手続きを取りました。

プロバイダ変更の手続きはドコモショップでしかできないと書いてあることもありますが、自分が見たとき(2023/09)はWeb上に申し込みフォームが出来ていたので、おそらくごく最近Web申し込みに対応したのではないかと思います。しかしこの記事に書いたことも含め色々疑問点があったので自分はドコモショップに行きました(9月末)。どちらにしても契約事務手数料3,000(税別)がかかります。

ドコモショップでは切り替え日をいつにするかと聞かれて、12日後くらいの日付を提示された気がするので適当にOKしたかと思います。ただ、新しいプロバイダ(OCNイ)の契約に関する書類はそれより前のタイミングで届くと思う、と言われました。

実際に申し込んでからちょうど1週間後には家に契約書的なものが届き、そこにPPPoEアカウントが記載されていました。また、「サービス開始の予定時期」は「ドコモ光のご利用開始日に準じます」と書いてありましたが、今回はドコモ光の中でのプロバイダ変更であってドコモ光自体はずっと使っているのでよく意味が分かりません。ならもう使えるのかということでPPPoEアカウントを入力してみたら普通につながりました。このタイミングではhi-hoとOCNのPPPoEアカウントが両方使えていたということになります。なお、この10日後くらいにもう一度hi-hoのアカウントがつながるか試してみたら、まだつながりました。ある程度余裕を持って設定しているようです。結局、PPPoEに関しては、その「切り替え日」のタイミングでは何も起こりませんでした(何かが送られてくることも、何かが使えるようになることも、何かが使えなくなることもなかった)。

ただ、IPoEの開通確認(及びPPPoEとの併用確認)については何日か後になってしまいました。最初から使えていたのかもしれませんが、切り替え日のタイミングでIPoEが通るようになったという可能性もあります(IPoE認証の仕組みを考えてもこれは割とありそう)。ちゃんと確認すべきでしたね…

なお、この記事ではIPoEに関してかなり多く書きましたが、PPPoE同士で比べてもhi-hoからOCNインターネットへの移行で劇的な改善が見られました。どちらも昼間はパケットロス0-1%、ping10ms程度で十分快適ですが、hi-hoでは21時台になるとパケットロスが6-8%、pingが50-60msくらいになるのに対し、OCNイではpingが15-20msくらいになりますがそれほど変わらず快適に使えていました。

あと、hi-hoの退会についてですが、ドコモショップに行く直前に電話したところ、ショップで切り替え手続きをしたら数日後にはドコモ側から切り替えの連絡がhi-hoに入るので、その後のタイミングで10月末までにまた改めて連絡してくれれば追加の請求なく退会できるとのことでした。これも後日問題なくできました。

記録: HGWの交換及びひかり電話のタイプ変更

前述の通り、自分の家にはRT-200NEが設置されていましたが、IPoEとPPPoEを併用しやすくするためには新しい機種に変更が必要でした。

まず、プロバイダを変更する前に、実は自分のRT-200NEについてはDHCP不定期に機能しなくなるという不具合があったのでそれを口実に新しいものに交換できないかと問い合わせました。しかし、113番の故障担当の窓口でオペレーターにつながらず、向こうからの電話を待つ予約を入れるくらいしかできなかったためこの日はとりあえず諦めました。

次に、プロバイダ変更の申し込みを終えた後、OCNインターネットからの契約書が届くより前くらいのタイミングでまた113に電話しました。ただしこんどは交換の理由としてはIPoEを使えるサービスに乗り換えるからということをメインで説明し、最後に補足としてDHCPの不具合について説明しました。

すると、「故障でなく機能不足での交換なので別の窓口につなぐ」「故障扱いでの交換だと同じ機器との取り換えになることがあるので、新機種が必要ならそのように手続きしたほうがいい」とのことだったので従いました。なるほど(それにしてもRT-200NEの故障でRT-200NEをもう一度送ってくるんだとしたら面白すぎる…)。ちなみにこの「別の窓口」というのは15715番でつながるものと同じだったようです(電話の最後に確認しました)。

で、その15715番のほうで、RT-200NEだとIPoEが使えないので交換したいと言ったところ、契約状況を確認してもらった上で「今はプロバイダ変更の手続きが入っているので交換手続きができない。そちらが完了してからにしてほしい」「お客様の機種(RT-200NEのこと)であれば無償交換になるはず。ただ、新しい機種を送付する形で済めば無料だが、こちらのシステムの判定でどうしても作業員を派遣して工事を行う必要があるとなった場合は派遣手数料6,600円がかかる」と言われました。なるほどなるほど。急ぎすぎだったようですが、交換は無料でやってもらえる可能性が高そうです。とりあえずその日はそれ以上なにもできないので終わり。

そして、プロバイダ変更が完了してIPoEとPPPoEの併用テストも終わって落ち着いたタイミング(正確にはOCNインターネットの契約書が送られてきた9日後)で、改めてまた電話しました(今度は直接15715番に)。IPoEに対応したものに変えたいと言って、現在の機種名すら伝えていなかったのですが、無償交換するので最短だと5日後に新機種及び旧機種の返却キットを送り、6日後に切り替えという形になると言われたので、それをお願いしました。無事、工事が必要という事態になることは避けられました。切り替え日は0:00で切り替わるのかと聞いたら、9:00-12:00くらいに切り替わるとのことで、よくわかりませんがまあとりあえず大丈夫だろうということで、それ以上は聞きませんでした。切り替えより前に接続したらどうなのか聞いたら、使えないと言われたような気がします。機種が何になるか聞いたら、たぶんRT-500かRX-600になる的なことを言われました。また、このときに「ホームゲートウェイでの利用にはフレッツ・ジョイントというものが必要で、それが使えない場合もあるようだが、大丈夫なのか」的なことを聞いたら、「こちら側で手続きを行う」的なことを言われたので、これも完全には腑に落ちていませんが、とりあえず大丈夫だろうということにして電話を終えました。

で、少し時系列が戻るのですが、この電話をする直前、0120-116-116に電話してひかり電話のタイプ1/タイプ2を確認しようとしました。しかし、固定電話の番号を伝えたら、「そのような契約が確認できなかったので、プロバイダと契約している場合はそちらに連絡してほしい」と言われました。この時にようやく、光コラボの場合は0120-116-116に電話するのは間違いだということを知りました。

それでさっきの機種交換の電話を終えた後、やはり自分の契約がタイプ1なのかタイプ2なのかは気になるので今度はドコモ光の151番に電話し、タイプはどちらなのかと聞いたら、「現在、タイプ1からタイプ2への変更手続きが入っている状態になっている」という返答でした。つまり、さっきの機種交換の申し込みによってタイプ2への変更手続きがとられたものと推測できます。正確にどの手続きによってトリガーされたものなのかまでは聞きそびれてしまいましたが、プロバイダ移行手続きをしたのはしばらく前であり、OCNインターネットのサービスも9日前から使えていたことを考えれば、おそらくそういうことでしょう。つまり、ひかり電話(ドコモ光電話)がタイプ1である状態でIPv4 over IPv6対応のHGWへの交換を申し込んだため、その利用開始には物理的な機種交換とあわせて(フレッツ・ジョイントのために)ひかり電話のタイプ変更が必要とドコモ光側が認識し、NTT東日本に対してタイプ2への変更を依頼する手続きを行ったものと推測することができます。一応、電話でも「これはドコモ光の側からNTT東日本に対してタイプ変更を依頼したという理解でいいか」と聞いたらそんな感じかと思われますという答えが返ってきました。

この電話により、自分のひかり電話の契約はタイプ1で、おそらくOCNインターネットへのプロバイダ移行後もそのままだったこと、その状態でもOCNバーチャルコネクトが使えていたことが明らかになりました。

NTT東のひかり電話を間接的に提供している他の光コラボでも、v6プラスやHGW利用でのIPv4 over IPv6などタイプ2が必要なサービスを申し込んだ場合は、プロバイダ側が代行してタイプの変更を申し込んでくれるのかなと思いますが、これに関する情報はほとんど見つかりません(プロバイダ側がわざわざ利用者側に伝える必要がないので書いておらず、実際にそれでうまく行っているので利用者側の話としても出てこないということかもしれません)(ただ、似たような状況の「フレッツ・v6オプション」に関しては割と書いてあるのですが…)。しかし「v6プラス」の手続きをしたい (お客さまIDが「COP」で始まり、2014 年 9 月以前にひかり電話の契約をしている場合) | 会員サポート | So-netのように、明示的にプロバイダ側へのタイプ変更の連絡が必要そうなケースもあります。

で、5日後になって新HGWのRX-600KI及び旧機種の返却キットが届きました。最新型なのでラッキーです。返却キットはただの紙袋で、返送用の配達依頼書みたいなのもついています。RT-200NE本体と電源アダプタと緑色のLANケーブルを返せば良さそうです。

RX-600KIのほうは取扱説明書の一式がついていました。しかし、今回の切り替えに際しての設定方法の案内などは一切ありませんでした。とりあえず、PCとケーブルで直接つないで管理パスワードなどの最初の設定を終えます。で、フレッツ・ジョイントを受けるためにはPPPoE接続をしておくと良さそうなので、IPoEルーターの下にぶら下げていたPPPoEルーターを外し、かわりにHGWをPPPoEで接続しました。同じLANには入れていません(経過措置なのでループなどの面倒ごとを避けたかった)。この時点でHGWにはPPPoEに関する設定が全て残っていて、RT-200NEとはあまり変わらない感じです。ただし、フレッツ・ジョイントのhttp://192.168.1.1:8888/t/が見れるようになっていました。中身は何も配信されておらず空っぽです。あと違うのはIPv6 PPPoEの項目が増えたくらい。この状態でフレッツ・ジョイントが来るかなと一応待ちましたがその日は結局何も起こらなかったので、まあ切り替え日は明日だしということで寝ました。後述しますが、このPPPoEが使えているタイミングで「IPv6パケットフィルタ設定(IPoE)」を「高度」にするのをやっておくと若干手間が減ります。

翌日、言及のあった9:00を30分ほど過ぎてもいっこうに接続状態が変わらないので、やや拙速ですがまず15715に電話して、IPoE対応のHGWに変えたがフレッツ・ジョイントが来ていない(要約)と伝えました。しかし、工事に関する手続きの窓口なので技術的なことはちょっと…と言われて、プロバイダ側とか、0120-825-360に電話してくれと言われました。しかし後者は調べたら有料だったので、プロバイダの「OCNテクニカルサポート」に電話しました。

ここのサポートはテクニカルと銘打っているだけあってかなり話が通じる感じでした。配線についての説明を終えたら、新しいHGWの利用登録が終わっていないっぽいのでそれをする必要があると言われ、さらにNTT東西どちらか聞かれ、東と答えたらひかり電話がタイプが1か2かわかるか?と聞かれたのでHGW交換の直後に電話したときに1→2に変更中と言われたと答えました。回線ID(COP********)なども聞かれました。諸々確認してもらったようで、おそらくタイプ2であることも確認できたのか、「これから登録をしておくので、20-30分くらい経ったら設定が変わっているか確認してくれ」と言われて電話が終わりました。

その後HGWを眺めていたら、電話が終わった30秒後くらいに、目の前でPPPoEランプが消灯しました(11:30頃)。PCから確認すると、めでたくPPPoEに関する設定が消滅しており、192.168.1.1:8888/t/を見るとOCNインターネット関連のソフトウェアの項目(調べればでてきます)が出現していました。バージョンは4.0.3で、ポート開放の設定もありました。

一応、15715の担当者が言及していた切り替え時間帯が終わる12:00より前だったとはいえ、このOCNへの電話によってはじめてフレッツ・ジョイントの配信が有効化した可能性がかなり高いので、15715でのHGW交換に伴う切り替え対応が十分だったかは大いに疑問が残ります。とはいえ無事にフレッツ・ジョイントを受けられたわけなので、これでひかり電話のタイプ2への変更も完了したことが確実になりました。

このタイミングで、「IPv6パケットフィルタ設定(IPoE)」が無いことに気付きました。動揺したものの、モデム直下につないでいないのでひかり電話契約が無い扱いになっていて表示されないという可能性に思い至りました。すぐにモデムにつないでもよいのですが、「高度」にした状態でつなぎたかったので、一旦OCNバーチャルコネクトを無効にしてPPPoE接続ができる状態にして「IPv6パケットフィルタ設定(IPoE)」を復活させ、「高度」に設定し、もう一度OCNバーチャルコネクトを有効化しました。

そしてVDSLモデム直下に接続し、電話線も含めて完全に接続を切り替えました。このタイミングでRT-200NEは引退ということになりました。PCから確認すると、ちゃんと「IPv6パケットフィルタ設定(IPoE)」が復活しており、「高度」になっていました。一旦外していたPPPoE用ルーターを再びLANに入れ、これにてプロバイダ移行作業は完了しました。

結論

ドコモ光を使っているならOCNインターネットはタイプAで月額利用料が安いのにIPoEとPPPoEが併用できるしPPPoEの質もまあまあなのでオススメです。

あとPPPoEルーターをHUBから下げてLANに入れる配線もオススメです。

mpvとギャップレス再生について

mpvとは

メディアプレイヤーの一種である。おおよそこの世にあるほとんど全てのメディア形式に対応しており、オープンソースで開発されている。UNIX系でもWindowsでも動作する。また、バックエンドのAPIがlibmpvとして公開されており、これを使用する派生メディアプレイヤー(フロントエンド)も多く存在する。

ギャップレス再生というのは、楽曲間に無音時間を生じさせることなく再生する機能のことである。ファイル形式にもよるが、きちんと対応しているソフトウェアは意外と少ないなかで、mpvの対応状況はほぼ完璧に近いものと言えるだろう。

Windows向けビルド

Linuxを使える人にインストール方法の説明は不要だろう。Windows版はhttps://sourceforge.net/projects/mpv-player-windows/files/ からダウンロードできる。Weeklyビルドのほうがよくダウンロードされているようだが、ギャップレス再生に問題があることがあった(一時的なものかもしれないが)。changelogはあまり追っていないがreleaseにあるもの(2022/11/04時点で最新はほぼ1年前の0.34.0)でもそうそう不便はしないだろう。なお、設定ファイル(mpv.conf)は、mpv.exeと同じフォルダに入れておけばいいようである。

UIの改善

筆者の個人的な印象では、mpvの最大の欠点は(クリックで該当曲を再生できるような)プレイリスト画面がないことである。libmpvを使用する各種フロントエンドの中にはプレイリスト機能を持つものもあるが、その分ギャップレス再生の対応が怪しいものも多い。mpv.netなんかはそこそこ知名度もあるようだが、音量が小さくなっている気がするし、ちょっと怪しそう。Linuxを使用しているのであれば、お勧めはcelluloid(旧称GNOME MPV)である。ただし(他の多くのフロントエンドにも共通するが)標準入力からのデータ受け取りはできないことに注意。Windowsにはあまり良いものがないが、https://github.com/mpv-player/mpv/issues/5500 で紹介されているhttps://github.com/tomasklaen/uoscLuaで書かれたUIのプラグイン(?)で、mpv.confと同じ場所に展開すれば最低限のプレイリスト機能が使えるUIになる。

ギャップレス再生関係のオプション

以前は以下のようなオプションを指定しないとギャップレス再生されないことが多かったが、最近はデフォルトのままでもほぼ問題なく動く。ただしWeb上のリソースをギャップレス再生したい場合はprefetch-playlist=yesaudio-buffer=数字のどちらかを指定する必要がありそうである。上の3つは指定しておいても損はないだろう。数値は一例である。

詳しくは公式ドキュメント参照。

  • cache=yes キャッシュが行われる。キャッシュを表す線が表示される。
  • demuxer-max-bytes=5000KiB キャッシュの最大容量?
  • demuxer-readahead-secs=10 前読みの時間?
  • prefetch-playlist=yes Web上のリソース(HTTP等のリンク)を再生する際に予めリソースを取ってくることでギャップ発生を防ぐ?ドキュメントによると、highly experimentalな機能で、デメリットもあるらしい(例えばプレイリストが書き換わった場合などにうまく動作しない恐れがあるらしい)。後述のyoutubeのリンクに対しては無効。
  • gapless-audio=yes デメリットもありそう。デフォルトのweakで十分そうなので指定しなくてよさそう。
  • audio-buffer=2 曲の終了2秒前から次の曲の再生フェーズに切り替わる。Webリソースのギャップレス再生に有効。短すぎるとギャップレス再生に失敗する。
  • player-operation-mode=pseudo-gui CUIからの起動でもGUIを強制する。
  • fs=yes フルスクリーン表示になる。オプションが効いているかどうかのテスト用に使える。

YouTubeへの対応

内部でyoutube-dlを使用しているためYouTubeのリンクは(再生リストも含め)一通り再生できる。しかし、ギャップレス再生はできない。また、youtube-dlの最新リリース(2021.12.17)ではダウンロードが異常に遅くなる不具合が解決していないため、mpvでも問題が発生する可能性がある。

celluloidビルドメモ

余談だが、celluloidをWindows向けにビルドしてみたので、その際のメモを載せておく。

MSYS2の64bit版を入れる。READMEに書いてある通り基本的には

meson build && cd build && ninja && sudo ninja install

という流れ。

meson buildをするとbuildというフォルダになんかビルド用ファイルたちができる。この時点でライブラリが足りなかったら出るはずなのでそれを入れていく。全部ちゃんとMSYS2にある。MSYS2でダウンロードがうまくいかないときは--disable-download-timeoutを付けるといいかも。

次にninjaをする。どこで止まってるかよくわからんので、なんかのファイルにリダイレクトしてログを取って、そこで「error」で検索した。エラーが出るたびにその場しのぎの適当な修正をしていたら意外と通った。出たエラー一覧

  • いつ出たか忘れたが(最初のほうだったかな)、なんか色々とヘッダが足りんと言われるのでmeson.buildに global_cflags = ['-ID:/msys2/usr/include'] と追加する(この例ではD:\msys2にMSYS2をインストールしている)
  • struct flockが多重定義されている →後に出てきた方(usr\include\sys\_default_fcntl.hだったかな?)をコメントアウトした
  • glib-unix.hにある#error "This header may only be used on UNIX” というプリプロセッサ命令に引っ掛かる→コメントアウトした
  • celluloid-mpv.cにおいて、gdk/gdkwin32.hってのが見つからんと言われる →探したらgdk**/win32**/gdkwin32.hがあったのでそう書き換えた
  • mingw64/include/winsock.hにあるselectgethostnameの型が以前に定義されているものと違うと言われる→winsockが悪いと判断して以前のものと揃えた
  • (ldのエラー)undefined reference to `__stack_chk_fail'と言われる →meson.buildでgccの(リンカの?)オプションにfno-stack-protectorを指定する(ただし既に-fstack-protector-strongが指定されているのでそれを変更する形になる)
  • (ldのエラー)celluloid-application.cにおいてundefined reference to `g_unix_signal_add'と言われる →g_unix_signal_addが使われている3行(連続している)をコメントアウト(※これをするならglib-unix.h自体がいらない気がするので前述のglib-unix.hの編集も不要?)

結果として、videoは一切動作しない(動画は見れない)が、音声は正常に再生できるし、動画ファイルでも--video=no(celluloidのオプションとしては--mpv-video=no)を指定すれば中の音声は聴ける。しかし、他にも以下のような問題があり、残念ながら音声ファイルに関してもまだ実用に適するとは言えない。

  • 文字小さくて見えない→どうすればいいかわからん
  • mpvと違って再生終了後にウインドウ閉じない→--mpv-keep-open=no指定してみたけどだめ、これもわからん(これLinux版でも同じ?)
  • タスクバーのアイコンに再生の経過が表示されない(これはしょうがない)
  • 変なことすると落ちる

Windowsのパス長さ制限に関する挙動まとめ

パス長さ制限

Windowsが扱えるパスの長さは260(定数MAX_PATH)に制限され、それ以上の長さのパスをもつファイル・フォルダの操作に支障が出ることがある。

この制限はLongPathsEnabledというレジストリの値を1に設定することで解除できる。例えばPowerShell上で以下を実行すればよい。

Set-ItemProperty "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem" -Name LongPathsEnabled -value 1

また、現在の値を確認するには以下を実行する。

(Get-Item -Path "Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem").GetValue("LongPathsEnabled")

しかし、制限を解除すれば全ての操作が支障なくできるというわけではない。例えば、Windows APIのマルチバイト文字方式の関数(末尾がAのもの)は長いパスに対応していない(末尾がWのワイド文字方式のものは対応している)らしく、これを使用しているアプリケーションはこの制限を解除しても正しく動かない。またエクスプローラ上での操作性もほとんど改善しない。

これはあくまでWindowsの問題であってファイルシステムの制限ではないので、後述の通りエクスプローラ上でも例えばパス長さ260を超えるファイルを作ること自体は容易である。ネットワーク上のフォルダを閲覧する場合など、実際にWindows上で長さ260を超えるパスを扱う必要がある場面も多く、(制限を解除しなくても)ダブルクリックで開く程度の操作はできることが多い。

以下ではこの問題に関してさらに詳細な挙動を解説する。なお動作確認に使用したのは主にWindows10である。Windows11でも少し試したが、大幅な改善はなさそうである。

関連する公式のドキュメントとしては以下が参考になる。

https://docs.microsoft.com/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#file-and-directory-names

パスの形式について

今後出てくる様々な挙動を把握するために、ファイルに短い別名を与える仕組みである「8.3形式」およびパス長さ制限の回避に有効な「”\\?\プレフィックス」について紹介する。

8.3形式(短いファイル名)

古いWindowsのファイル名には「8文字以下の名前+ピリオド+3文字以下の拡張子」という長さ制限があった。また、空白を含む一部の記号も使用できない。この制限がなくなった(緩和された)現在でも、Windowsは制限を満たさないファイルに対してこの制限に基づく別名を自動生成する。これが「8.3形式」あるいは「短いファイル名」などと呼ばれるものである。例としては”Program Files”→”PROGRA~1” などがある。8.3形式の名前はコマンドプロンプトのdir /xコマンドで表示できる。

比較的新しいWindowsでは、fsutil 8dot3nameコマンドを使うことで、8.3形式の名前を生成するかどうかをシステム全体およびボリューム(Cドライブ、Dドライブ)ごとに設定できる。デフォルトではCドライブのみ有効になっているようである。

この別名を通常の名前のかわりに使用することで、現実的に多くの場合は長さ制限を回避できるだろう(もちろん階層が深すぎて「短いパス」でも長さ制限を超えてしまう場合などはできない)。また、パスに含まれる空白による問題も回避できる。

後述の通り一部アプリケーションはこれを積極的に使うことで長さ制限を回避しようとすることがある。この際は8.3形式を可能な限り多く使用したパス(可能な限り最も短いパス)が用いられるようである。

例えば8.3形式の名前がCでは有効、Dでは無効(つまりデフォルト設定)だったとする。Dドライブ直下に”longfoldername”という名前で”C:”へのジャンクションを作り、それを経由してC:\Program Filesにアクセスする場合は、”D:\longfoldername\PROGRA~1”が「可能な限りもっとも短いパス」ということになる。

「可能な限り多く」ではなく、短い名前をもつフォルダのうち一部のみを8.3形式としたパスがexplorerのアドレスバーなどで使われているのを見たような気もするが、詳細を記録していなかったため再現できず。

8.3形式は基本的には普通のパスと同じ扱いであるため、多くのアプリケーションが対応しているが、PowerShellなどは強制的に長い名前に変換しようとするため支障が出ることもある(後述)。また、4文字以上の拡張子は3文字に短縮されてしまうため、例えばWordの.docxファイルが.docファイルと混同されるなどの問題が生じる。また他にもシェルの入力補完で表示されないなど、通常のパスと比べて不便であることには変わりない。

\\?\プレフィックス

公式ドキュメントでも用語の定義がはっきりしないのでよくわからないが、パスの先頭に”\\?\”(検索しやすさのために書いておくと、バックスラッシュ(=円記号)2つ+クエスチョンマーク+バックスラッシュ1つ)というプレフィックスを付加すると”Win32 file namespace”というものにアクセスすることになるらしい。具体的にどうなるかというとWindows APIによるパスに対する各種のチェックが行われなくなり、結果として長さ制限を超えるパスを使えるようになる。ただし対応状況はアプリケーションによってまちまちである。

このパスはネットワーク上のファイルを指定するのに使われるUNCパス(UNCはUniversal Naming ConventionあるいはUniform Naming Conventionの略)の一種とも考えられる。UNCパスは「\\コンピュータ名\パス本体」という形式だが、この「コンピュータ名」の部分に?が入っているというわけである。ちなみに、元々UNCパスだったものにこのプレフィックスを付加する場合は\\?\UNC\コンピュータ名\パス本体とすれば良いらしい。

なお、クエスチョンマークの代わりにピリオドを使用した\\.\というプレフィックスもあり、これだと”Win32 file namespace”ではなく”Win32 device namespace”というものにアクセスすることになるらしいが、詳細は不明。長さ制限を回避するには使えないようである。

以降では便宜的に「“\\?\プレフィックス」を指して単に「プレフィックス」と呼ぶ。

ちなみに今回の話題とは無関係だが、connulなどWindows上で許容されない名前のファイルが削除できない際に、コマンドで\\?\\\.\を付けたパスを指定すると削除できる。

Explorerや各シェル、アプリケーションにおける挙動の変化

ここから具体的な挙動の変化を見る。特に記載がないものは、レジストリ値を変更して制限を解除しても変わりがないということである。

以下で「PowerShell」と呼んでいるのはバージョン5であって、6以降(実行ファイル名がpwsh.exeになって以降)では異なるようである。

8.3形式・プレフィックス付きパス等を扱えないアプリケーション

アプリケーションによって細かい挙動は様々だが、プレフィックス付きのものや8.3形式の名前が含まれるパスに関して不具合が出ることがある。はっきりエラーメッセージが出ることもあれば、何も起こらないこともあるし、空白の(ファイルを開いていない状態の)ウインドウが表示される場合もある。いくつか例を挙げておく。

  • Windows Media Playerプレフィックス付きのものや長さ制限を超えるパスを引数に渡すと起動しない(何も起こらず終了する)。
  • ペイント…プレフィックス自体は扱えるが長さ制限を超えるとプレフィックス付きであっても扱えない(引数として渡すと何も起こらず終了する)。
  • Word…プレフィックス付きパスを渡すと、起動はするが新規作成の画面になる。また長さ制限を超えるパス(プレフィックス付き含む)を渡すと「パス名が長すぎる」というようなメッセージを表示した上で新規作成の画面になる。また、”.docx”は拡張子が4文字以上であるため、短いパスとして渡されると不自然な動作になることがある(”.doc”、つまりWord 97-2003文書との混同が生じる)。
  • Visual Studio…8.3形式を用いて短くした.slnや.vcxprojを渡しても、元の(8.3形式を使わない)パスが制限を超えていると「パス名が長すぎる」というようなエラーが表示され開けない。

長さ制限を超えるパスをカレントディレクトリとして実行できないWindowsネイティブアプリケーション(?)

おそらくアプリケーション側の都合で、長さ制限を超えるパスをカレントディレクトリとしての起動に対応していないことがある。具体的には、Git Bashで、長い名前をもつフォルダを開いているとき、mspaintやcmdの実行に失敗する。次のようなメッセージが出る。

Error: Current working directory has a path longer than allowed for a
Win32 working directory.
Can't start native Windows application from here.

bash: /c/Windows/system32/mspaint: File name too long

しかし、同じ状況でgrep.exeの実行は成功する。従ってアプリケーションによって対応状況に差があるものと推測される。ただしこのエラーメッセージはGit Bashによるものであり、またGit Bash以外で違いを確認できていない(例えばcmdやPowerShellではmspaintもgrepシェル側の都合で失敗する)ので、例えばGit Bashが必要以上に多くのプログラムを勝手に”native Windows application”に分類している可能性などは残る。またgrep.exeのようなGit Bash付属の実行ファイル以外で起動できるものは確認していないので、判定条件がよくわからない。

カレントディレクトリを8.3形式によって短くできれば起動できる。

explorer

まず、以下の挙動については全てのフォルダで同様。8.3形式で短くできるものも含まれる。

  • 長さ制限を超えるファイルのリネームができない(元々超えている場合は短くすることもできない)
    • 超えていない場合、制限いっぱいになるとそれ以上入力できなくなる
  • 中にあるファイルのパス長が制限を超えるようにフォルダをリネーム・移動することは可能
    • これにより長さ制限を超えるパスをもつファイル・フォルダをエクスプローラ上で容易に作れる。逆に、長すぎてリネームできないファイルなども、外側のフォルダをいったん短い名前に変える・短い名前の場所に移動することで操作できるようになる
  • 長さ制限を超えてもフォルダを開くことは可能。

さて、explorerは、制限を超える長いパスに対しては概ね次のような原則で対処しようとするようである。

  1. 8.3形式の名前を使用して「可能な限り最も短いパス」を得て、これを使う。
  2. 8.3形式の名前がない、あるいはそれを使っても制限を超過するなどの場合は、パス先頭に”\\?\プレフィックスを付加する。

例えばexplorerのアドレスバーを見ると、このように動作していることがわかるだろう。あるいは、そのフォルダおけるexplorerの挙動はアドレスバーを見れば大体予測できるということにもなる。ファイルに関して調べたければ「パスのコピー」を使うとよい。なお、手動でプレフィックスや8.3形式の名前をエクスプローラのアドレスバーに入力して移動した際は、通常のパスに変換される(それが長さ制限を超えていれば改めて上記の対処が行われる)。

1のとき

ダブルクリックでファイルを開くことができるほか、右クリックメニューの「送る」「Codeで開く」(※VS Codeを適切な設定でインストールすると表示される)なども正常動作する。なお「PowerShell ウインドウをここで開く」は、動作するが、PowerShellは強制的に通常の(長い)名前を使おうとするため、カレントディレクトリとしては通常の名前が表示される(この先の挙動はPowerShellの項目を参照)。また、PowerShellを使用するよう設定したWindows Terminalをここで開くと、制限を解除した場合は通常形式のパスをカレントディレクトリとして正しく起動するが、解除しない場合はカレントディレクトリをC:\WINDOWS\System32\WindowsPowerShell\v1.0として起動する。

ファイルの新規作成は可能だが、フォルダを作成しようとするとエラーが出る。ファイルやフォルダを「ごみ箱に移動」できる。

2のとき

2に当てはまるフォルダでは、「Codeで開く」など外部プログラムを起動するような右クリックメニューの多くが動作しない(Explorer.EXEによる”ディレクトリ名が無効です。”とのダイアログが出る)。「開く」も動作せずファイルをダブルクリックで開くこともできない(例えば.txtがメモ帳に関連付けられた状態で開いてみるとよい)(※これに関してはWindows11で修正された模様)。ただしCOMを用いて実装されているメニュー(レジストリコマンドラインではなくUUIDが書かれているようなもの)は正常に動作するようである(例えば「映画 & テレビ」「フォト」のようないわゆる「アプリ」で開く場合)。

以下はCOMが用いられているか不明(未調査)だがその可能性が考えられる。

  • PowerShell ウインドウをここで開く」…正常に動作する。
  • 「プログラムから開く」…「開く」とは異なり、(アプリケーション側が対応していれば)正常に動作する。
  • 「送る」…Explorer.EXEのエラーは表示されない。ただし、特殊な方法(これもCOM?)で実装されている「ドキュメント」「デスクトップ (ショートカットを作成)」「圧縮 (zip 形式) フォルダー」メニューなどを除けば、選択しても何も起こらない。また、zipのメニューに関しても、最終的にzip作成には失敗する。なお、この「送る」に関しては、(2に当てはまるフォルダ内でなくとも)2に当てはまるファイルが一つでも含まれていると同様に動かないようである。

また、「新規作成」メニューにはフォルダの作成のみ表示されるが、なぜか”管理者マーク”が付いており、押しても何も起こらない。従ってファイルもフォルダも作れない。「ごみ箱に移動」は動作せず、delキーを押しただけで「完全に削除しますか?」と聞かれる(完全に削除することは可能)。

コマンドプロンプト

制限を解除した場合に限り長いパスを扱える(cdやdirが動作する)。また8.3形式の名前も普通に使える。

プレフィックスは、全く解釈できないわけではない(例えばrdコマンドの引数に使うことはできる)が、カレントディレクトリとしては許容されないようで、指定してcdしようとすると「CMD では UNC パスは現在のディレクトリとしてサポートされません。」と言われる。

外部プログラムを実行する際は、(制限が解除されていても)カレントディレクトリのパスが長いと判定したら「可能な限り最も短いパス」を代わりに使うようで、(それで制限以下の長さにできるフォルダであれば)正しく起動できる。

PowerShell

制限を解除した場合に限り長いパスを扱える点はcmdと同じである。しかし前述の通り、カレントディレクトリに8.3形式が使われるのを許容しないようで、強制的に長い名前に変換するため、しばしば奇妙な挙動を引き起こす。

例えば、カレントディレクトリのパスが200文字だったとして、そこに名前が100文字のフォルダがあったとする。いずれも実体はCドライブにあって8.3形式の名前が有効とする。このとき、パス長さ制限が解除されていなくても、8.3形式の名前を使えばcd自体はできる。しかしcdが成功すると同時にカレントディレクトリは長い名前に変換されるため、カレントディレクトリは300文字程度になり制限を超えてしまい、そこでのdirコマンドなどの実行は失敗するようになってしまう。

また、長さ制限を超えるパスがカレントディレクトリであるときに外部プログラムを実行すると、制限が解除されていない場合は「可能な限り最も短いパス」を使おうとするが、解除されている場合は長いパスをそのまま使おうとする(cmdとの違い)。結果として実行に失敗する。つまり、制限を解除した結果としてむしろ実行が失敗するようになるという状況が発生している。

プレフィックスには対応していて基本的な操作ができる。カレントディレクトリに設定するとMicrosoft.PowerShell.Core\FileSystem::\\?\C:\Usersのように表示される。

またカレントディレクトリがプレフィックス付きであるときに外部プログラムを実行するときは、不要な\\?\\\.\を除去してくれるようで、正しく起動できる。これは\\?\C:\Windowsのようなフォルダで正しく起動できるということであって、そもそも\\?\を付けないと扱えないような長いパスでの実行はいずれにしても失敗する。

また、(制限を解除していない状態だとしても)この際に「最も短いパス」を使用することまではしてくれないようで、Cドライブ上の長いパスに\\?\を付けたものをカレントディレクトリとしてnotepadを実行してみたが失敗した。

また、なぜかCドライブ直下を対象にしたcd \\?\C:cd \\.\C:はうまくいかない(cd \\?\C:\Userscd \\.\C:\Usersは成功する)。\\.\に関しては一旦cd \\.\C:\Usersなどしてからcd ..をするとCドライブにいけるがこのときはなぜか\\.\が消えてMicrosoft.PowerShell.Core\FileSystem::C:という表示になる。\\?\の場合はこれもできない。

Git Bash

git bashUnix由来のシェルであるためか、それ自体で長さ制限を超えるパスを扱う能力を持っているようである。従って制限を解除しなくても長いパスを扱える。また8.3形式の名前も使える。

「可能な限り最も短いパス」を得ようとするような動作はしないため、長いパスをもつカレントディレクトリでの外部プログラム実行は失敗する(前述の通り、Git Bash内蔵のgrep.exeなどは例外)。

Git Bashでは、\\?\\\.\//./は使うとエラーになり、//?/を付けた場合はcdには成功するが//?/が除去される。

結論

こうしてみると長さ制限を解除しても大した改善はないというのが実情である。

【マイクラ】ヤギの角笛を全種類集める方法について(叫ぶヤギの入手、自動回収装置)

Minecraft 1.17においてヤギという新しいmobが追加された。ヤギは特定の条件で「ヤギの角笛」というアイテムをドロップし、これはプレイヤーが右クリックで使用するとはるか遠くまで届く大音量のサウンドが鳴る。

この記事ではヤギを2匹見つけてから角笛を手に入れるまでの方法を解説する。特に角笛を落とさせるための装置は独自に考案したものであり、レッドストーンを使用しない簡易的なものである割に安定して動作するのが強みである。

誘導・保護

(繁殖にも使用する)小麦を使って誘導することができる。誘導の間はあまり突飛な行動はしないので他の動物と同じく容易に扱える。

ヤギは比較的入手が難しいmobであり、周りに(プレイヤー含め)他のmobがいる場合は突進の被害に遭うおそれもあるので、慎重な保護が必要である。5~10ブロック程度ジャンプする能力があるので、普通のフェンスや高さ2ブロックの壁では外に逃げられてしまう。高い塀を作るよりは、屋根(天井)を設けるのが楽だろう。長時間静止しなければ突進しては来ず、突進しなければ水平方向の移動は緩慢なので、出入り口は手動のフェンスゲートでも十分である。

叫ぶヤギの入手

ヤギには2つの種類があり、普通のヤギと、叫ぶヤギ(screaming goat)というのがいる。それぞれについて落とす可能性のあるヤギの角笛が4種類あるため、角笛は全部で8種類である。従って角笛を全種類揃えるには叫ぶヤギを入手する必要がある。

叫ぶヤギのスポーン条件は以下の通りである。

  • 自然スポーンのヤギは2%の確率で叫ぶヤギになる
  • 普通のヤギ同士の子は2%の確率で叫ぶヤギになる
  • 普通のヤギと叫ぶヤギの間の子は50%の確率で叫ぶヤギになる
  • 叫ぶヤギ同士の子はJava Editionなら100%、Bedrock Editionなら98%が叫ぶヤギになる

つまり、入手は普通のヤギより難しいが、1匹でもいれば増やすのは容易である。普通のヤギしかいない場合、自然生成のヤギを50匹探すよりはヤギを50匹繁殖させるほうがはるかに簡単であるから、小麦を使って増やしていくことになる。

やや問題になるのは、叫ぶヤギと普通のヤギの判別である。叫ぶヤギの声は人の声のように甲高くかなり特徴的で、これは子ヤギの時点から既にそうであるため、叫ぶヤギが産まれたにもかかわらず気づかないということはほぼない(サウンドoffの場合は、英語で字幕を表示するとgoat screamingと表示される)が、柵の中のたくさんのヤギの中でどれが叫ぶヤギなのか判別するのは難しい。

おすすめは、ダメージ音で判別する方法である。ボートに乗せて動けなくしておき、雪玉か卵を当てて音を聞けば、叫ぶヤギを確実に判別することができる(音声サンプルはWikiにある)。ただ、ヤギの数が多すぎると収拾がつかないので、叫ぶヤギが産まれるまではヤギ小屋の近くに常駐して繁殖を行い、成長した(普通の)ヤギは定期的に減らし、叫ぶヤギが産まれてすぐ、まだ子ヤギであるタイミングで子ヤギ全員をボートに乗せて判別を行うのがよい。

名札でもつけておけば、そこから叫ぶヤギを増やすのは簡単だろう。あるいは飼う場所を分けてもよい。特にJava Editionでは、叫ぶヤギだけになってしまうと普通のヤギをそこから得ることはできないので引き続き管理には注意が必要である。

角笛のドロップ

叫ぶヤギを増やせるところまで来たので、角笛に関する仕様を説明する。

ヤギは動いていないmob(と防具立て)に不定期的に突進する習性があり、この途中で(目標が移動するなどして)壁にぶつかった場合はヤギの角笛(goat horn)というアイテムを落とす。この際、壁は自然生成されるブロック(石、原木、一部の鉱石)である必要がある。

一応、プレイヤーが的になって突進が当たる直前に避けるという方法もあるが、突進の速度が速いためかなり難しい。叫ぶヤギは突進を行う頻度がかなり高いのでまだやりやすいが、普通のヤギでは1つ落とさせるだけで日が暮れてしまう。

そこで今回使うのは、mobの経路探索を攪乱するための定番アイテムともいえるトラップドアである。上付きトラップドアは開いた状態にしても地面だと認識されるので落とし穴に使えることで知られているが、実は下付きトラップドアも開いた状態にしてもそのまま地面のように認識されるようである。つまり、実際にはトラップドアが障害になって通れないにもかかわらず通れると誤認させることができる。

開いた下付きトラップドアの先に防具立てを置いておけば、ヤギはそちらに向かって突進するが、トラップドアに当たるのでその上に乗ることになる。そこで、そのときにヤギの頭が当たる位置に前述した石や原木などのブロックを置いておけば、角笛を落とさせることができる。

突進は、ある程度の距離(5ブロック以上程度)がないと行われないため、正方形の囲いであれば角に置いておくのがいいだろう。

設置例

効率は結構よく、普通のヤギだとしてもゲーム内で1日くらい待てば多くのヤギが2本とも角をドロップしてくれる。回収装置が付いていないのが課題といったところである。

あと、マイクラにはsouth-east ruleというのがあり、南東方向だとmobの当たり判定が狂ってフェンスから逃げたり壁に埋まって窒息したりといったバグがよく起こるらしいので、この装置は北西の方角に設置したほうがよさそうである。実際、手元では特に南や東方向に設置したときに、ヤギの頭がブロックに埋まってしまって窒息する例がみられた。

Windowsでsshfs(トラブルシューティング等)

はじめに

sshfsとは、リモートのsshサーバー上のディレクトリをローカルにマウントすることができるLinux(UNIX)用のソフトウェアです。Windowsでも同等の機能を持つSSHFS-Win(https://github.com/winfsp/sshfs-win)というソフトウェアがあるのですが、使うにあたっていくつかつまずいたポイントがあったので記事に残しておこうと思った次第です。

前提知識

sshを用いたリモートサーバーへの接続(鍵ペアの作成、sshのconfigの書き方など)に関してここでは解説しませんので、他の記事をご覧ください。この記事ではssh server1と打つ(&適宜、パスフレーズなどを入力する)ことでマウント対象のサーバー(server1)にアクセスできるようにconfigで設定してあることを前提にします。さらに、公開鍵認証を想定にし、パスワード認証に関しては扱いません(ただ、むしろ公開鍵認証でうまくいかないという投稿を多く見る気がするので、パスワード認証でも大きく変わらずできるとは思います)(コメントなどで要望があれば試してみるかもしれません)。あと、WSL関係も試していません(これも要望があればやるかも)。

なお、configで予め設定しておかなくてもSSHFS-Winにsshのオプションを渡すことはできるのですが、トラブルシューティング時の原因の切り分けが面倒になるので、configを設定してからSSHFS-Winの設定に進むことを強く推奨します。

使用ソフトウェアについて

前述の通りSSHFS-Winを使うのですが、他にも使えるソフトウェアがあるようです。まず名前がよく似ているwin-sshfs(https://github.com/feo-cz/win-sshfs)があります。SSHFS-Winのほうは(Windows上での仮想的なファイルシステムを提供するための)バックエンドとしてWinFsp(https://github.com/winfsp/winfsp)というのを使っているのですが、win-sshfsのほうはDokany(https://github.com/dokan-dev/dokany)(以前はDokanとして開発されていたもののフォーク)を使っている点が異なります。おそらくWinFspのほうがDokanyより後発で、win-sshfsは開発があまり活発でないようなので、今回は(WinFsp+)SSHFS-Winを使用することとします。なお、有料ソフトウェアですがExpandriveというのもこの目的に使えるようです。

インストール方法

WinFspとSSHFS-Winのインストールはいずれも容易です。配布されているmsiファイルを起動して指示に従えば、特に問題なくインストールできると思います。(デフォルトでは)SSHFS-Winの実行ファイル群(ssh.exe, sshfs.exe, sshfs-win.exeの3つ及び依存ライブラリのdll)はC:\Program Files\SSHFS-Win\binにインストールされます。

使用するコマンド、及びマウントポイントについて

SSHFS-Winの使い方に関する記事では、Windows標準コマンドのnetを使用するものや、sshfs-win.exeを使用するものが比較的多いと思います。しかし、これらは実際にはsshfs.exeを呼ぶための薄いラッパーであり、むしろsshfs.exeを直接呼ぶ方が見通しが良いため、この記事ではsshfs.exeコマンド(以下、混乱の恐れがない場合は単にsshfsと呼ぶ)のみを使います。

また、フォルダのマウント先に新規ドライブレター(X:のような)を使う解説例が多いと思うのですが、実は既存のドライブの中のディレクトリにマウントすることも可能です(これはnetコマンド経由ではできないようです)。となるとわざわざ貴重なドライブレターを消費する理由もないので、この記事ではディレクトリへのマウントを行うこととします。なお、sshfsが成功するためにはマウント先のディレクトリ(もちろん同名のファイルも)が存在しない状態である必要があります。ディレクトリはマウント時に作成され、sshfsの終了時に削除されます。これはマウントポイントが既に存在する空フォルダでなければならないLinuxとは異なるところなのでご注意ください。

コマンドラインオプション

sshfsの書式とオプションの全体は-hで確認できますが、この記事で使用するものをここで紹介しておきます。

  • -d デバッグ情報が出力されます。失敗しているときにConnection reset by peerとかしか出ないと何もわからないので、トラブルシューティング時は有効にしておくとよいです。正常動作中は大量のログが吐き出されるのでつけないほうがよさそうです。
  • -f デーモンとしてではなくフォアグラウンドで実行されます。わざわざtaskkillしなくてもCtrl+Cだけで停止できるので、頻繁に起動/終了するトラブルシューティング時にはつけた方が便利な気がします。
  • -o 様々なマウントオプションを指定します。たとえばtransform_symlinksを指定すると、リモートフォルダの中のシンボリックリンクを良い感じに変換してくれます。複数指定する場合はカンマで区切ります。

では、以下の2つのコマンドを(testdirというファイルやフォルダがない場所で)コマンドプロンプト上で実行してみてください。

set PATH=C:\Program Files\SSHFS-Win\bin;%PATH%
sshfs -f -o transform_symlinks server1:/ testdir

configなどが正しく設定できていれば、testdirというフォルダが作成され、server1のルートディレクトリの中身が見られるようになっているはずです(server1:/の最後のスラッシュがルートディレクトリを表している)。ちなみにtestdirの部分をX:などに変えれば新規ドライブレターへのマウントも可能です。

なお、この例ではSSHFS-WinのbinフォルダをPATHの先頭に追加しているのでsshfs.exeと同じ場所にあるSSHFS-Winのssh.exeが使われますが、Windows10の場合は標準でインストールされているOpenSSHのssh.exeもあるので、PATHを変えずにC:\Program Files\SSHFS-Win\bin\sshfs.exeを直接呼び出しても動作します。ただし後述のように多段sshを使う場合はうまく動作しないようなので注意してください。

問題1: 自分のユーザフォルダ等が見えない・ファイルを上書きできない

しかし実はここまでの設定だけだと問題があり、公開鍵認証が成功しているにもかかわらずなぜか自分自身のユーザフォルダの中身を見ることができません。言わば自分であることを証明できないような状態になっており、誰でも見ることができるファイルしか見れません。アクセスできないフォルダを開こうとすると、「このフォルダーにアクセスする許可がありません。[続行]をクリックすると、このフォルダーへの永続的なアクセスを取得します。」と言われてしまいます。

ここで[続行]を押すと見られるようになる場合もあるのですが、その過程でホームディレクトリのパーミッションが強制的に変更された結果sshログインが失敗するようになるというひどい目に遭ったので、押さないでください。押してしまった場合にchmodで直すために、該当サーバーにsshログイン済みのシェルを複数用意しておくことをお勧めします。cmdとかPowerShellだといつの間にか消えてることがある気がするので、Git Bashとかのほうがいいです(多分)。シェルがなくても、Windows上でアクセス権限を編集すれば元に戻せるかもしれませんが、やったことがないのでわかりません。あと元々701だったのを661に変えられたせいで(フォルダのアクセス権がなくなって)chmod 701 .ができなくなったことがあるのですが、cd ..で一つ上に移動してからchmod 701 usernameをすれば直せます(←蛇足ながら、本当に焦ったので一応書き残しておきました)。

で、どうすれば解決できるのかというと、-oでさらにオプションを追加するのですが、自分の知る限り有効なものが3つあります。ただし、これらの正確な機能やなぜそれでうまくいくのかなどは全く理解していません。

結論から言えば、(少なくとも自分の環境では)umask=0idmap=userの2つを指定しておけば十分そうでした。Microsoftアカウントと紐づけられていないアカウントの場合はumask=0を指定せずidmap=userだけでも大丈夫でしたが、紐づけられているアカウントの場合は、gid=0を指定すると自分の所属グループの権限で見れるはずのファイル、gid=0を指定しないと自分の権限で見れるはずのファイルがそれぞれ見えなくなりました。また、idmap=userだけだと、閲覧は問題なくできますが、既存ファイルへの上書きができなくなりました。より正確な情報はリンク先を読めば書いてあるかもしれません。

というわけで、実行時のコマンドは以下のようにしましょう。

sshfs -f -o transform_symlinks,umask=0,idmap=user server1:/ testdir

問題2: ポートフォワーディング(多段ssh)を使用すると失敗する

先ほども少し触れましたが、ポートフォワーディングを使用して、マウントしたいディレクトリがあるのとは別のsshサーバーを経由してsshfsを使う場合、そのままでは接続が失敗(Connection reset by peer)してしまいます。-dを有効にしてみると

/bin/sh: No such file or directory

というようなエラーが出ているのがわかります。解決策はhttps://github.com/winfsp/sshfs-win/issues/152#issuecomment-597087792に書いてあり、(busybox-w32)https://frippery.org/busybox/に同梱されているsh.exesshfs.exeと同じフォルダにコピーしてから同じコマンドを実行するといけました。 ちなみに当初はSSHFS-Winのssh.exeがいけないのかと思い、OpenSSHのssh.exeが呼ばれるようにしたところ多少改善した(パスフレーズ要求が一度も出ないところから二度出るまで行った)のですが、最終的にはやはりConnection reset by peerになってしまっていて、結局SSHFS-Winのssh.exeを使う上記の方法だけがうまくいきました。

おわりに

以上、Windowsでsshfsをする方法について解説しました。もしこの通りにやっても上手く行かない場合は、-dでの出力とともにコメントいただければ何かわかるかもしれません。

Youtube名演探訪シリーズ#4 - プロコフィエフ/ピアノソナタ第5番 改訂版(作品135)

久しぶりの更新です。初回の第8番に続き、こんどはプロコフィエフピアノソナタ第5番を扱ってみようと思います。

第8番の記事でも述べたとおりプロコフィエフピアノソナタで僕が一番好きなのは8番、その次が7番で、僕自身はプロコフィエフの最高傑作はこのどちらかだと思っています。ただ、同じく戦争ソナタ3部作に含まれる6番は、中間2つの楽章などは素晴らしいと思うのですが冒頭の主題があまり好きになれなくて、それよりは枯淡の境地とも言える9番と、中期の作品でありながらそれに似たものを感じる中期の5番を推したいのです。

この2曲についてはCiNii 博士論文 - セルゲイ・プロコフィエフのピアノ作品解釈に関する一考察 : ピアノソナタ第5番と第9番を巡ってという日本語の論文を見つけました。この論文で主張されていることは、僕自身はもちろん、5番や9番を好んで聴く人は皆どこかで感じたことがあるのではないかと思います。すなわち端的に言ってこの2曲はプロコフィエフの作品の中でもかなり「地味」な作品で、7番のような「打楽器的」なピアノ書法や、風刺的・前衛的な性格といったプロコフィエフステレオタイプと合致しないために広く知られていないのではないか、ということです。

しかしそのような先入観を捨てて聴けば、類まれなメロディーメーカーとしてのプロコフィエフのセンスは5番ソナタでも明らかですし、もっと聴き込めば6~8番にはない、言わばフランス的な(?)上品さが漂うこの曲独特の世界観が見えてきます(この曲を書いた当時のプロコフィエフは亡命してパリを拠点に活動しており、初演の場所もパリでした)。

この曲に関してもう一つ見逃せないのが、大幅な改訂を経て新たに作品番号(38→135)が付与された改訂版があるということです。全体の構成もかなり変わっているのですが細かい音の変更もなかなか興味深いです。

各楽章の紹介も兼ねて具体例を見ていきましょう。さっそく1楽章の冒頭付近からあります。

1楽章冒頭、作品38

1楽章冒頭、作品135

細かいですが、それでもはっきり音が違います。ちなみにですがこれを覚えておくと開始10秒で版の違いを判別できて便利です。

ところでこの第1主題、プーランクのフルートソナタの冒頭にどことなく似ていると思いませんか?プーランクプロコフィエフ、ルーツはけっこう違うと思うんですがそれにしては音楽の作り方がかなり似ている気がします。そのおかげかは知りませんが、前述の通りパリに滞在していたプロコフィエフプーランクとブリッジ仲間になるなど親しくしていたようで、プーランクオーボエソナタプロコフィエフに捧げられています。いい話だなあ。

第2主題は5連符の伴奏が特徴的なゆったりとした旋律です。特に再現部では絶妙な不協和音の響きが美しく、個人的には1楽章でここが最も好きです。この楽章で最も改訂が目立つのは展開部で、構造が全く違うというほどではないにせよ「つなぎ」のような部分がかなり変わっている印象です。詳しくは実際に聴いてみてください。

では2楽章に行ってみましょう。この楽章に関しては構成の変更はなく、小節数も変わりません。とはいえ、聴いていて「あれ?」と思うくらいの変更はそこそこあります。

2楽章冒頭、作品38

2楽章冒頭、作品135

まあなんか、けっこう違います。ここまで2例を見てきて改訂版のほうが臨時記号が増えている傾向があるのがわかるでしょうか。原典版が直線的あるいは新古典的なやや乾いた響きだとすれば、改訂版のほうが陰影に富んだ内省的な音楽になっている気がします。僕は改訂版のほうが好きなんですが、皆さんはどうですか?

次は3楽章で、これまた冒頭からあります。

3楽章冒頭、作品38

3楽章冒頭、作品135

違いますね。てかこれ、上の旋律は変わってないのに下だけガラッと変えてるんですよね。プロコフィエフの音楽にこうやって変える選択肢あるんだなというか、天才でも迷うことってあるんだなというか、とにかく面白いです。まあ改訂版が好きなんですが。

3楽章は全体的に最も改変の度合いが大きく、1楽章とは異なり主題部にも小節数の増減を含む大幅な変更が頻繁に施されており、展開も大きく変わっています。特に最後の方のPiu mosso以降は原典版にはなかった部分で、終わりまでこのテンポで突っ走るためかなり印象が異なります。

f:id:turgenev:20220331225152p:plain

Piu mossoになるところ

ところでこの音型、論文によると楽章冒頭の3~4小節目の縮小形と書いてあって、言われてみればたしかにそうなんですが、

www.youtube.com

ペトルーシュカのこれにしか聞こえなくないですか?関連があるのかは知りませんが、あったら面白いですね。

この3楽章、大幅な改訂を経たとはいえ、やっぱりいまいち展開が物足りない感はあると思うんですよね。展開部っぽいところに入ったと思ったらいつの間にか再現してて(言葉遣いが違うかもしれませんが…)、いつの間にコーダで、もう終わり?みたいな。テンポはそこそこ速めですが、(単一楽章の1, 3を除く)他のナンバーの最終楽章と比べるとやはり分かりやすい盛り上がりに欠ける面もあり、この楽章の地味さが作品全体の地味な印象につながっているのかなあというのは何となく想像できます。それでも流れるような展開やほどよい不協和音は聴く者を楽しませてくれます。

楽曲紹介はこれくらいにして、聴き比べに移りましょう。前述の通り僕自身は改訂版が好きでそっちに慣れてしまったので今回の聴き比べは改訂版(作品135)だけを対象にすることとします。読者の皆さんにも改訂版をおすすめしておきます。ただし作品135であっても「作品38(改訂版)」的な表記になっていたりするので検索するときは気を付けてください。実際に聴いてみて確かめるのが一番確実です。

 

まずは楽譜付き演奏の紹介から。演奏はアナトリー・ヴェデルニコフです。

www.youtube.com★★★★★

1959年録音なので音はあまり良くありません。しかしそこまで高い録音の質を要求しないのもこの曲の良いところです。演奏の内容は全く申し分なく、古典的なセンスにあふれています。特に2楽章は硬質な刻みと自然に流れる旋律の描き分けが素晴らしく、必聴。結論から言うとこの記事で紹介する録音でこれが一番おすすめなので、面倒な人は先を読まずにこれだけ聴いて頂ければ構いません。

元音源(公式)はこちら。 

www.youtube.com

 

次はOp.38(ボリス・ベルマン) とOp.135(ベルント・グレムザー)(15:57~)の聴き比べ動画です。といっても作品38は本記事の対象外なので、グレムザーのほうだけ扱います(ベルマンはOp.135も録音していて、これは後で扱います)。

この1楽章の第2主題を速くする解釈は(ほかにもいくつかありますが)聞いていて落ち着かないので個人的にそんなに好みではありません。まあ速くしない演奏に慣れてしまったということもありますが、せっかく5連符なんだからじっくりやればいいのにと思ってしまいます。

2楽章も、どちらかというとさっきのヴェデルニコフのように左手のテンポは揺らさず、アーティキュレーションをスタッカートで揃えるほうが好みかなあ。

www.youtube.com公式音源はこちら。

 

 

では、ここからは楽譜なしの音源を。

www.youtube.com★★★★☆

全集をつなげた動画ですがなぜか最初に5番(Op.135)が入っています。やや古い録音ですが、音質も演奏もかなり良いです。ただ、細部がヴェデルニコフほど洗練されていない気がするので星4つにしておきます。

 

www.youtube.com

★★☆☆☆

録音はまともですが、3楽章1:53~あたりにリッピングが原因とみられる音飛びがあります。演奏は、技術的にあまり余裕がなく、ところどころでリズムや音色のコントロールが甘くなっています。特に3楽章の最後のほうはいまいちです。2楽章も、意図的に遅い演奏というよりはやや間延びして聴こえます。

 

www.youtube.com

★★☆☆☆

録音は問題ありません。これも1楽章の第2主題を速くするタイプの演奏。テンポ・音量変化のセンスがよくわからないのと、勢いにまかせて雑なところがあります。

 

www.youtube.com★★★☆☆

極めてデッドというか、至近距離から直接音だけ録ったような録音です。ピアノの雑音を多く拾っていて、あまり心地よい音ではありません。ミスタッチが少なく安定しており、演奏は割と良い方だと思います。ふつうの録音で聴きたかったですね。

 

www.youtube.com

★★★☆☆

あまり特徴のない演奏ですが全体として悪くはないです。たまに細部が雑な気も。録音は良好です。

 

www.youtube.com

★★★☆☆

けっこう癖の強い演奏で、細かい速度・音色の変化が多いです。わりと弾けているので面白いところもありますが、いきなり響きが途切れて不自然に聴こえる箇所もちらほら。さっきの「2楽章途中」の改変の箇所などはさすがにリズムが歪みすぎだと思います(カップリングの8番も聴いたのですが似たような傾向あり)。全体の完成度で見ると微妙ですが、ミスが少ないのとアイデアが豊富ではあります。

 

www.youtube.com

★★★☆☆

ピアノソナタ全集から。冒頭からいきなりスタッカート気味の伴奏で落ち着かない感じがします。1楽章の第二主題が速く、他にも同じくらいの規模でまとめて速くなっているところがいくつかあります。全体に縦のリズム感よりは横の流れを重視しているような印象です。それがうまくハマっているのが3楽章といったところでしょうか。ミスは少なく、音色も綺麗だと思いますが、録音に関しては2楽章の冒頭などで顕著なようにピアノの打鍵音のような謎の音を拾っておりこれがかなり気になります。

 

www.youtube.com

★★★★☆

これも全集から。8番のところで推奨盤のひとつに挙げたオフチニコフの演奏です。技術的には安定感があります。1楽章は比較的遅めのテンポでじっくり鳴らす感じで、もう少し流れてもいいのではないでしょうか。2,3楽章は普通かやや速めくらいのテンポで、キレがあってなかなか良いです。

 

www.youtube.com

★☆☆☆☆

録音は直接音が大きすぎるような感じでいまいちです。演奏もやや凹凸が大きく、思いつきで適当に弾いているような印象を受けます。ミスタッチも多いです。

 

以下は、Op.38とOp.135が両方収録されています(余談ですが、そこまでする人というのはだいたい未完の10番の断片まで録音しているものですね)。

www.youtube.com

★★★★☆

Op.38(既に紹介した楽譜付き音源と同一)の直後にOp.135が収録されています。録音はやや残響が多いものの良好です。技術はさすがに安定しています。2楽章のテンポはいい感じに遅いのですが、たまに中途半端にペダルが入るところが気になるかも?対して3楽章のテンポは速めです。最後の方で盛り上がるところはどうしてもうるさくなりがちですがこの演奏は綺麗です。全体に模範的な演奏といえるでしょう。

 

www.youtube.com

★★★★☆

一方こちらは作品番号順ということで、9番よりあとにOp.135が収録されています。聴いた印象としてはオフチニコフに似ていて、変化は少ないほうです。全楽章とも比較的遅め。録音は基本的に良いですが、3楽章終盤の高音のffのところで、何か機材に共鳴しているようなノイズが入っています。惜しい。

 

これ以下は、Op.38と表記されているが実際にはOp.135になっているものです(逆はなさそうですね)。

www.youtube.com

★★★☆☆

全体にテンポが速めで忙しない感じです。技術力は十分なのですが、(おそらくミスタッチではなく)譜読みの間違いが多くて勿体ないです。細部のセンスはまあまあかな。

 

www.youtube.com

★★☆☆☆

これもPetrushanskyと同じくけっこう変化のある演奏で聴き疲れします。音量的にバランスが悪いと感じるところもあり、あまり高評価にはできません。

 

www.youtube.com

★★★☆☆

必要以上に尖るようなところがなく聴きやすい音ですが、なよっとしているというか、テンポや音量が定まらないようなところも多い気がします。音のミスは少なめ。

 

まとめ

一番古いヴェデルニコフの演奏が素晴らしく、それを超えたと思える演奏に巡り会えませんでした。とはいえ、★★★★☆の演奏は十分にお勧めできます。中でも一つ選ぶならペトロフでしょうか。

技巧で有名な曲ではなくともやはり簡単な曲でもないようで、技術的な面で割と差が出る印象でした。とはいえ、もっと知名度が上がって一流の演奏家が次々に取り組んでくれるようになれば、必ず良い演奏が生まれるはずです。期待しましょう。