コンテンツへスキップ

1

引っ越し先でのネットワーク環境整備: MAP-E という記事で、DTI光に契約したことを書きましたが、MAP-E接続にハマりMikroTik RB4011iGS+RMを有効活用できないまま半年が経過してしまいました。

RouterOSでMAP-E接続の試み

MAP-E(OCNバーチャルコネクト)で通信できるように、例の計算機の力を借りながら、下のようなスクリプトでマッピングルールに従ったNAPTを設定してIPIP6トンネルへ流し込むなどあれこれ試してみたのですが、どうにもうまくいかず…。

:global addNatRules do={
  # Args: $PSID $v4Addr $outInterface
  :for i from=1 to=63 do={
    :local portStart ((i << 10) | ([:tonum $PSID] << 4))
    :local portEnd   ($portStart + 15)
    :local portRange "$portStart-$portEnd"

    /ip firewall nat add chain="srcnat" action=masquerade protocol=tcp nth="$(64 - $i),1" \
      to-address=$v4Addr to-ports=$portRange out-interface=$outInterface
    /ip firewall nat add chain="srcnat" action=masquerade protocol=udp nth="$(64 - $i),1" \
      to-address=$v4Addr to-ports=$portRange out-interface=$outInterface
  }
}

$addNatRules PSID=XX v4Addr=xxx.xxx.xxx.xxx outInterface=ipipv6-ocnvc

結局諦めて、BUFFALO WSR-2533DHP2をルータにして運用していました。

しばらくはこれで使っていたのですが、5〜6月にOCNバーチャルコネクトでの通信速度の低下が目立つようになり、在宅勤務に若干支障が出始めていました。DTI光の「IPv6(IPoE)接続サービス」は、契約時期によってVNE(OCNバーチャルコネクト or v6プラス)が異なるのですが、各所での報告を見るとOCNバーチャルコネクトのみ速度低下が顕著に現れているようでした。PPPoEは言わずもがななので、もう人権がありません。

IIJmioひかりへ

DTI光のキャッシュバックも振り込まれたし、他のISPに移るには良い時期だと思いまして、RouterOSで動作実績のあるDS-Lite(transix)採用のIIJmioひかりに事業者変更することにしました。

コラボ光での事業者変更は初めてのことでしたし、VNEの切り替えも伴うため、少し手間取ってしまいました。

申し込みから時系列に整理すると以下の通り。

2020/07/06 DTI光 事業者変更承諾番号発行
2020/07/07 IIJmioひかり 事業者変更申し込み
2020/07/11 ひかりプロビジョニングセンターから電話
2020/07/14 IIJmioひかり 回線開通日
2020/07/15 「回線開通のお知らせ」メール受信
2020/07/16 IIJmioひかり IPoEオプション申し込み
DTI「退会手続き受け付けのお知らせ」メール受信
2020/07/17 DTIサポートへ「IPv6(IPoE)接続サービス」の即時廃止を依頼
2020/07/20 昼過ぎ頃にOCNバーチャルコネクトから切断されたことを確認
IIJサポートへその旨を連絡
2020/07/21 「IPv6 IPoEオプションご利用開始日確定のお知らせ」メール受信
2020/07/22 transix接続確立確認

DTI光が月末解約扱いということに7/16のメールで気づき、「IPv6(IPoE)接続サービス」をすぐに廃止してほしい旨を連絡したのですが、もっと早く連絡していればIIJ側でより早くVNE切り替え・transix開通できたと思います。このあたりの仕組みをよく理解していなかったのが反省点です。

RouterOSでDS-Lite

ひかり電話なしの環境なので、RAで/64のプレフィックスが払い出されることを理解していれば、設定自体は難しくありませんでした。

以下のブログ記事の内容そのままです。

ねころくぶろぐ: RouterBoardでDS-LITE

PPPoEとの併用

