2018/02/20(火)IPv6 の基礎(1) - ネットワーク機器類の取扱説明書を見る時、得意になれそうな知識

今回から不定期にIPv6基礎ネタを備忘録的に残していこうと考えています。
あくまでも「備忘録」です。はい。

筆者がかねてから想像していたとおり、今まで嗜んできたIPv4 とは毛色が違うし、似て似つかないものがあります。なので、初心者から「志を持って」(何のだ・・)猛勉強中です。

そんな中、各種のネットワーク機器を家電量販店やICT機器専門店などで買うときや、買った後で知っておくと、周囲に威張ることができそうな理解がしやすくなるような基礎知識を先ずはまとめていきます。

IPv4 は、軍事・学術研究から行き当たりばったりで進化してきた技術ですが、
IPv6 は最初から民生用途が意図されていて、万人共通の定義づけがいくつかあります。
ここがまず IPv4 と違う世界ですね。
IPv6基礎(1)
IPv6 の世界で先ず使われる用語の基礎用語として、以下があります:
■ ノード
 IPv6 通信機能を持った機器全てを指す。
 具体的には、パソコン、ネットワークプリンタ、ルータ、サーバを指し、ハブやスイッチングハブなどはノードに含みません。
 図示していませんが、スマートフォン、タブレットも「ノード」です。
 ノードは「ルータ」と「ホスト」の2つに区別されます。

■ リンク
 ハブやスイッチングハブ、無線LANアクセスポイントなどを介して、ルータ超えしないで直接イーサネットやWiFiで通信可能な装置間接続を指します。
 ルータ同士の通信も「リンク」です。
 ルータ超えの通信は「リンク」ではありません。

■ サイト
 1つ以上のリンクからなるLANを指します。
 ルータが複数あっても、インターネットに出ていかずに別のリンクと接続するLANは、接続ルータ先のリンクもまとめて「サイト」になります。
 ただ、この概念は古い IPv6 の資料には出てくるのですが、現在は使いません。
 古い IPv6 の資料を読むときに必要となります。

■ ルータ
 ノードのうち、リンク外部との通信中継・リンク内部通信の取りまとめを行う機器を指します。
 インターネット接続には不可欠な装置になります。

■ ホスト
 ノードのうち、ルータ以外の全ての機器を指します。
 受信時、自ホスト宛は処理できるが、他ホストへ転送出来ない機器全てがホストです。
 パソコン、ネットワークプリンタ、サーバ、スマートフォン、タブレットなどは、典型的なホストの一例です。
 リンク内でも他ホストへの送信は、基本的にルータが取りまとめて処理します。

■ 近隣ノード
 リンク内で通信が直接到達可能なノード全てを指します。

これらは概念として理解しておくと、後々 IPv6 の理解が楽になります。

2018/02/17(土)IPv6非対応回線に IPv6導入(6to4接続)

実は、弊社がメインで使用している回線は、ネイティブ IPv6 には非対応です。
# 正確には対応していたはずだが、ISP経営統合でそのあたりの対応が立ち消え状態・・・

よって、IPv4 で IPv6 を包み込んで通信する「トンネル接続」と一般的に称する手法を用います。
筆者はこの「トンネル接続」は嫌いなんですが・・・
通信自体が遅くなる上に、不安定要素を自ずと抱えるからです。どのくらい遅くなるのか、実験で示してみましょう。

先ずは、IPv6 ネイティブ接続(いわゆる IPoE 接続) 回線で通信到達時間を図ってみます。
20180217_1.png
最初の10回がトンネル接続回線への通信到達時間。これは若干速い方です。日本国内だからあたりまえか。。
次の10回は google IPv6回線 Webサーバなんですが、最初の10回よりも2倍速いです。
このサーバはどうやらオーストラリアに設置されているようです。
外国へ通信するほうが速い・・・orz

