そろそろ企業向けにIPv6本格導入考える時期が来たんじゃない？

各企業において様々な働き方に対応できるインフラ構築も落ち着いた時期じゃないかと思いますが、IPv6だけは相変わらず導入できそうな気配を感じませんね。

やろうと思えばできるのですが、企業インターネット黎明期あった、グローバルアドレスを社内IPとして利用してしまう失敗が脳裏をよぎって躊躇してしまいますよね。「OCNエコノミーで安定高速インターネット接続環境を！！」みたいなことを言ってた時代に現地調査はいると「170.0.0.1/24」とかが設定されているネットワークに出会うことがたま～にありました。社内ネットワークで利用できるのは3種類のプライベートアドレスは今では当たり前ですが、Windows3.1時代にネットワークを構築した企業にとっては当たり前というとかわいそうですね。RFCの公開が1994年ですし。

インターネット接続環境はインフラ環境が単純な家庭用サービスが先行して普及するのは自然のことで、IPv6もその一つですね。フレッツ光プレミアム以降のサービスを契約すると気にすることなくIPv6対応ルーターが設置され利用できる準備が整いますので、利用者は意識してなくてもIPv6通信の普及は進むし、PPPoE遅い問題を目にした方はIPv6の積極的な導入に動いたのではないでしょうか？

そういう流れで会社のインターネット遅い！！IPv6対応して高速化しろよ！！って意見がちらほら聞こえているのです。企業ネットワークを変化させることって難しいのです。トップダウン型で取り組み始めても費用を提示するとNGってこともあるし、そもそも製品の選択肢が無かったり、性能不足、ノウハウ不足、パートナー不在と費用提示の前にとん挫することもあります。うまくいっても利用者側から変更を拒否されたり、利用システムが未対応だったりと課題もたくさんあり「今は変化できない」がず～っと続いてしまいます。

新規小規模拠点なら導入課題は少ないですが、既存小規模拠点の場合は予算的に不可というケースが多いのでは？一般家庭用機器ネットワーク拠点なら設定変更程度で済みますけど、VPN装置があったりすると対応機器に買換えが必要だったりしますが”壊れていない”　”今問題なく業務出来ている”という状況と”見えない効果”がブレーキを掛けます。だって「高速化した分、売り上げも上がるよね？」って現場が言われると無理、いらないって答えるよね。

そんな感じで変化はとても難しいのですが、インフラ担当としては何年も先を見据えて機器選定をしているので買換えタイミングでは高速化、もちろんIPv6対応も考慮しているわけです。機器に関しては予算が付けば解決できるし、利用システムも対応が徐々に増えているので何とかなるかな～という感じではあるのですけどね。

そんな中、絶対に無理だな～と感じているのが”定番設計が存在しない”という問題。

IPv4には”インターネット接続ゲートウェイでNATとLAN側はプライベートアドレスを使う”が最低限の定番設計で、拠点間で異なるサブネットを使っていれば統廃合に対して部分的な変更だけで対応できる。

この定番設計で構築されたネットワークをIPv4/IPv6デュアルスタック化しようとするといくつかの問題が解決できない。「あ、無理だ～」というのが私の感想。

何が無理って「プロバイダー変更のインパクト」「IPv4と同じセグメント分けが出来ない」って話だけでも、結構無理～って感じる。

プロバイダー変更のインパクト

IPv４はゲートウェイでグローバルアドレスに変換して、内部はプライベートアドレスを使用するので、プロバイダーを変更した際にグローバルアドレスが当然変わるけど、ゲートウェイの設定変更だけで利用者に影響でない。

これが、IPv６の場合、内部もグローバルアドレスを使うので、プロバイダー変更ですべてのIPアドレス設定に影響が発生する。自動設定だから問題ない？いや、端末への反映時間やDNSやサーバーの設定変更などを考慮すると「ISP障害だから別のISPに切り替えて対応しよう」ってのがIPv４のように気軽に出来ない。常に利用できる状態にするという設計になるのだろうか？

または、IPv4と同じようにユニークローカルアドレス使えばよいじゃないって話になるんだけど、NAT6対応のゲートウェイが必要になる。すべての機器が対応していれば話は簡単なんですけどね。

IPv4と同じセグメント分けが出来ない

IPv6はグローバルアドレスを使う前提なので、プロバイダーから割り当てられるIPアドレスを分割できる/56や/48だと良いのですが、/64だと無理ってなります。だって分割の最小が/64だから・・・これ以上分割できない。

PPPoEや専用線契約なら/48など潤沢なアドレス範囲を使えるので分割できるけど、IPoEだとひかり電話契約ありで/56、ひかり電話契約なしだと/64になるので必要セグメント数にもよるけど1:1に出来なければIPv4のセグメント統合が必要になる。