DS-LiteはISP側のルータ(AFTR; Address Family Transition Router)でNAPTされるため、自由にポート開放ができません。MAP-Eではマッピングされたポートについては自由に扱えるため、自宅サーバへのアクセスを実現できていたのですが、今回は別の方法を考えなければいけません。
(もちろんグローバルIPv6アドレスで公開することはできるが、出先ではIPv4のみの環境も多いため、IPv4アドレスでのアクセス手段を考える)

どこかのVPSを踏み台にして自宅とVPNを張っておく、という手段もありますが、IIJmioひかりはIPv4 PPPoE接続も併用できるので、こちらを使うことに。DTI光では「IPv6(IPoE)接続サービス」が開通すると、IPv4 PPPoE接続は自動的に廃止され併用できない仕様だったので……。

PPPoEとの併用にあたって、以下のような設定を行いました。(PPPoE接続のセットアップ自体は特に悩むところはないので割愛)

PPPoE経由のpolicy-based routing

PPPoEから入ってきた接続にmangleでrouting-markを付け、デフォルトのtransix向けIPIP6トンネルではなく、PPPoEへルーティングするように設定します。

以下は、PPPoEから入ってきたtcp/10022ポート宛を自宅鯖192.168.88.100のtcp/22へdst-natする想定での例です。

/ip firewall mangle
add action=mark-connection chain=prerouting connection-mark=no-mark connection-state=new in-interface=pppoe-iijmio new-connection-mark=pppoe-iijmio passthrough=yes
add action=mark-routing chain=prerouting connection-mark=pppoe-iijmio dst-address-type=!local in-interface-list=LAN new-routing-mark=ppoe-iijmio passthrough=no
/ip firewall nat
add action=masquerade chain=srcnat out-interface=pppoe-iijmio
add action=dst-nat chain=dstnat dst-port=10022 in-interface=pppoe-iijmio protocol=tcp to-addresses=192.168.88.100 to-ports=22
/ip route
add comment="PPPoE-IIJmio connection" distance=1 gateway=pppoe-iijmio routing-mark=ppoe-iijmio
add comment=transix distance=2 gateway=ipipv6-transix

これでイケる!と思って、試しに外からSSH接続してみると、接続は確立するものの、ブラジルのサーバと通信しているのかってくらいパケロスの大きい回線を使っているような状態でした。

あれこれ原因調査をしていると、redditで以下の質問を見つけました。これを読むと、どうやらpolicy-based routingしようとしているパケットをfasttrackしてしまうとマズイっぽい。

reddit: My routing mangle rules dont work.

デフォルトではfilterルールに以下のようなルールが入っているけど、

/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related

connection-mark=no-markに限定して適用するように修正すればOK

/ip firewall filter
add action=fasttrack-connection chain=forward connection-mark=no-mark connection-state=established,related

このルールがどの程度パフォーマンス的に影響があるか評価してないですが、上限100MbpsのVDSLである我が家で問題になることはないでしょう。

DDNSのIPアドレス

RouterOSにはCloudサービスとしてDDNS機能が提供されています。*.sn.mynetname.netというホスト名が与えられて参照解決できるようになるのですが、複数のPublic IPアドレスを持つことを想定していません。

とりあえずDDNSの更新サーバへ通信する時のIPアドレスが登録されるっぽいので、そのままだとデフォルトゲートウェイのtransix側のIPアドレスが登録されてしまいます。外部から自宅へアクセスする目的なので、PPPoEのIPアドレスが登録されるようにします。

MikroTIkのDDNS更新用サーバはcloud2.mikrotik.comと書いてあるので、こいつへのアクセスはPPPoE経由になるようスタティックルートを設定してあげます。
(今後、更新用サーバのIPアドレスが変わるかもしれない点は要注意)

/ip route
add comment=DDNS distance=1 dst-address=159.148.147.201/32 gateway=pppoe-iijmio
add comment=DDNS distance=1 dst-address=159.148.172.251/32 gateway=pppoe-iijmio

IPv6 IPoEのブリッジ設定