次に トンネル接続な回線からの通信到達時間計測。最初の10回は、互いに同じサーバ同士での実験です。
ほぼ同じ程度なのは当然の結果です。
次の10回は、ホスト名指定だと接続の度にIPアドレスが変わってしまうようなので、試験条件を同じにするために、IPアドレスを直接入力しています。
さすがに最初の10回と約2倍の差はありますが、IPv6 ネイティブ接続と比較すると、約3倍かかっている。。
20180217_2.png
単位はミリ秒(1000分の1秒)単位なので、大したことないだろと思う方居られるかもしれませんが、その考えは大きな間違いで、この差が積もり積もってそのまま体感アクセス速度の差になるのです。
やっぱりネイティブ接続が断然いいですね。。

2018/02/10(土)〔続き〕(自宅の)インターネットで IPv6 が使えるようになった。FreeBSD pfのNAT66 を採用・・

先日の続きです。
単純な構成なら、問題なく IPv6/IPv4 のデュアルスタックで動作するようなのですが、筆者のLAN環境は通常業務とシステム開発の両方を同時進行で行うため、歴史的経緯で以下のような変な構成になっています。(機器類はもっと数あるんですが、かなり端折って書いています)
20180210_1.png
「IPv6 の接続優先度を下げる」という事例は沢山ありますが、その逆は殆ど事例がありません。
何故なら、デュアルスタックにおけるデフォルトの挙動が『IPv6 優先』だからなのです。

当方のように「IPv4 接続がどうしても優先される(IPv6 でつながる場合もある)」という不可解な現象は、Windows10 においては、LANが複数あってインターネットへの接続ができる場合に特定のLANが優先的に選択され、選択されたLANが IPv4 しか通信できないと、見かけ上 IPv4 優先に見えるのではないか、という推測を立ててみたわけです。

具体的には「実験環境用ルータ兼サーバ」と記したサーバに NAT66 を設定することでほぼ解決しました。
'NAT66' とは IPv4 における NAT の IPv6 版といった感じです。
'NAT64' という機構もあるのですが、ここでは割愛します。

当該サーバのLANカード情報を以下に示します。
このサーバには、LANカードを2枚挿しし、相互に通信できるようにしていますが、
re1 → re0 への通信において NAT66 を設定しています。
20180210_2.png
①がプロバイダと接続する IPv6 アドレスで、このIPアドレスは今回使用しているプロバイダの提供機能上、半固定です。
何故「半固定」という謎仕様なのかは、最低限 IPv6 の基礎を理解する必要があるため、今は「そのようなものだ」と思っておいてください。

②が実験・製品開発業務用に使うLAN2のルータIPアドレスで、fdxx: で始まる「ユニークローカルユニキャストアドレス」というもので、IPv4 でいうところの「プライベートIPアドレス」に相当します。

/etc/rc.conf に以下のように設定します。(IPv6 関連のみ抜粋。この他に pf の設定も忘れないように。)
20180210_4.png
/etc/pf.rules (任意のファイル名で可能)には、下記のように設定します:
20180210_5.png これは、必要最低限の設定です。ぼかしてあるところは設定の必要ありません。

こうすることで、どちらでアクセスしても IPv6 で通信可能であれば、IPv6 が優先するはずです。再起動して再度、例のサイトでチェックしてみました。
20180210_3.png
このIPアドレスに見覚えないでしょうか?
この記事の2枚目の画像キャプチャ中で「①」と示したIPアドレスと一致します。
NAT66 が機能し、且つIPv6 アクセスが出来ていることが確認できました。

IPv6 接続を優先すると、「従来の IPv4 接続に時間かかるだろうが!」と思われる諸氏もいるかもしれませんが、それは、IPv6 でインターネット接続が出来ない環境での話。
筆者の環境は「IPv6 でインターネット接続が出来るようになった」ため、IPv4 接続が出来ない状態にならない限り、そういう現象には出くわさないです。

この数年、技術的記事ネタ切れ状態でしたが、暫く「IPv6の基礎」ネタで技術的な記事が書けそうです。(苦笑)

2018/02/07(水)(自宅の)インターネットで IPv6 が使えるようになった。が・・・

