これまで FreeBSD を使用したネットワークサービスに関して書いてきましたが、今回は少し FreeBSD から離れて Cisco デバイスに関して書いてみたいと思います。コロナ以降、自宅やそれ以外のロケーションからリモートと称する VPN 接続を介して社内リソースを使う形態が非常に多くなってきております。このことからオフィスで仕事を行うのはオフィス管理を行う立場の方や、配送を担当される方々、気分転換にたまには自宅から離れて仕事をしたい方々、そして嫁さんの刺さるような視線に耐えられない方々くらいでオフィスを稼働させていることが多くなってきています。それでも社内のネットワークは必要なわけで、有線のスイッチと WiFi を提供しています。有線スイッチは管理目的以外は2つの vlan を使っており、内部のネットワークの vlan とゲストのネットワークの vlan にデバイスを振り分けています。振り分けに使用するのは Active Directory と openldap をバックグラウンドに持つ radius で、使用できる vlan をダイナミックに割り当てています。AD 自身も LDAP なのですが、変なデータを入れて機嫌を損ねると非常に困るので、別途 LDAP 専用に openldap を使います。AD はドメイン PC の認証を担当し、openldap は MAB などのドメイン PC 以外の認証を担当させて、それらをまとめて freeradius 経由で認証および認可をスイッチに対して行います。有線ネットワークのゲストセグメントには特に認証を設けているわけではなく、オフィスにお越しいたき、社内のだれかとともにオフィスのゲートをカードキーで開けて社内 LAN に接続できると言うことで認証をパスしているとみなします、WiFi はこれでは足りないわけで、無料プロバイダとならないためにゲストネットワークへの接続にも認証を設けています。当然のことながら、ゲストネットワークからのアクセスはインターネットのみとなっています。
TACACS
今回ご紹介するのはこれらの認証認可ではなく、スイッチ自体へのアクセスをコントロールする方法の一つとして TACACS をご紹介します。RADIUS でもパスワード認証を行うことができますが、最大の違いが2点あります。TACACS の通信は TCP を使用して全てが暗号化されているが、RADIUS は UDP を使用して、暗号化されているのはパスワードだけである点と、RADIUS は認証のみが行えるのに対して、TACACS は認証に加えて認可を行うことができます。Cisco 機器を筆頭にして、多くのネットワークベンダーが TACACS をサポートしています。微妙な ( 時には大きな ) 違いはあるのですが、基本的な部分は同じと考えることができます。ただ、これまでの経験から、Cisco 以外のベンダーのインプリメンテーションはイマイチと言わざる負えないのが実情かと思います。TACACS 自身が Cisco 独自のサービスだったので、仕方のない部分があるのかもしれません。
以前の記事で Cisco Catalyst スイッチがあるとお話ししましたが、これまでの使い方はハブと同等レベルの使用しかしていませんでした。今回は TACACS を使用する準備として Cisco Catalyst Switchで最低限のセキュリティの確保と、AAA によるアクセス管理を使えるようにしてみたいと思います。スイッチ関係の記事は IPv6 の RA に関してしか書いてこなかったので、TACACS を使えるようになるまでの道のりは少々長くなります。そこで、3部構成としたいと思います。スイッチの初期設定、スイッチの AAA 設定、そして、TACACS による管理の順で書いてゆきたいと思います。
serial connection
まずは、初期設定からご紹介したいと思います。因みにスイッチの設定は一旦消してしまって、ホスト名しか定義していません。ほぼ全てデフォルト状態です。まず、コンソールからログインし、管理者になります。一昔前の Cisco デバイスは RS-232C のインターフェースに有名なブルーケーブルでの接続が多かったのですが、最近では、USB インターフェースでの接続が多くなってきています。Catalyst 2960G は十分古いので、PC に USB-SERIAL 変換のデバイス経由でブルーケーブルでコンソール接続します。転送速度の Cisco 側のデフォルトは、9600bps, ８bit, none-parity, 1 stop bit となっているはずです。画面に何も表示されなかったり、訳のわからない文字が表示されていたらこちらを確認してみてください。この例では、PC の Tera Term でシリアルデバイスを直接開くことでコンソール接続としています。VMware にシリアルデバイスを追加して、FreeBSD から扱うこともできますので、最後にご紹介します。接続が完了すると、このような感じになります。
デフォルトの動作を行って、そのログが表示されています。とりあえず、enter を押してみます。すると、権限なしの状態でログインできました。enable コマンドを入力して、管理者権限を得ます。これもパスワードなしです。
これがデフォルトです。どこかの宣伝ではありませんが、”あまりにも無防備やなぁ。。。” 状態です 🙂 何はともあれ作業しやすいように、メッセージがコンソールに出力されないようにします。長いコマンドの入力中にログが表示されると、何が何だか分からなくなります。
vlan configuration
設定をリセットしたので、vlan もデフォルトの vlan 1 しかありません。
まずは未使用のインターフェースを shutdown しておきます。
デフォルトの vlan 1 はシステムにより何かと使用されるので、セキュリティ上別の vlan を作成してそれをメインのネットワークとします。
新しく作成した vlan 99 をメインとするので、vlan99 インターフェースに IP アドレスを振ります。vlan 1 の IP アドレスのデフォルトは DHCP での取得となりますので、重複しないように shutdown します。
default-gateway
インターネットへの接続にはゲートウェイのアドレスも必要になります。
portfast
使用中のインターフェースは全て vlan 99 に割り当てます。そして、PC しかつながっていないので、スパニングツリー portfast を指定します。
rapid-pvst
続いてスパニングツリーのモードをデフォルトの pvst から rapid-pvst に変更します。これらの違いはトポロジーに変化があった時の収束時間が異なります。文字通り、rapid-pvst は１秒以内に収束します。そして、このスイッチが必ず root ブリッジになるようにプライオリティを上げておきます。
IPv4 IPv6 dual stack
続いて IPv6 アドレスもセットしたいと思います。しかし、vlan99 では IPv4 関連のコマンドしか受け付けないようです。
そこで、スイッチのプロファイルを IPv4/IPv6 Dual Stack に変更します。そして、メッセージ通り再起動します。
再起動してログインしようとしたときに RSA Keys をデフォルト値で作り始めました。
ssh key
以前の記事でも書きましたが、ビット長は長いほど強力になります。一方デフォルトで作られた鍵は 1024 ビットで少々短いと思います。ですので、一旦削除して最長の鍵を作り直します。
4096 ビットまで受け付けてくれます。鍵を手動で作成するにはドメイン名が入力されている必要があります。これはスイッチでの DNS の使用いかんにかかわらずドメイン名だけが必要になります。勿論必要に応じて DNS を使えるようにしても構いません。
enabling IPv6
IPv4/IPv6 Dual Stack のプロファイルを選択したので、IPv6 アドレスが使用できるはずなので、ルータから配られる IPv6 アドレスとデフォルトゲートウェイを使用するように設定します。勿論固定の IPv6 レンジをお持ちであれば、固定 IPv6 アドレスとゲートウェイアドレスをセットしても構いません。
DNS を使用するようにしていないので、PC で IPv6 アドレスを取得してコピーペーストして接続性をテストします。
logging
最初の方でログをコンソールに表示しないようにしたので、ログはメモリ上だけに存在して、再起動したら消えてなくなります。ログには有用な情報が含まれていますので、syslog で dhcp さんに飛ばすように設定しておきます。
IP アドレスと振り分けに必要な facility を指定します。
これでログは dhcp さんに飛んでいるはずですが、dhcp さんはデフォルトのままで受け取ることができません。これを受け取ることができるようにします。
このままではデフォルトの /var/log/messages に他のメッセージと混在してしまうので、専用のログファイルに出力されるようにします。そして、シグナルを送って設定を再読み込みさせます。
さらに、このままだとこのログファイルは大きくなる一方なので、ローテーションとアーカイブを行えるようにしておきます。３０日分のログを圧縮して保存しておきます。
お試しでログを飛ばします。後は FreeBSD 上でいかようにでもログの調理を行うことができます。
ntp
何がいつ起こったかを知るために重要な時間も、日本のバブルが崩壊した時期の時間になっています。少々高級な機材にはバッテリバックアップされた時計が入っているのですが、安い機材では外部から時間をとってくる必要があります。
ということで、正確な時間を刻むように NTP サーバから時間をとってくるようにします。設定後しばらくすると時間の同期が完了して、現在に戻ってきます。
私の会社のスイッチの時間は全て UTC ( GMT ) にセットしていますが、ここでは日本だけですので、他の FreeBSD と同じようにタイムゾーンを JST にセットします。
serial access from virtual machines
基本的な初期設定は以上です。PC からのコンソールアクセスがお好みでない場合は、こちらのように FreeBSD からアクセスできます。ただ、必要なハードウェアは PC 直接と同じです。
Virtual Machine にデバイスを追加して再起動すると、このようなファイルが作られます。
/etc/remote ファイルにはそれらのファイルを使用した接続方法が記述されています。
デバイスファイルのオーナー情報を見てみると、私にはアクセス権限がありません。
root で使えばいいのでしょうが、pokemon ユーザで使えるようにしてみます。NIS マスタの dhcp さんで /etc/group ファイルを編集して、pokemon を dialer ユーザに追加し、/var/yp で make して NIS サーバへプッシュします。プッシュが完了したら login しなおします。dialer グループに入っていることを確認します。
確認出来たら tip コマンドでデバイスに接続できるようになります。
ドメインと先入観
私が使用しているドメイン名はホスティングしてもらっているプロバイダさん経由で取得したものなのですが、これはホスティングしてもらっているからこそ利用できた手法でした。例えば、自前のサーバーを家庭内に立てる、あるいは、企業のネットワークでドメインだけが必要になる場合など、最近は事あるたびにドメインを取得するような傾向にあり、わかりやすいドメイン名は既に誰かに使用されているケースが目立ちます。そうなんです、早い者勝ちなんです 🙂 日本だと、.jp が TLD なので、日本のサイトであるというのが非常にわかりやすく、アクセスする側も日本のサイトのようだということで、安心感から思わずクリックしてしまったりと、アクセスしやすくなっています。最近は、.tokyo や .osaka、.kyoto などもっとローカルな TLD が表れてきたり、もっと極端な例では .google などという企業名が TLD として使われたりするようになってきています。さて、このドメイン名ですが、結構誤解されている部分があると思いますので、ちょっと付録的な話をしたいと思います。
もっとも有名な TLD は何かというと、.com ドメインで、誰でもいくつでも取得することができます。そうです、誰でもいくつでもなのです。これだけ有名になってくると、もうお気に入りの名前などを新規に取得することはもう不可能に近く、ありそうなドメイン名は高額で取引されていたりします。つまり、そのドメインは既に誰かに取得されていて、そのドメインのウェブサイトを開くと、いくらで売ります云々と、ドメイン購入に関してなどとリンクがあるのではないでしょうか？実はこのような状況があることも一因で、国以外の TLD が目的に応じて創設されてきたわけです。例えば、.kyoto の TLD が使用されていると、何か京都に関しての記事が見れるのじゃないかという心理的な先入観が働きます。ですので、京都に関する記事を書く方には大きなアドバンテージがあります。.kyoto ドメインの場合は審査が比較的厳しいようで、本来のドメイン名のあり方を追求しておられるようで、クリーンなイメージが保たれるよう努力されているようですが、そのような TLD ばかりとも限りません。
もう一つの先入観として、例えば .jp ドメインが使用されているとそのサイトは日本に物理的にあるような気がします。これも大きな間違いで、.jp を TLD として持つサイトの所在地が実は中国であったりするわけです。
我々ネットワーク管理者はよくユーザから ”このサイト信用できるん？” と相談を受けることがあります。その時にはドメインの登録情報などを調べてみて、”うーん、大丈夫っぽいよ。” と教えてあげたりします。ウェブでもこのような情報を提供してくれるサイトがありますが、FreeBSD にもベース OS に含まれるコマンドで調べたりすることができます。.jp ドメインの管理がどのように行われているかを知りたいときに、whois .jp などとコマンドを叩くと、公開されている情報が表示されます。こんな感じです。情報はまだまだ続くのですが、head コマンドで頭の部分だけを表示しています。
この whois コマンドは、この情報を得ることが目的なのではなく、ネットワーク接続に問題が起きたときに誰にコンタクトすればいいのかを得ることが本来の目的なのです。例えば、user@none-existent-domain.jp 宛にメールを送りました。ユーザは知り合いで存在するのはわかっています。でも、そんなユーザはいませんとメッセージが返ってきます。このような場合に whois none-existent-domain.jp などとして管理者情報を調べて、問題の修正をお願いするというのが本来の使い方です。今回は Cisco スイッチの話題のページなので、cisco.jp に関して調べてみました。出力の最後の方を見ると、US San Jose の Cisco.com となっています。信頼できそうですよね 🙂
cisco.jp が信頼できそうということからウェブページを開いてみようと思うのですが、コンピュータはこのドメイン名から IP アドレスに変換しないと接続することができません。cisco.jp に割り当てられている IP アドレスを見てみると、このようなアドレスが割り当てられています。
この IP アドレスもドメイン名同様、whois で調べることができます。このアドレスを調べてみると、このような情報を得ることができます。
IP アドレスレンジ 72.0.0.0/8 は US に割り当てられたアドレスで、うち、72.163.0.0/16 は Cisco.com に直接割り当てられたアドレスであるとわかります。ですので非常に高い確率で US にあると思われます。ただし AS番号 109 で BGP ピアリングがあるようなので、さらに細分化したアドレスレンジが、US 外にある可能性も否定できません。が、アドレスレンジの所有者が cisco.com なので、これも信頼できそうです :) では実際はというと、traceroute で見てみましょう。
私が自宅で使用しているプロバイダ経由で、US Dallas で ISP から Cisco.com につながっているように見えます。
ドメイン名はサイトのアイデンティティを表す顔のような重要な情報です。いろいろなことをドメイン名を基にして調べたりします。ですので、わかりやすいドメイン名の需要は多く、登録事業者 ( レジストラ ) もたくさんあります。ドメイン登録という目的は同じなのですが、何かをすることで安くなったり、ドメイン名を購入することでレンタルサーバが無料になったり、レジストラ毎の特徴があります。ですので、特徴を調べてみて、用途に適したレジストラを選んでドメイン登録するのがお得だと思います。このドメイン名、早い者勝ちなのです。何か新しい企画があるような場合は、早めのドメイン名取得がお勧めかと思います。 早い者勝ちですよ 🙂
以下広告
コメント