そして最後は、ひかり電話なしの環境でLAN側にIPv6をどう流してやるか。RouterOSはいわゆるND Proxyは実装されていないので、もうブリッジしてやるくらいしか無いですね??

Routerboardユーザグループさんのブログに以下のような記事がありましたので、ほぼ同じような構成にしました。

Routerboard User Group JP Portal Site: IPoE(IPv6)環境でのRouterOSの設定方法について

とりあえずbridge filterでNGNとはPPPoEとIPv6しか通れないようにします。

記事ではether1(WAN)・ether2(LAN)の想定ですが、RB4011で全インタフェースブリッジしてether1がONUに接続されているという想定だと、以下のようなルールになります。
(完全に雰囲気で書いているので、これで良いのか自信は無い)

/interface bridge filter
add action=jump chain=input comment="INPUT from WAN" in-interface=ether1 jump-target=input-wan
add action=accept chain=input-wan comment="accept input IPv6" mac-protocol=ipv6
add action=accept chain=input-wan comment="accept input PPPoE" mac-protocol=pppoe-discovery
add action=accept chain=input-wan mac-protocol=pppoe
add action=drop chain=input-wan
add action=jump chain=output comment="OUTPUT to WAN" jump-target=output-wan out-interface=ether1
add action=accept chain=output-wan comment="accept output IPv6" mac-protocol=ipv6
add action=accept chain=output-wan comment="accept output PPPoE" mac-protocol=pppoe-discovery
add action=accept chain=output-wan mac-protocol=pppoe
add action=drop chain=output-wan

このbridge filterによってbrigdeのhardware offloadingは無効になってしまうので、NASなどは別のスイッチを接続してその下にぶら下げたほうが良いと思います。

ipv6-test.com result

追記

以下のブログ記事を見て気がついたのですが、bridgeの設定で use-ip-firewall というオプションがあり、なんと、これを有効にすることでブリッジされるパケットについてもIPレベルのフィルタが適用できました。

Knowledgeloc: [RouterOS] 日本のISPにおける一般的なIPv4/IPv6 Dual Stack構築方法

Mikrotik: Building Your First Firewall

今思えば、パケットのフローダイアグラムで、ブリッジのところからUSE-IP-FIREWALLの分岐が示されていたけど、こういうことだったのか……。


ということで、以上。せっかく買ったRB4011を有効活用できる環境がひとまず整ったのでヨシ!

また格安VPSシリーズです。

今回はGreenCloudVPSというプロバイダを紹介します。米国を中心に、ヨーロッパからアジアまで27ヶ所のデータセンターからサービスを提供しているようです。

前から気になっていたのですが、LowEndTalkでシンガポールのお得なオファーが出ていたので、まずは$60/yの方を試しに契約してみました。

ざっとベンチ結果など貼っておきます。

# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
#              Yet-Another-Bench-Script              #
#                     v2020-02-10                    #
# https://github.com/masonr/yet-another-bench-script #
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #

2020年  3月 14日 土曜日 09:12:54 MST

Basic System Information:
---------------------------------
Processor  : QEMU Virtual CPU version 2.5+
CPU cores  : 2 @ 2700.052 MHz
AES-NI     : ❌ Disabled
VM-x/AMD-V : ❌ Disabled
RAM        : 3.7Gi
Swap       : 2.0Gi
Disk       : 20G

fio Disk Speed Tests (Mixed R/W 50/50):
---------------------------------
Block Size | 4kb           (IOPS) | 64kb          (IOPS)
  ------   | ---            ----  | ----           ---- 
Read       | 76.99 MB/s   (19.2k) | 597.61 MB/s   (9.3k)
Write      | 77.19 MB/s   (19.2k) | 600.75 MB/s   (9.3k)
Total      | 154.18 MB/s  (38.5k) | 1.19 GB/s    (18.7k)
           |                      |                     
Block Size | 512kb         (IOPS) | 1mb           (IOPS)
  ------   | -----          ----  | ---            ---- 