昨日、「IPv6 接続が出来るようになりました」というお知らせが電子メールで来たため、確認作業を行いました。10日もかからなかったらしい。
だが、ハマってしまった。。

数ある接続確認サイトで軒並み
「IPv4で接続しています」「IPv6で接続されていません」
と言う表示で、本当に接続出来ているのか? という疑わしい状態。
最終的に接続確認は、これを使いました → http://whatismyipv6address.com/
こんな感じです:
20180207_3.png
しかし、IPv6アドレスで直接Webサイトアクセスすると、これは出来ているので「出来ているっぽい?」という意味不明な状況。
試行錯誤しているうちに、LANカード(ネットワークアダプタ)のプロパティ変更すると、IPv6接続することが判明しました。
具体的には:
20180207_1.png
上記赤枠で示したIPv4を使わない設定という暴挙です。

こうすると、こんな感じになります:
20180207_2.png
IPv6 アドレスが出てきました。でも IPv4 を無効にすると全く使えない。。

筆者の手元で使用している Windows10 は、デフォルトの挙動が IPv6 優先接続になっています。
#そのため、IPv6 を無効にする設定方法が沢山の有志によって掲載されている

しかし、接続はどう見てもIPv4 が優先している挙動です。
IPv6 に対応しているサーバなり、Webサイトなりであれば、優先してIPv6 で接続し、そうでなければ IPv4 で即座に接続するような挙動であってほしいのだが。。

IPv6 に対応しているか否かは、DNS索引で判ります。
今後の記事で少しずつ出てくる(予定)と思っていますが、DNSのIPアドレス情報(正引き、ホスト名からIPアドレスを得る)には
 ・IPv4用の Aレコード
 ・IPv6用の AAAAレコード
の2種類あり、AAAAレコードがあればIPv6対応という判断が出来ます。
昨今では、技術的にはそのような挙動をするような作りを求められているところです。[RFC 8305参照]

今週はこの調査と環境整備で潰れそうです。

2018/02/04(日)(自宅の)インターネット接続プロバイダを変更してみた

6年近く、GMOの固定IP1個プランで頑張っていましたが、
この度、IPv6 を調査して IPoE 接続を使う必要性に迫られてきたのと、通信費関係の請求を出来るだけまとめてくれたほうが管理が楽(註:筆者の固定電話は『ドコモ光』です)ということもあって、プロバイダを乗り換えることにしたのです。

GMOは現状では IPoE 接続での固定IPv6接続には対応しないらしいというのが直接のきっかけですが。。(要するに技術的な懸念)

GMOは、ドコモ光対応のプロバイダで「タイプA」なのですが、固定IPプランは、『対象外』で、「単独タイプ」というものに強制されてしまいます。
「タイプA」「タイプB」「タイプC」は、プロバイダ接続料込の料金がNTT docomo から一括請求(プロバイダ固有のオプションサービス除く)で、割安になるパターンが多いようなのですが、
「単独タイプ」は、従来通りプロバイダ接続料を別途プロバイダへ支払う形の上に、却って割高になるパターンが多いようなので、このあたりはプロバイダ選びに注意する必要があります。

画面見ると、どこのプロバイダに乗り換えたかがわかる人には判ってしまうのですが、以下、「ドコモ光」におけるプロバイダ選びの一例として参考になれば幸いです。

筆者の場合は、2018/01/11 にドコモショップで手続きを行い、2月1日から切り替えということで話が進みました。ちょうど3週間あります。
ドコモショップで手続き後、数日経過すると、プロバイダから電話がかかってきます。これは手続き上必ず経なればならないようです。
要するに、本人確認とプロバイダ変更の意思確認、オプションサービス希望の有無、プロバイダ固有のオプションサービスを利用予定の場合は、その分が別途徴収となるため、決済処理の手続き案内などです。

この電話確認後、更に数日すると契約内容や接続やオンライン手続きに必要なIDやパスワードが記された書類が郵送されてきます。