2022年現在はIPv6に変更する目的は「輻輳状態にあるPPPoEを迂回する」だと思うので、輻輳していないかもしれないIPv6のPPPoEは避けたいと考えるし、専用線費用なんて割に合わない。1Gbpsの専用線って月額いくらなんだ？100万位？

デュアルスタックへの準備は本格的に考えているけど、課題はたくさんありそうだし、何より定番設計が無さそう。ってのが一番痛いよね～。まだまだ企業内ネットワークのIPv6対応は先の話になりそう。

世の中のネットワーク技術者の皆さんお買い物どうやってる？

 パソコンの購入はすでに落ち着き、円安による値上げが気になってる時期ですけど、ネットワーク機器って皆さん調達できているんですかね？

春ごろに注文した無線LANアクセスポイントはやっと届くとリセラーから連絡がありました。

24Port LANスイッチの納期照会したら”未定”という回答。

４月発表の新製品はいまだ商品登録されておらず見積もり出てこず。

L3スイッチは半年以上待ち

ファイアウォールは２ヶ月待ちと。

基本海外製品であるNW機器は納期１か月は標準ですけど、未定とか辛すぎ

もちろんメーカー、製品を選ばなければ調達できるけど計画的な設計は不可能。

壊れたらどうする？

追加購入が必要になったら・・・

拠点が増えたら・・・

コロナ騒ぎも落ち着きを見せ、出勤率も徐々に高くなっている段階で入手不可という状況はつらいですね。

promtailを使ってiisのW3Cログを取得する

Grafana Lokiのpromtailをつかってiisのログを収集する際、timestampはログの取得日時が標準の動きで、新しいログの取得では大きな問題にはならないと思うけど、今までの記録やpromtailの実行直後のログは正しい時間が記録されないので困った場面に遭遇するかもしれない。これに備えてログに記録された日時を採用するように設定することは非常に重要なことだと思う。

ポイントは、W3Cログの日付はUTCで記録されている点です。

というわけでscrape_configs部分をYAMLで紹介。

scrape_configs:

  - job_name: system

    static_configs:

    - targets:

        - localhost

      labels:

        job: iis

        __path__: c:\inetpub\logs\LogFiles\*\*.log

    pipeline_stages:

    - match: 

        selector: '{job="iis"}'

        stages:

        - regex: 

            expression: ^(?P<datetime>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2})

        - timestamp: 

            source: datetime

            format: 2006-01-02 15:04:05

            location: Etc/UTC

スペースの数はYAMLではとても重要なので書写する際は注意しましょう。

iisのログはstatic_configsで取得しjob名を"iis"と設定しています。
__path__:は利用環境に合わせて修正してください。

取得したログからtimestampを取得するための設定はpipeline_stagesのmatchで指定します。

job名"iis"に対し正規表現で行頭から日付部分を抽出し、timestampの書式を指定します。
format: の日時はドキュメントにも定義されている定数なので変更するとうまく動作しません。初めて設定した時はなんで2006年なんだ？と悩んだのと「2006-01-02 03:04:05」に設定していてうまく動作しなかったのですが、03は12時間、15は24時間になるので正しく認識しないよね。

後はlocation:で正しいTimezoneを指定してこのログはUTCで記録されていることを明示します。

この設定を行っていれば、過去のログは当時の日付で記録されるので安心です。

楽天モバイルさんよ～

 今までありがとう。２～３か月後には旅立ちます。

微妙なエリア住民だけど価格的にメリットがあったけど、価格が同じなら当然エリアの広いサービスを選ぶよね。パートナー回線エリアも縮小しているようだし。

ということで、キャリア変更しますのでよろしく。

次のキャリアですが、

OCNモバイル、IIJmio、Yモバイル、LINEMOあたりを狙っています。
データ少な目でDかY回線。
個人的な思いもあってDDI系列とKDD系列とはお付き合いしたくないんだ。

eSIMにしてRakuten Handを継続することも可能だけど、
せっかくのMNPなので、できれば安価にiPhoneに変えたい。
でも便器より汚いらしい受話器の中古はちょっと嫌なので新品。

手始めに散髪屋の隣にあったYモバイルに突撃してみた。
もちろんiPhone SE3 1円という看板が出ていたから。

店員さんに1円について詳しく聞きたいというお願いをして説明を聞いたのですが、看板にあった24ヶ月のキーワードが一切出てこない。キャンペーンは土日に実施していて、金曜日に内容が確定して、内容は毎週異なり機種も微妙に異なる。
iPhone希望ならソフトバンクモバイルを契約する必要がある。半年後にYモバイルに変更すると短期解約ペナルティーもなく差額を考慮してもお得だと。