Read       | 813.57 MB/s   (1.5k) | 731.37 MB/s    (714)
Write      | 856.79 MB/s   (1.6k) | 780.08 MB/s    (761)
Total      | 1.67 GB/s     (3.2k) | 1.51 GB/s     (1.4k)

iperf3 Network Speed Tests (IPv4):
---------------------------------
Provider                  | Location (Link)           | Send Speed      | Recv Speed     
                          |                           |                 |                
Bouygues Telecom          | Paris, FR (10G)           | 365 Mbits/sec   | 132 Mbits/sec  
Online.net                | Paris, FR (10G)           | busy            | 5.83 Mbits/sec 
WorldStream               | The Netherlands (10G)     | busy            | busy           
wilhelm.tel               | Hamburg, DE (10G)         | busy            | 5.47 Mbits/sec 
Biznet                    | Bogor, Indonesia (1G)     | 919 Mbits/sec   | 417 Mbits/sec  
Hostkey                   | Moscow, RU (1G)           | busy            | 252 Mbits/sec  
Velocity Online           | Tallahassee, FL, US (10G) | 363 Mbits/sec   | 115 Mbits/sec  
Airstream Communications  | Eau Claire, WI, US (10G)  | 384 Mbits/sec   | 46.4 Mbits/sec 
Hurricane Electric        | Fremont, CA, US (10G)     | 500 Mbits/sec   | 79.2 Mbits/sec 

iperf3 Network Speed Tests (IPv6):
---------------------------------
Provider                  | Location (Link)           | Send Speed      | Recv Speed     
                          |                           |                 |                
Bouygues Telecom          | Paris, FR (10G)           | 388 Mbits/sec   | 107 Mbits/sec  
Online.net                | Paris, FR (10G)           | 407 Mbits/sec   | 79.1 Mbits/sec 
WorldStream               | The Netherlands (10G)     | busy            | busy           
wilhelm.tel               | Hamburg, DE (10G)         | 244 Mbits/sec   | 91.9 Mbits/sec 
Airstream Communications  | Eau Claire, WI, US (10G)  | 339 Mbits/sec   | 55.5 Mbits/sec 
Hurricane Electric        | Fremont, CA, US (10G)     | 434 Mbits/sec   | 57.5 Mbits/sec 

Geekbench 5 Benchmark Test:
---------------------------------
Test            | Value                         
                |                               
Single Core     | 515                           
Multi Core      | 1024                          
Full Test       | https://browser.geekbench.com/v5/cpu/1455882

日本との通信速度

$ speedtest-cli --share --server 7139
Retrieving speedtest.net configuration...
Testing from Nexeon Technologies (96.9.x.x)...
Retrieving speedtest.net server list...
Retrieving information for the selected server...
Hosted by SoftEther Corporation (Tsukuba) [5361.83 km]: 337.221 ms
Testing download speed................................................................................
Download: 204.28 Mbit/s
Testing upload speed......................................................................................................
Upload: 222.65 Mbit/s
Share results: http://www.speedtest.net/result/9131998304.png

日本へのルーティング

# traceroute -4 www.soumu.go.jp -T -A
traceroute to www.soumu.go.jp (203.180.216.224), 30 hops max, 60 byte packets
 1  103.200.219.1 (103.200.219.1) [AS38001]  0.293 ms  0.186 ms  0.175 ms
 2  10.15.62.202 (10.15.62.202) [*]  0.702 ms  0.720 ms  0.697 ms
 3  xe-0-0-7-1.a01.sngpsi03.sg.bb.gin.ntt.net (116.51.26.113) [AS2914]  1.623 ms  1.594 ms  1.553 ms
 4  ae-13.r00.sngpsi07.sg.bb.gin.ntt.net (129.250.7.82) [AS2914]  117.733 ms  117.723 ms ae-8.r01.sngpsi07.sg.bb.gin.ntt.net (129.250.7.84) [AS2914]  117.690 ms
 5  ae-2.r20.sngpsi07.sg.bb.gin.ntt.net (129.250.3.101) [AS2914]  1.536 ms  1.575 ms  1.532 ms
 6  ae-1.r25.osakjp02.jp.bb.gin.ntt.net (129.250.2.67) [AS2914]  117.626 ms  117.832 ms  117.645 ms
 7  ae-2.r03.osakjp02.jp.bb.gin.ntt.net (129.250.7.33) [AS2914]  111.709 ms  111.703 ms  111.702 ms
 8  210.173.179.34 (210.173.179.34) [AS7521]  111.574 ms  112.441 ms  112.322 ms
 9  osk004bb00.IIJ.Net (58.138.106.125) [AS2497]  118.617 ms  118.379 ms osk004bb01.IIJ.Net (58.138.107.29) [AS2497]  118.154 ms