さて、2月1日になって、いざ接続設定します。
繋がるんだけど、固定IPで接続しない。。。何か変。。何か書類以外の情報が無いかと、オンラインで契約状態を確認します。
ん?? 「開通待ち」って何?? プロバイダでは認識されていないけど何故かつながっている??

プロバイダから送られてきた書面には下記の記載があります。

え、2月1日からって言ったのだけど。。
改めて、ドコモショップで交付された申込書類をチェックします。
先ずは変更内容:


これは、「単独タイプ」から接続プランが変わるため、これを廃止するというものですが、『工事日』『開通日』というのが・・・。え、工事日ていつよ??? 開通日って???
そういえばきちんとした説明がなかったな。。こっちはこっちで2月1日からと勝手に思っている。。


これが新しいプラン。「タイプB」に変えるという申込書です。
ちなみに 2017年1月というのは、筆者が「ドコモ光」に変更した月で、2年定期契約なのですが、今回のような場合は「承継」されるようです。
つまり、プランが変わるからといって、2年契約解約扱いにはならず、この関係で解約金だの違約金だのは一切発生しないということです。

注意したいのは、筆者の場合は「単独タイプ」→「タイプA/B/C」で、この変更パターンのみ手数料は発生しません。
それ以外の変更パターンで違うプロバイダへの変更は、どのような場合でも税抜き3000円の手数料がかかるようです(同一タイプ内でもプロバイダ変更は変更手数料の請求あり)。
但し、「単独タイプ」におけるプロバイダ変更は、ドコモ光から見たらプロバイダ対応の話は預かり知らぬことなので、この場合、ドコモ光は関係ありません。

筆者の場合は、ちょっと急いで解決しないといけない状態だったので、プロバイダのカスタマサポートに電話しました。
どうやら、最初の画面キャプチャにある「開通待ち」は表示の問題という説明を受けたのですが、これはNTT側から契約データ更新の通知が無いと変わらないらしい。
取り急ぎ解決しなければならない事案は「固定IP接続したい」だったので、この件はカスタマサポートで解決できました。
いずれにせよ、このプロバイダではカスタマサポートへ直接連絡しないと駄目なようです。(この旨、説明書きは小さく出ています)

現状はこの状態:

IPv6 接続したいのですが、「開通待ち」が解除されないとできないようです。画面表示の問題というよりは、NTTフレッツ網とプロバイダ間の情報疎通の問題。NTT側の情報更新間隔が長すぎることに問題があるのでしょう。
当方の場合は、あと10日くらいかかりそうだとカスタマサポート担当者に言われました。。。
こういうつまらないところで日本のICT技術発展が阻害されてるんだよね、、、昨今の夜になるとネットが遅くなるという問題も直接の要因はNTTの PPPoE 接続。

ドコモ光の契約内容はオンラインで確認でき、現在のプランは以下のようになっています:

オンライン上で変わるのも2日かかっているし、この情報がプロバイダ側に伝わらないと、 IPv6 接続申し込みもできない。
契約上の変更日から1ヶ月は待つつもりで対応したほうが良いかもしれません。時間かかりすぎだけどね。。

2018/01/26(金)コントロールパネル改良作業開始

大多数の方々にはどうでもいいことではありますが・・・
弊社コントロールパネル https://ctrl.basekernel.ne.jp/ の改良作業をしています。

改良内容は:
○ 左メニューをボタン化して操作性改善
○ IPv6 対応(DNS AAAA レコード、PTR レコードの追加サポート)
○ サブドメイン、逆引きゾーン対応

といった、DNS絡みが中心です。
逆引きゾーンは弊社の場合、弊社技術者以外は一般には使うことがない機能ですが、
どのようなニーズにでも対応できるように公式提供する予定。
以下は、開発版の画面。提供時には変わるかもしれません。

これが出来ないと、次の段階でLANのIPv6 対応環境が整わない状態で、先に進まないのです。

IPv6は今まであまり必要性が無かったため、特に対応しないままでやってきましたが、
今年あたりからIPv4・IPv6併用の案件が増えてくることが予測できるため、今のうちにシステム構築をある程度やっていこうという状況だったりします。