ちょっとパニックだ。入店前の情報と一致せず騙されている気分だ。

iPhone miniを希望するなら2年が区切りでそれ以降の分割は機種変で不要になる。（やっと知っている情報が出てきた）でも、iPhoneSEをキャンペーンで購入して予備として持ってた方が壊したときに使えるのでキャンペーン利用はお勧めだと。ここでキャンペーンは買取ということを理解した。

私にとってはかなり裏技のように感じたけど、店員さんにとっては当たり前の契約方法らしい。今まで量販店とキャリア系のショップしか経験なかったので価格面を中心に話をしてくれてとてもありがたかった。

いやぁ～勉強になった。

DevToysは開発者だけのツールではない(Base64)

 Intuneの構成プロファイルを作成すると「Base64でエンコードする必要があります」なんて求められる時、インターネット上にはBase64に変更してくれる便利なサイトがありますよね。

検索で見つけたサイトを使おうかな～と思っちゃいますよね。と同時にこのサイトは大丈夫なのか？と思ったり。ほかにBase64エンコードしてくれるツールなんか知らないし、企業秘密が含まれた情報でもないけど、最近だとLog4jの脆弱性を狙った文字列を付与されないかとか心配だったりしますよね。

あらゆるリスクを考慮すると出来ればサイトを使わず変換することを希望するのですが、今まで使いやすいな～と感じたツールが無かったんですよね。準備が面倒だったりコマンドベースだったりと、利用頻度も少ないのでサイトを使っていたのですが、見つけちゃいました。

「DevToys」です。名前から想像するにIT管理者向けではないと感じるかもしれませんが、結構使える機能がそろっています。その一つが「Base64エンコード/デコーダー」

変換したい文字列を張り付けるだけでエンコードされた文字列を得ることが出来ます。
もちろん逆もできるので確認にも使えますね。

インストールもMicrosoft Storeから出来るのでとっても簡単。

そのほかにも構成ポリシーの中にはJSON形式の設定文字列を１行表示で入力する必要があったりします。これも作成や修正ではインデント表示でないと構造が分かりづらく苦労しますけどDevToysを使えば簡単に変換することが出来ます。
このツールを知らないときってエディタで改行やスペースを地道に修正していたので地味に効率が悪かったんですよね～

ちょっとお勧めなツールの紹介でした。

iCloudに移行するための作業(アカウント削除したら汗かいた！！)

 エクスポートのダウンロードも完了し、サブスクリプション削除、アカウント削除とすすみ、G suite Legacy解約手続きはすべて終わりました。

これからは一般のご家庭で使うGmailアカウントでこのブログやYouTubeチャンネルを管理していきます。

作業が終わり、さて、Gmailのチェックをしようと開くとエラー500番。ログインできなくなったんですけど・・・いや、Gsuiteアカウントは削除したよ。でもGmailアカウントでサインインできないってどういう状態？えっとAndroid携帯も使っているんですけど・・・

はい、Google村八分にされました。

というわけではなく、二つのアカウントを切り替えられるように連携していたのですが、片方のアカウントが削除されたのでエラーになっていたようです。
ちゃんとサインアウトして、再度サインインすると使えるようになりました。

めっちゃ汗かいたけど・・・

あせったわ～～。

iCloudに移行するための作業(3/12までの作業)

 久しぶりにまとめると、特に何もしていません。
移行作業完了したし。

とはいえ、まだね、Gsuiteアカウントにメールが届いているんですよ。
某車メーカーや〇ONYのDMとか・・・この人たちってDNS見てないよね。だいじょうぶなんかな？

そろそろね、解約手続きをしないといけないと思うんです。
なので、エクスポートを実行しています。

まだ完了していないのでどういうフォーマットで取得できるかわかりませんけど、一応確認しておこうかな～というレベルです。

最近ね、仕事で社内向けDNSサーバーの更改検討をしておりまして設定とかを見直しているのですが、ほんと上の2社のような存在は困りますよね。
数分程度のTTLなら多少無視するのは許せますけど、かれこれ１か月はさすがに許容範囲を超えていますよね。

MXレコードを書き換えてちゃんとTTLの指示通り届きだすサーバーもいれば、いまだに旧MXレコードで指定しているサーバーに送ってくる相手がいるんですよ。
TTLとか完全無視で接続エラーが発生するまで更新しないつもりなんですかね？

それにしても、何度も書いているかもしれませんが、DNSの仕組みってすごいですよね。

設定見れば誰でも理解できるような単純な内容のテキスト形式のファイルでインターネットの名前解決をすべてこなしているとか、基本設計した人のセンスが素晴らしかったってことですよね。

ほんと、感謝です。