10  tky008bb01.IIJ.Net (58.138.88.45) [AS2497]  118.444 ms  118.459 ms  118.270 ms
11  tky008sdgw30.IIJ.Net (58.138.105.198) [AS2497]  117.655 ms tky008sdgw30.IIJ.Net (58.138.105.194) [AS2497]  117.732 ms tky008sdgw30.IIJ.Net (58.138.105.198) [AS2497]  117.263 ms
12  tky008sdgw40.IIJ.Net (58.138.104.194) [AS2497]  117.204 ms  117.155 ms  117.425 ms
13  160.13.133.162 (160.13.133.162) [AS2497]  120.284 ms  120.241 ms  119.688 ms
14  203.180.216.224 (203.180.216.224) [AS2497]  117.997 ms  120.593 ms  120.573 ms

IPv6だとHurricane Electricのバックボーンを抜けてくる。

# traceroute -6 www.soumu.go.jp -T -A
traceroute to www.soumu.go.jp (2001:240:bb81::21:e0), 30 hops max, 80 byte packets
 1  _gateway (2406:f400:8:32::1) [AS38001]  0.252 ms  0.179 ms  0.212 ms
 2  2406:f400:1:4::1 (2406:f400:1:4::1) [AS38001]  0.343 ms  0.305 ms  0.289 ms
 3  2406:f400:262:408::2 (2406:f400:262:408::2) [AS38001]  117.412 ms  117.380 ms  117.304 ms
 4  hurricaneelectric1-100g.hkix.net (2001:7fa:0:1::ca28:a19e) [*]  118.855 ms  118.779 ms  118.738 ms
 5  100ge10-1.core1.tyo1.he.net (2001:470:0:3c0::2) [AS6939]  167.226 ms  167.205 ms  171.738 ms
 6  2001:7fa:7:1::2497:3 (2001:7fa:7:1::2497:3) [AS7521]  167.813 ms  164.441 ms  168.911 ms
 7  tky001bb10.IIJ.Net (2001:240:bb01:39::7d) [AS2497]  164.307 ms tky001bb10.IIJ.Net (2001:240:bb01:3b::7d) [AS2497]  169.112 ms tky001bb10.IIJ.Net (2001:240:bb01:83::7d) [AS2497]  164.726 ms
 8  tky012agr10.IIJ.Net (2001:240:bb00:9176::1b8) [AS2497]  119.510 ms tky012agr10.IIJ.Net (2001:240:bb00:9177::1b8) [AS2497]  119.052 ms  118.993 ms
 9  2001:240:bb81::21:e0 (2001:240:bb81::21:e0) [AS2497]  114.656 ms  120.042 ms  119.003 ms

手元のOCN回線からだとRTT 90ms弱ですね。