目下のところ、IPv4 とは毛色が全く違うため、IPv6 の基本的なところから学習中です。

〔2018/02/04 追記〕
システム構築の作業は終わり、これからマニュアルの更新作業ですが、これが大仕事。。。orz

2017/12/09(土)FreeBSD Ports のgnuplot は使い物にならなくなった・・・

gnuplot とは、グラフを描画するための有名なソフトウェアで、かれこれユーザ歴だけは15年ほどになります。

弊社では今まで gnuplot を安直に FreeBSD Ports コレクションからインストールしていたのですが、余計なものが依存関係で入って来るのが悩ましいところでした。

そこへいつものように FreeBSD Ports コレクションからアップデートを図ろうとしたところ・・・
なんと、X11 ライブラリ群がデフォルトで依存関係として入ってしまうようになったのです、、、
X11 サポートを外すことが出来なくなった。。致命的です。

弊社の環境では、単純にグラフが PNG や GIF,JPEG 形式で描画できれば十分で、X11 なんぞ邪魔!!!
ということで、止む無くソースコードから構築することにしたのです。
ちなみに現時点での最新は 5.2.2 です。

多機能な分、構築作業が複雑そうだなという先入観が強かったのですが、結局、
# setenv CPPFLAGS '-I/usr/local/include -I/usr/include'
# setenv LDFLAGS '-L/usr/local/lib -liconv -L/usr/lib'
# ./configure --with-readline=gnu
# gmake
# gmake install
で、済むようです。FreeBSD 11.1R-p5 (amd64) の環境で確認しました。

注意点としては、gnuplot 本体をインストールする前に、libpng 等のグラフィックスライブラリ、readline ライブラリ、IPAやkochi等の日本語フォントを予め Ports などでインストールしておく必要があります。

-liconv オプションは、どういうわけか libiconv がリンク出来ないというエラーを吐いて構築が中断する状態になるので、その回避策として追記したという状態です。

2017/12/07(木)PowerDNS 4.1 リリース(with PostgreSQL)

ということで、弊社のマスターDNSを PowerDNS 4.0.4 から PowerDNS 4.1.0 に更新してみました。

「久しぶりの記事がこれかい」と呆れられると思いますが。。orz
どうやら、今回の『売り』は、「当社比で PowerDNS 4.0.x から 最大で 400% 高速化した」ということらしいです。

単純に「4.0.4 の使用をやめて、セキュリティFIX された 4.0.5 以降にしなさい」という警告メッセージが出ていたのがきっかけなのですが。。orz

さて、PowerDNS 4.1.x に更新するにあたり、PostgreSQL を使用し、且つソースコードから構築する際の configure オプションが変更になっています。

PostgreSQL サポートに関しては、
 --with-pg-config=/usr/local/pgsql/bin/pg_config
これだけでいけるようになったようです。
ちなみに弊社では、ソースコードから
# ./configure --enable-libsodium 
       --with-pg-config=/usr/local/pgsql/bin/pg_config 
       --enable-perl=yes
        --with-modules="bind gpgsql random"
(実際には改行せず、1行で入力)のようにして構築しています。
環境は、FreeBSD 11.1R-p5 amd64版です。

2017/10/17(火)D級オーディオアンプ


発売開始当初に入手したものの、
「周囲にまき散らす電磁ノイズがひどい」という話だけを何故か聞くので保留していた代物ですが・・・

作業場(謎)に様子見のために設置してみました。
この基板には TI社のTPA2001D1 という、今では有名なICが2つ乗っかっています。

アナログ回路のA級・B級アンプしか知らない筆者にとって、
無信号時の背景ノイズが殆ど無いのは驚きました。これもまた評判どおり。
ICの発熱もほとんど感じません。

気になる電磁ノイズは思ったほどではありません。しばらく使ってみることにします。

2017/10/16(月)CGI に Python を利用し、PostgreSQL を使用する

どちらかというと、自分メモ。

