2018/04/10(火)IPv６の基礎(3) - 機器設定時に必要と思われる知識
2018/04/10 14:04
IPv6 アドレスは記述自体が長くなるため、一定の省略記述ルールが決められています。
しかしながら、必ずしも省略記述をする必要はありません。
むしろ、慣れないうちは敢えて省略記述をしない方がよいのです。
ですが、実際には先駆者によって多用されているので、ここでは省略記述ルールを紹介します。
「省略記述」は全て、数字の'0' (ゼロ) を省略するルールが定義されています。
先ず、「各フィールドの上位桁の'0'は省略可能」です。ただし、'0000' だけは全てを省略せずに'0'を記述します。
次に、「'0000' のフィールドが連続する場合は、該当部分を '::'(ダブルコロン)で省略可能」です。
但し、これが使えるのは１回だけです。
また、'::'(ダブルコロン)は、最も長く省略できる部分に適用すべき、と規定されました。
なので、厳密には上記例の３番目も×です。
２番目の 2001:db8:0:3::1 のみが正解となります。
更に、IPv6 表記でしか設定できない環境下で、IPv4を表記する場合の記述法も定義されています。
現在は、「IPv4 射影アドレス」の記法が
ただし、「IPv4 組み込みアドレス」もたまにみかけるので、知っておくとよいです。
2018/03/28(水)IPv6 の基礎(2) - ネットワーク機器類の取扱説明書を見る時、得意になれそうな知識
2018/03/28 02:52
今さら誰にも聞けないレベルになりつつある内容ですが、この「備忘録」が役立てば幸いということで。。
今後、従来からのＩＰプロトコルは、IPv6 と区別するために IPv4 と称することにします。
世の中での表記区別がそうなっているため、それらに倣うことにしました。
今回はIPv6 アドレスの形式です。
IPv4 では当初、クラスＡ，クラスＢ、クラスＣ、クラスＤ、クラスＥ というカテゴリ分けで、ＩＰアドレスブロックの割り当てがされ、サブネットマスクは固定でした。
以下のような感じです：
クラスＡ 1 ～ 126 で始まるＩＰアドレス (サブネットマスク 255.0.0.0)
クラスＢ 128 ～ 191 で始まるＩＰアドレス (サブネットマスク 255.255.0.0)
クラスＣ 192 ～ 223 で始まるＩＰアドレス (サブネットマスク 255.255.255.0)
クラスＤ 224 ～ 239 で始まるＩＰアドレス (サブネットマスク 255.255.255.255)
クラスＥ 240 ～ 254 で始まるＩＰアドレス
このうち、クラスＤはマルチキャスト通信専用で使われており、クラスＥは各種実験・特殊用途向けで一般利用はできないことになっています。
０と255で始まるIPv4 アドレスは仕様的に使用不可、127で始まるIPv4アドレスは、ループバック専用で、これは用途が仕様として強制されています。
クラスＤにサブネットマスクの概念そのものがなく、クラスＥには、サブネットマスクの規定はありません。
＃なので、クラスＥの領域は実際は「IPv4 枯渇を無視して割り当てされずに温存されて」います。
クラスＡ，クラスＢ、クラスＣのサブネットマスクは、1992年６月に RFC1338 で初めて CIDR（「サイダー」と称する模様） と言うクラス分けをバッサリと捨てる概念（＝クラスレス化）が提唱され、 1993年９月の RFC1519 を経て、2006年８月に RFC4632 で現行のものになりました。
さて、IPv4 は、アドレスが４オクテット（４バイト）固定長で構成されます。
１オクテットずつ、ドット区切りの10進数で表記するのが通例です。
１オクテットで表現できる１０進数の整数は０～255 なので、各ドット間の数字は必ず０～255の範囲になります。
これに対して、IPv6 は、アドレスが16オクテット（16バイト）固定長で構成されます。
実にIPv4アドレス総数(約43億)の ２32倍 × ２32倍 × ２32倍 ＝ ２128 個(約340澗 ≒3.4 ×1038) になり、『これだけあればアドレス枯渇問題は将来に亘ってほぼ皆無だろう』ということになっています。
アドレス表記も16進数表記です。これはエンジニアの間では常識ですが、16進数のほうがディジタル機器のあらゆる整数数値において親和性が非常に高いためです。
16進数表記の a ～ f は、基本的に小文字を使うように規定されています。[RFC5952, 2010年８月]
「16進数」がわからない方は、google などを使って各自調べてください。
合わせて「２進数と16進数」の関連を知ることで、何故16進数の方が親和性が非常に高いかが理解できるかもしれません。
IPv6 のアドレスは、２オクテット（２バイト）毎にコロンで区切って表記します。
そして、コロンで区切った各々の部分は「フィールド」と呼称します。
このフィールドは、省略表記（別記事にて後述）しない限り、桁数は４桁固定で必ず８個になります。
IPv6 には「サブネットマスク」という概念がありません。
その代わり、IPv4 のクラスレス化で導入した CIDR の考え方を踏襲して、「プレフィックス」「プレフィックス長」という概念が導入されました。
IPv6 における「プレフィックス」とは IPv4 で言うところの「ネットワークアドレス」、
この長さをビット長で示したものが「プレフィックス長」になります。
2018/02/20(火)IPv6 の基礎(1) - ネットワーク機器類の取扱説明書を見る時、得意になれそうな知識
2018/02/20 05:09
あくまでも「備忘録」です。はい。
筆者がかねてから想像していたとおり、今まで嗜んできたIPv4 とは毛色が違うし、似て似つかないものがあります。なので、初心者から「志を持って」（何のだ・・）猛勉強中です。
そんな中、各種のネットワーク機器を家電量販店やＩＣＴ機器専門店などで買うときや、買った後で知っておくと、
IPv4 は、軍事・学術研究から行き当たりばったりで進化してきた技術ですが、
IPv6 は最初から民生用途が意図されていて、万人共通の定義づけがいくつかあります。
ここがまず IPv4 と違う世界ですね。
IPv6 の世界で先ず使われる用語の基礎用語として、以下があります：
■ ノード
IPv6 通信機能を持った機器全てを指す。
具体的には、パソコン、ネットワークプリンタ、ルータ、サーバを指し、ハブやスイッチングハブなどはノードに含みません。
図示していませんが、スマートフォン、タブレットも「ノード」です。
ノードは「ルータ」と「ホスト」の２つに区別されます。
■ リンク
ハブやスイッチングハブ、無線ＬＡＮアクセスポイントなどを介して、ルータ超えしないで直接イーサネットやＷｉＦｉで通信可能な装置間接続を指します。
ルータ同士の通信も「リンク」です。
ルータ超えの通信は「リンク」ではありません。
■ サイト
１つ以上のリンクからなるＬＡＮを指します。
ルータが複数あっても、インターネットに出ていかずに別のリンクと接続するＬＡＮは、接続ルータ先のリンクもまとめて「サイト」になります。
ただ、この概念は古い IPv6 の資料には出てくるのですが、現在は使いません。
古い IPv6 の資料を読むときに必要となります。
■ ルータ
ノードのうち、リンク外部との通信中継・リンク内部通信の取りまとめを行う機器を指します。
インターネット接続には不可欠な装置になります。
■ ホスト
ノードのうち、ルータ以外の全ての機器を指します。
受信時、自ホスト宛は処理できるが、他ホストへ転送出来ない機器全てがホストです。
パソコン、ネットワークプリンタ、サーバ、スマートフォン、タブレットなどは、典型的なホストの一例です。
リンク内でも他ホストへの送信は、基本的にルータが取りまとめて処理します。
■ 近隣ノード
リンク内で通信が直接到達可能なノード全てを指します。
これらは概念として理解しておくと、後々 IPv6 の理解が楽になります。
2018/01/26(金)コントロールパネル改良作業開始
2018/01/26 04:23
弊社コントロールパネル https://ctrl.basekernel.ne.jp/ の改良作業をしています。
改良内容は：
○ 左メニューをボタン化して操作性改善
○ IPv6 対応(DNS AAAA レコード、PTR レコードの追加サポート)
○ サブドメイン、逆引きゾーン対応
といった、ＤＮＳ絡みが中心です。
逆引きゾーンは弊社の場合、弊社技術者以外は一般には使うことがない機能ですが、
どのようなニーズにでも対応できるように公式提供する予定。
以下は、開発版の画面。提供時には変わるかもしれません。
これが出来ないと、次の段階でＬＡＮのIPv6 対応環境が整わない状態で、先に進まないのです。
IPv6は今まであまり必要性が無かったため、特に対応しないままでやってきましたが、
今年あたりからIPv4・IPv6併用の案件が増えてくることが予測できるため、今のうちにシステム構築をある程度やっていこうという状況だったりします。
目下のところ、IPv4 とは毛色が全く違うため、IPv6 の基本的なところから学習中です。
〔2018/02/04 追記〕
システム構築の作業は終わり、これからマニュアルの更新作業ですが、これが大仕事。。。orz
2017/12/09(土)FreeBSD Ports のgnuplot は使い物にならなくなった・・・
2017/12/09 05:34
弊社では今まで 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)
2017/12/09 05:03
「久しぶりの記事がこれかい」と呆れられると思いますが。。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"（実際には改行せず、１行で入力）のようにして構築しています。
環境は、FreeBSD 11.1R-p5 amd64版です。
2017/10/16(月)CGI に Python を利用し、PostgreSQL を使用する
2017/10/16 02:35
# 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 を組み込んだ状態にてＣＧＩをスレッド動作させると原因不明の不安定な動作になったり、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 の組み合わせに相当します。
2017/10/13(金)はんかくさい日報を新システムへ移行しました。
2017/10/13 05:11
しかし、見栄えは以前よりシンプルになってしまいました。
移行が何故か上手く行かず、更にデータの一部を壊してしまったため、
移行そのものを全て手動操作でやる羽目になり、足掛け３日掛かってしまいました。
また、手動操作移行の故、記事番号・記事URLが変わってしまい、Google 等への反映は１カ月程度かかるものと思われます。
2017/10/07(土)メールサーバへの攻撃事情
2017/10/12 22:20
こういう障害は２０年運用していて初めてのことでして・・・
どうも直接の原因は、これです。ＩＰアドレスも晒します。 ↓
52.166. 系のＩＰアドレスの登録上の使用者は、皆が誰でも知っている企業です。
調べればすぐ判るので、ここでは敢えて言及しません。
なんと、概ね 10秒毎にＳＭＴＰ認証を失敗しては繰り返しています。
文字列 'UGFzc3dvcmQ6' は、'Password:' を Base64エンコードして得られる文字列です。
ＳＭＴＰ認証も現在は数種類あって、これはセキュリティレベルが低いとされている LOGIN 認証と言われる種別。
サーバ負荷をこのようにして意図的に高くし、サーバ障害やサーバダウンを引き起こそうとする愉快犯か、何等かの意図を持っている連中の仕業です。
10/5 の 21:00 頃に、現在一緒に仕事をしている同業者がこのログを見て、 Twitter で呟いたそうです。
『○○社のネットワークから、メールサーバへの攻撃を受けている』と。
そうしたら、52.166. 系からの攻撃は「ピタッ」と止まりました。
これには余りの素早さに笑ってしまいましたね。勿論、対応された方々には感謝申し上げます。確信犯的にやっていたのであれば、逆に許せないですが。
で、今の攻撃主体はどうやら ↓ の模様。これもＩＰアドレスを晒しておきます。
間隔は４分毎ですが、攻撃と言えるレベルです。
時折「セキュリティ対策業者がセキュリティホール探しのためにやっている」なんていう話をする奴がいますが、ならサーバ負荷を意図的に上げるような行為を何故やる？ という 疑問が必然的に湧きますね。
SMTP サーバ自体の接続拒否機能は、SMTP認証処理成功後に機能するようで、認証前にＩＰアドレスや接続元ドメインなどで強制切断するようにはなっていないようです。
これをするには、ファイアウォールを使わないと駄目ですね。
この手の設定は、微々たるものだとしても傘下ネットワーク全体のパフォーマンス低下を招くので、出来れば余計なことはしたくない。
SMTP サーバ単体で、接続そのもの自体を拒否できる機能が欲しいと考えるのは自分だけでしょうか。
ま、発信元で犯人の処分をしてくれるのが最も有益なわけですが・・・
2017/08/28(月)powerDNS 4.0.4 は FreeBSD10 以降でソースコード構築途上でコンパイルエラー
2017/10/12 22:17
コンパイルを始めたばかりのところで、
ext/json11/json11.cpp:153:24: error: invalid operands to binary expression
('nullptr_t' and 'nullptr_t')
return m_value < static_cast<const Value<tag, T> *>(other)->m_value;
~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ext/json11/json11.cpp:209:5: note: in instantiation of member function
'json11::Value<json11::Json::Type::NUL, nullptr_t>::less' requested here
JsonNull() : Value(nullptr) {}
^
のようなエラーを吐いて構築不能になります。どうやら clang/LLVM 4.0.0 環境が少なくとも全滅です。
FreeBSD 11 はまさにこの環境。
% /usr/bin/clang -v FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) Target: x86_64-unknown-freebsd11.1 Thread model: posix InstalledDir: /usr/bin日本語の情報が殆ど無いですね。
これは ext/json11/json11.cpp と ext/json11/json11.hpp の２つのファイルを修正することで解決します。
具体的な修正内容は下記リンクです：
json11 fixes from upstream via pdns #135それにしても日本人の感覚だと、この修正量と内容だとバージョンアップしてソースコード一式を再リリースするものですが、開発元であるオランダ人の感覚は違うようです。
https://github.com/PowerDNS/weakforced/pull/135/commits/9e4d9bd48663e849be13e2cb5fcf64f917aec608