# traceroute 45.119.201.6 -A -T
traceroute to 45.119.201.6 (45.119.201.6), 30 hops max, 60 byte packets
 1 *
 2 *
 3 *
 4  122.1.245.65 (122.1.245.65) [AS4713]  13.175 ms 60.37.54.161 (60.37.54.161) [AS4713]  13.882 ms 122.1.245.65 (122.1.245.65) [AS4713]  13.180 ms
 5  ae-5.r02.tokyjp05.jp.bb.gin.ntt.net (120.88.53.17) [AS2914]  21.345 ms ae-6.r02.tokyjp05.jp.bb.gin.ntt.net (120.88.53.21) [AS2914]  20.947 ms ae-6.r03.tokyjp05.jp.bb.gin.ntt.net (120.88.53.29) [AS2914]  20.960 ms
 6  ae-4.r30.tokyjp05.jp.bb.gin.ntt.net (129.250.3.34) [AS2914]  20.941 ms ae-3.r30.tokyjp05.jp.bb.gin.ntt.net (129.250.3.23) [AS2914]  21.265 ms  21.219 ms
 7  ae-4.r24.tkokhk01.hk.bb.gin.ntt.net (129.250.2.51) [AS2914]  57.291 ms  57.270 ms  58.156 ms
 8  ae-1.r03.tkokhk01.hk.bb.gin.ntt.net (129.250.6.98) [AS2914]  57.214 ms ae-1.r02.tkokhk01.hk.bb.gin.ntt.net (129.250.6.92) [AS2914]  57.194 ms ae-1.r03.tkokhk01.hk.bb.gin.ntt.net (129.250.6.98) [AS2914]  58.780 ms
 9  ae-1.a01.newthk03.hk.bb.gin.ntt.net (129.250.5.253) [AS2914]  61.338 ms ae-2.a01.newthk03.hk.bb.gin.ntt.net (129.250.6.125) [AS2914]  61.036 ms ae-1.a01.newthk03.hk.bb.gin.ntt.net (129.250.5.253) [AS2914]  65.018 ms
10  xe-0-0-24-2.a01.newthk03.hk.ce.gin.ntt.net (203.131.240.134) [AS2914]  62.225 ms  61.003 ms  62.228 ms
11  * * *
12  sg1.newmediaexpress.com (45.119.201.6) [AS38001]  86.969 ms  81.011 ms  82.140 ms

データセンターはEquinix SG1なので日本との接続性も悪くないです。
これで$60/y(=$5/m)はお買い得感ありますね。ただ、もう少しストレージが多ければ文句なしなんですけどね……。

2

お久しぶりです。実は先月引っ越しをしまして、その直後にコミケがあり、正月でやっと一息つけたところです。

さて、引越し先はフレッツ光のVDSL方式しか選択肢のないマンションでして、色々と苦しんでおります。これまでauひかりを10年以上使っていたので、自宅でフレッツ回線をまともに触るのは2000年前半にADSLを引いたとき以来になります。

auひかりでは上下5Gbpsの高速サービスを契約しており、実測値も悪くなかったので、かなり富豪的にインターネットを使えておりました。

が、今は上下最大100MbpsのVDSLです。(光ネクスト マンションタイプ プラン1B)

また、噂には聴いていましたがPPPoEの網終端装置での輻輳がここまでひどいとは思いませんでした。夜間のピーク時にはダウンロードが2,3Mbpsほどになり、動画配信サービスはまともに使えたものではありません。(網内では90Mbpsは出ています)

PPPoE終端での輻輳を回避するため、NGNのIPv6 IPoE接続を使ってIPv4 over IPv6トンネリングしてやるサービスが乱立しているんですね。あちこちで「IPoE」と呼ばれているものが、実際はNGNにおけるIPv4 over IPv6 over Ethernetを指していると認識しました。それから「IPv6だから速くなる」的な誤った推論も溢れていて、まぁ、カオス状態で驚きました。

しかし、NGNに関して完全に浦島太郎状態だったので、NGN独特の仕様に疲弊しております。ひかり電話の契約によって、IPv6プレフィックスが降ってくる方法が変わるとか……どうして……

この前買ったMikrotik RB4011iGS+RMで遊ぼうと考えていたのですが、泣きそうです。


愚痴はさておき、上記のような様々な罠を知らずに契約したのがDTI光(ひかり電話なし)です。