CGIというのは、環境変数からパラメータを受け取り、
標準出力へ HTTPヘッダ群とコンテンツを出力する、というのが基本的セオリーで特別なことは必要ないです。

しかし、昨今の Python3系では、WSGIインタフェースというものを意図してCGIを制作するのが普通になっており、これはパフォーマンスの点で有利とされています。
Apache に mod_wsgi 拡張モジュールをインストールする必要があります。
現在のところ、標準モジュールにはなっていないため、別途インストールが必要です。

FreeBSD11 における mod_wsgi インストールは、ソースコードから下記のように行うのが確実。
pip (後述しています) でのインストールは、環境判定を誤認識したり変にエラーを吐いたりすることが環境によっては発生するため、筆者は全くお勧めしません。
# cp mod_wsgi-4.5.20.tar.gz /usr/local/src 
# cd /usr/local/src
# tar xvzf mod_wsgi-4.5.20.tar.gz
# cd mod_wsgi-4.5.20
# ./configure --with-python=/usr/local/bin/python3.5 --with-apxs=/usr/local/apache2/bin/apxs
# make
# make install

--with-apxs を指定することで、お使いのサーバにおける環境に合わせた構築が出来ます。
通常、mod_wsgi は、上記の場合、/usr/local/apache2/modules/ 配下に動的リンクでインストールされます。

Apache への mod_wsgi に対する設定は、以下を参考にどうぞ:
LoadModule wsgi_module modules/mod_wsgi.so

WSGIDaemonProcess cgi-bin user=webadmin group=webuser processes=1 threads=5 WSGIScriptAlias / /home/webroot/hoge/cgi/app.wsgi <Directory "/home/webroot/hoge/cgi"> WSGIProcessGroup cgi-bin WSGIApplicationGroup %{GLOBAL} </Directory>

ちなみに WSGIインタフェース自体は、Python に特化する目的を持つものではありません。
この辺りは勘違いされている諸氏が結構多いようです。

Perl だと mod_perl という Apache に組み込む形での有名な高速化拡張モジュールがありますが、それと同じようなものでしょうか。
Python 以外では導入メリットが見えにくいです。

最近のPerl はそれ自身が高速化してきているので、mod_perl 導入のメリットが見えにくくなってきているのと、mod_perl を組み込んだ状態にてCGIをスレッド動作させると原因不明の不安定な動作になったり、Perl 5.26 にすると、静的モジュールでは何故かインストールできないなど、色々問題があり、筆者のサーバでは mod_perl の利用は見合わせている状況です。

次に、Python から、PostgreSQL インタフェースを扱うモジュールをインストールするのですが、このインストールに先立ち、pip というサポートツール(?)を導入する必要があります。
Perl で言うところの CPAN に該当するものですね。

# python3.5 -m ensurepip

あれ? と思った諸氏も居られるかもしれません。
多くのサイトには「Python 3.4 以降では、pip は同時にインストールされる」と説明されているからですが、FreeBSD11 にて Ports から Python を導入した場合、pip は導入されません。FreeBSD11 にて Ports から Python を導入した場合、pip は手動操作で導入しないと駄目らしいです。
でも、pip は今後のメンテナンスで必須になるものの、今回は使いません。

最後に Python の PostgreSQLインタフェースモジュールをインストールするのですが、これもpip では環境誤認識をするため、ソースコードを持ってきて、下記の手順が確実です。
事前に、PostgreSQL 本体をインストールしておくことは言うまでもありませんね。
# cp psycopg2-2.7.3.1.tar.gz /usr/local/src
# tar xvzf psycopg2-2.7.3.1.tar.gz
# cd psycopg2-2.7.3.1
# setenv PATH '/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/pgsql/bin'
# python3.5 setup.py build
# python3.5 setup.py install
ここで重要なのは、pg_config コマンドのパスを、環境変数 PATH に含めることにあります。
Python の psycopg2 は、Perl における DBI と DBD::Pg の組み合わせに相当します。
OK キャンセル 確認 その他