PPPoE接続はいいとして、問題はIPIP6(IPv4 over IPv6)の方式です。DTI光では、MAP-E方式のOCNバーチャルコネクトというサービスを導入しているようです(なお、契約時期によってはv6プラスだった模様)。それにしても、わざわざ 4466.jp なんてドメイン取ってまで宣伝してるのですね。

RouterOSを用いた接続ですが、DS-Lite方式については動作報告を見つけることができましたが、MAP-Eは見当たりませんでした。

ねころくぶろぐ: RouterBoardでDS-LITE

MAP-Eそのものというよりは、提供事業者によるマッピングルールやBorder Relay(BR)が明らかにされていないことが問題でしょうか。

JPNEが提供するv6プラスやBIGLOBEのv6オプションについては、先人たちの調査によって判明しているようです。

風柳メモ: v6プラス関連の覚え書き

ネトゲー回想録: v6プラスのIPアドレス&ポートの計算方法

issue: biglobeのIPv4 over IPv6でハマった話 (RTX830)

OCNバーチャルコネクトコネクトは情報がありません……

仕方がないので、調査用にOCNバーチャルコネクト対応ルータWSR-2533DHP2を買ってきました。それで挙動を解析しました。

とりあえず、分かったことを書いておきます。

  • rule.map.ocn.ad.jp というホスト名を名前解決してた
    • ググるとCiscoの以下のドキュメントがヒットする
      IP Addressing: NAT Configuration Guide, Cisco IOS XE 17
    • どうやら↓みたいなAPIを叩いて、マッピングルールを取得しているっぽい?
      https://rule.map.ocn.ad.jp/?ipv6Prefix=<address>&ipv6PrefixLength=<prefixLength>&code=<API Key>
  • ルータ管理画面の出力を見る限りでは、CEアドレス、IPv4アドレス、ポート番号が以下の計算機の計算結果と一致することを確認。なんと、この計算機はOCNのIPレンジも対応済みだったんですね…。
    http://ipv4.web.fc2.com/map-e.html
  • BRアドレスは、自分の環境(東日本)では 2001:380:a120::9

はぁ、意地を張らず最初からIX2105あたりを入手しておけば良かったと後悔しかけています。

今日はここまで。

[追記]

あれこれ格闘しましたがうまくいかず、結局DS-Lite対応のIIJmioひかりへ移りました 。
=> IIJmioひかりへ事業者変更 RouterOSでDS-Lite

そういえば、いつの間にか例の計算機でOCNバーチャルコネクトのBRアドレス(peeraddr)対応されていましたね…。一体何者なんだ…。

Pleromaインスタンス social.metadata.moe を立てました。

以前にMastodonを立てていたのですが、運用していたVPSのプロバイダが消滅してしまい(=> HostMyBytes SSD VPS 6GB VPS Special )、そのまま放置した状態でした。

やっぱりFediverseとの繋がりがほしいなぁ、という想いがあり、再度お一人様インスタンスを立て直してみました。

お一人様インスタンスとして、Mastodonは少々リッチすぎるなぁと感じてはいたので、今回は軽量だと評判のPleromaを採用しました。

サーバの用意

とにかく安さが最優先です。AWS、Azure、GCPなんて無かった。

が、以前のMastodonで運用していた$39/yearという激安すぎるクソVPSのように、また倒産しては困るので、もう少しまともなプロバイダを。

UltraVPS.euのCloud Special-2プラン (Los Angeles)

  • 2 CPU cores / 2GB RAM / 50GB SSD / 1TB Bandwidth

お一人様用では十二分のスペックですが、これで40€/yearです。ブラックフライデーでは、例年だとさらに20% OFFになるはずなので、おすすめです。

RTTは120msほどありますが、普通に使う分には困ることはないでしょう。

mediaproxyを有効にしたり、画像・動画をバンバン上げるようならば、ストレージを別途考える必要があります。同じUltraVPS.euのストレージプランでminioとか立てるのがコスパ最高だと思います。

インストール

以下のリポジトリを参考にして、Dockerで簡単に立てられました。
READMEに書いてある通りです。

GitHub: angristan/docker-pleroma

ただ、ちょっとカスタマイズするときに色々不便なので、uploadsディレクトリに加えて、staticディレクトリとかconfigファイルをマウントしておくと良いかもしれません。

    volumes:
      - ./uploads:/pleroma/uploads
      - ./static:/pleroma/instance/static
      - ./config/secret.exs:/pleroma/config/prod.secret.exs

staticディレクトリの内容については以下を参照。同じディレクトリ名が繰り返し出てくるのでややこしい。

Pleroma Documentation: Configuration - Static Directory

参考

みんなどんな風に立ててるのかなー、と気になりまして、参照したサイトです。

anyNodeというプロバイダの格安リソースプールを試してみました。

LowEndTalk: anyNode.net - Resource Pools from $12/yr in 3 locations

1Core CPU, 1GB, 20GB SSD, 1TB BW, 1 IPv4あたり$12/yearという激安価格。仮想化方式はOpenVZですが、今年11月にEOLを迎える6系ではなく7系です。

場所はMiami / Seatle / Las Vegasとありますが、現在はLas Vegas以外空きがなく利用できない状態でした。(どのノードにも空きがなくて、VMが新規作成できない状態も一時期ありました…)
複数VMを建ててみても全部同じノードに乗ってるようなので、なんだかなぁ(加藤恵さん風)という感じでございます。

以下、nench.shの結果を貼っておきます。

-------------------------------------------------
 nench.sh v2019.07.20 -- https://git.io/nench.sh
 benchmark timestamp:    2019-08-18 15:43:24 UTC
-------------------------------------------------

Processor:    Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
CPU cores:    4
Frequency:    2999.902 MHz
RAM:          2.0Gi
Swap:         -
Kernel:       Linux 4.9.0 x86_64

Disks:
ploop27975     40G  HDD

CPU: SHA256-hashing 500 MB
    6.396 seconds
CPU: bzip2-compressing 500 MB
    7.920 seconds
CPU: AES-encrypting 500 MB
    2.568 seconds

ioping: seek rate
    min/avg/max/mdev = 119.2 us / 290.1 us / 33.7 ms / 587.4 us
ioping: sequential read speed
    generated 2.83 k requests in 5.00 s, 707.8 MiB, 566 iops, 141.5 MiB/s

dd: sequential write speed
    1st run:    456.81 MiB/s
    2nd run:    621.80 MiB/s
    3rd run:    642.78 MiB/s
    average:    573.79 MiB/s

IPv4 speedtests
    your IPv4:    66.23.193.xxxx

    Cachefly CDN:         78.19 MiB/s
    Leaseweb (NL):        1.77 MiB/s
    Softlayer DAL (US):   16.96 MiB/s
    Online.net (FR):      1.80 MiB/s
    OVH BHS (CA):         3.81 MiB/s

ちょっとネットワークがいまいちで、パケロスが結構発生するのが厳しいです。(DC内というよりは、途中の経路が悪い感じですが)

パフォーマンス的には使えないことはないので、OpenVZ7でDockerも一応動くし、うまいこと使っていこうと思っています。

ただ、Dockerをインストールして普通に動かそうとすると、以下のようなエラーで動きません。

dockerd[16467]: failed to start daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables --wait -t nat -N DOCKER: iptables v1.8.2 (legacy): can't initialize iptables table `nat': Table does not exist (do you need to insmod?)

(OpenVZ)コンテナ内でiptable_natモジュールが使えないように設定されているみたいなんですが、これはサポートに依頼すれば変更してくれるのでしょうかね。anyNodeのDiscordでみんなカジュアルにやりとりしてるので、近いうち聞いてみるかな。

とりあえず、dockerdの起動オプションに--iptables=falseを付けておけば動くことは動きます。