技術メモメモ

2019年12月25日水曜日

商用OSのEOSを調べてみた！2019年末版

昨年以下記事でまとめた主要な商用OSのEOSについて、今年も調べてアップデートしてみた。

・商用OSのEOSを調べてみた！2018年末版
https://tech-mmmm.blogspot.com/2018/12/oseos2018.html

2020年にサポート期限を迎える製品については、赤字で強調表示した。

なお、本記事で「EOS」と表現する場合は、製品として完全にすべてのサポートが終了する期限を指すことにする。例えば、通常サポートが終了しても延長サポートが存在するような場合は、EOSとは表現しない。

Windows (PC用)

とうとうWindows 7が2020年1月でEOSとなる。2009年9月にリリースされてから10年経過しているが、極端に古いと感じないのは、今でも使用され続けている環境が多いことが理由だろう。

・製品のライフサイクルの検索
https://support.microsoft.com/ja-jp/lifecycle/search

・ご存知ですか？OS にはサポート期限があります！
https://www.microsoft.com/ja-jp/atlife/article/windows10-portal/eos.aspx

・Windows 7 SP 1
延長サポート：2020/01/14 (SP1必須)

・Windows 8.1
延長サポート：2023/01/10

・Windows 10
Windows 10は、今までのWindows OSとサポートポリシーが異なり、モダンライフサイクルポリシーが適用される。なお、今までの単純なメインストリームサポートと延長サポートの構成を「固定ライフサイクルポリシー」と呼ぶ。

Windows ライフサイクルのファクトシート
https://support.microsoft.com/ja-jp/help/13853/windows-lifecycle-fact-sheet

モダンライフサイクルポリシーについて簡単に説明すると、Windows 10では3月と9月の年2回、機能更新プログラムのリリースが予定されており、この機能更新プログラムのリリースから18ヶ月(EnterpriseとEducationのみ9月更新は30ヶ月)が、その機能更新プログラムを適用したWindows 10のサポート期間となる。

機能更新プログラムはYYMMの形式で表現され、2019年12月現在の最新バージョンは1909となる。

以下に現時点におけるサポート中のバージョンを以下に記載する。

・Windows 10, version 1809 サポート終了：2020/05/12
・Windows 10, version 1903 サポート終了：2020/12/08
・Windows 10, version 1909 サポート終了：2021/05/11

Windows Server

Windows Serverは現時点で、Windows Server 2008 R2、2012、2012 R2、2016、2019の5つのバージョンがサポート中の状況となっている。ただし、Windows Server 2008 R2はWindows 7同様、2020年1月でEOSとなる。

なお、Windows Server 2008 R2は、「プレミアムアシュアランス」と呼ばれる特別サポートにより、6年の追加サポートが可能といった情報もあったが、それは無くなったようだ。代わりに、Azure環境や有償サポートで延長ができるような記載は以下サイトにあった。

・Windows Server 2008 および Windows Server 2008 R2 のサポート終了
https://support.microsoft.com/ja-jp/help/4456235/end-of-support-for-windows-server-2008-and-windows-server-2008-r2

・製品のライフサイクルの検索
https://support.microsoft.com/ja-jp/lifecycle/search

・Windows Server 2008 R2 SP1
延長サポート：2020/01/14 (SP1必須)

・Windows Server 2012 / Windows Server 2012 R2
延長サポート：2023/10/10

・Windows Server 2016
メインストリームサポート：2022/01/11
延長サポート：2027/01/11

・Windows Server 2019
メインストリームサポート：2024/01/09
延長サポート：2029/01/09

vSphere

今年は新しいvSphereのバージョンはリリースされることなく過ぎてしまった。2020年はvSphere 5.5がEOSとなる。

・VMware Lifecycle Product Matrix
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf

・ESXi 5.5 / vCenter Server 5.5
END OF TECHNICAL GUIDANCE：2020/09/19

・ESXi 6.0 / vCenter Server 6.0
END OF GENERAL SUPPORT：2020/03/12
END OF TECHNICAL GUIDANCE：2022/03/12

・ESXi 6.5 / vCenter Server 6.5
END OF GENERAL SUPPORT：2021/11/15
END OF TECHNICAL GUIDANCE：2023/11/15

・ESXi 6.7 / vCenter Server 6.7
END OF GENERAL SUPPORT：2021/11/15
END OF TECHNICAL GUIDANCE：2023/11/15

Red Hat Enterprise Linux

RHEL 8がとうとうリリースされた年であった。2020年はRHEL 5が完全にEOSとなる。RHEL 6も延長サポートフェーズに移る。

・Red Hat Enterprise Linux Life Cycle
https://access.redhat.com/support/policy/updates/errata

・Red Hat Enterprise Linux 5
End of Extended Life-cycle Support：2020/11/30

・Red Hat Enterprise Linux 6
End of Maintenance Support：2020/11/30
End of Extended Life-cycle Support：2024/06/30

・Red Hat Enterprise Linux 7
End of Maintenance Support：2024/06/30
End of Extended Life-cycle Support：未発表

・Red Hat Enterprise Linux 8
End of Maintenance Support：2029/5月
End of Extended Life-cycle Support：未発表

AIX

AIXはTL (Technology Level)毎にサポート期限が異なる。本記事では各メジャーバージョンの最新TLのEOSを記載する。なお、昨年よりAIX 7.1 TL5のサポート期限が1年延長したようだ。

・AIX support lifecycle information
https://www-01.ibm.com/support/docview.wss?uid=isg3T1012517

・AIX 7.1 TL5
End of Service Pack Support ：2023/04/30 (予想)

・AIX 7.2 TL4
End of Service Pack Support ：2022/11/30 (予想)

HP-UX

HP-UXはあまり頻繁なバージョンアップはなく、2007年4月に発表されたHP-UX 11i v3が未だに最新という状況となっている。HP-UX 11i v2のサポート期限が1年延長したようだ。

・長期間利用のための開発方針とサポートポリシー
https://h50146.www5.hpe.com/products/software/oe/hpux/topics/support/

・HP-UX 11i v2
延長サポート終了：2021/12月

・HP-UX 11i v3
標準サポート終了：未発表

参考

・End Of Support (EOS) の調べ方
https://tech-mmmm.blogspot.jp/2015/04/end-of-support-eos.html

2019年12月18日水曜日

BitLocker暗号化手順

Windows OSにて標準で利用できるドライブ暗号化ツールとして「BitLocker」がある。名前は知っていたのだが、インストールして使ったことがなかったので使ってみた。

環境

今回は、仮想環境のWindows Server 2016を使って、TPM(Trusted Platform Module)を利用できない環境でのBitLocker暗号化手順を確認した。

本当はTPMを使った暗号化を試したかったのだが、TPMはハードウェアとして実装されている機能であり、壊してもよいPCもOSもなかったので、今回は仮想環境で試すことにした。
※ちなみに、vCenter Serverがあれば、仮想環境でも仮想TPMが利用できるようだ。

手順

「サーバーマネージャー」→「役割と機能の追加」→「機能の選択」にて、「BitLocker ドライブ暗号化」を選択する。

同時に、必要な機能管理ツールも選択されるので、併せてインストールする。

インストール後、再起動が必要なので再起動する。
再起動後、Cドライブを右クリックすると「BitLockerを有効にする」が選択できるようになる。

ただし、TPMが使えない場合は「このデバイスではトラステッドプラットフォームモジュールを使用できません」というエラーが表示され有効化できない。

上記エラーを回避するため、gpedit.mscを実行し「ローカルグループポリシーエディター」を開き、以下を選択する。
※【注】この手順はTPMが利用できる環境では実施しなくてよい。

「コンピューターの構成」
　→「管理用テンプレート」
　　→「Windowsコンポーネント」
　　　→「BitLocker ドライブ暗号化」
　　　　→「オペレーティングシステムのドライブ」
　　　　　→「スタートアップ時に追加の認証を要求する」

「スタートアップ時に追加の認証を要求する」の項目を選択し、未構成から有効にする。「互換性のあるTPMが装備されていないBitLockerを許可する」に必ずチェックを入れること。それ以外はデフォルトで問題ない。
※【注】この手順はTPMが利用できる環境では実施しなくてよい。
再度、Cドライブを右クリック→「BitLockerを有効にする」を選択すると、暗号化処理を進めることができる。初めにロック解除方法をパスワードにするか、USBキーにするかを選択できる。今回はパスワードで設定する。
「回復キーのバックアップ方法を指定してください」では、以下のいずれかを選択する。今回は「ファイルに保存する」を選択した。

USBフラッシュドライブに保存する
ファイルに保存する
回復キーを印刷する

なお、回復キーをファイルに保存する場合は、暗号化対象のドライブへの保存はエラーとなり実施できない(以下の通り「この場所は使用できません」のエラーとなる)。別ドライブやNASなどのネットワークドライブに保存すること。

「使用する暗号化モードを選ぶ」では、デフォルトの「新しい暗号化モード」とする。Windows 10以降で利用可能なモードとなるが、今時Windows 10以前のOSを使うこともそうそうないため、特別な理由がない限り「新しい暗号化モード」で問題ないだろう。
「このドライブを暗号化する準備ができましたか？」では、「BitLockeシステムチェックを実行する」にチェック入れたままとする。

これをチェックすると暗号化前に再起動を実施し、起動時のパスワードで問題なくログインできるか確認することができる。
再起動後、バックグラウンドで暗号化処理が開始される。

最初はすごく処理に時間がかかるが、途中で突然早くなったりするので、あまり進捗は気にせず待つほうが良い。ちなみに、10GB程度のファイル暗号化で、5分以内に完了した。
暗号化処理が終わると、「ディスクの管理」からも「BitLockerで暗号化済み」と表示されるようになる。

別OSにBitLocker暗号化済みディスクをマウントした場合

暗号化ディスクが別のOSで見た場合、どのように見えるか確認してみた。先ほど暗号化処理を行った仮想マシンをシャットダウンし、Windows Server 2019 (BitLocker未インストール)の別OSにディスクをマウントしてみた。すると、以下の通り鍵付きマークで表示され、ダブルクリックしても反応はなく内容の確認はできなかった。

マウント先のOSにもBitLockerをインストールすると、ダブルクリックして開こうとするとパスワードを求められるようになるので、設定したパスワードを入力することで内容を確認することができる。

2019年11月13日水曜日

グループポリシーを使ってドメインに所属するコンピュータにGoogle Chromeをインストールする2つの方法

以前はブラウザといえば、Internet Explorerが主流となっていたが、近年ではGoogle ChromeやFirefoxがメジャーとなってきており、新しいPCを導入した際にまずやることとして、ブラウザをダウンロードしてインストールする作業が発生することも多い。このインストール作業も1台であれば苦にならないが、何十台とPCが増えた場合は一苦労となる。

ドメインに所属するコンピュータであれば、グループポリシーで自動インストールさせることが可能となる。今回、Google Chromeを自動でインストール (配布)する方法を検証してみた。1つはmsi形式のインストーラを利用する場合の方法、もう1つはexe形式のインストーラを利用する場合の方法となる。

Google Chromeのオフラインインストーラをダウンロードする

Google Chromeは通常ではインターネット接続を前提としたオンラインインストーラが提供されているが、以下方法でオフラインインストーラ (スタンドアロン版)のダウンロードが可能となる。

msi版

Google Chrome Enterpriseのダウンロードサイトに行く本記事執筆時点では以下URLとなる。
https://cloud.google.com/chrome-enterprise/browser/download/?hl=ja
上記URLにてファイルをダウンロードすると、GoogleChromeEnterpriseBundle64.zipといったzipファイルがダウンロードできる。
zipファイルを解凍すると、「Installers」というフォルダの中にGoogleChromeStandaloneEnterprise64.msiがある。本ファイルを利用することでGoogle Chromeのオフラインインストールが可能となる。
※ファイル名に「Enterprise」と書いてあるが、通常のGoogle Chromeと差異はないようだ。

exe版

Google Chromeのダウンロードサイトに行く。本記事執筆時点では以下URLとなる。
https://www.google.com/intl/ja_jp/chrome/
?standalone=1をURLの末尾に付ける。
https://www.google.com/intl/ja_jp/chrome/?standalone=1
通常通りGoogle Chromeをダウンロードすると、ChromeStandaloneSetup64.exeというように「Standalone」がファイル名に付与されたオフラインインストーラがダウンロードされる。本ファイルを利用することでGoogle Chromeのオフラインインストールが可能となる。

それでは、上記ファイルを利用して、グループポリシーを使ってGoogle Chromeのインストールを実施してみよう。

方法①：msi形式のインストーラの場合

msi形式のインストールはグループポリシーで制御するための設定項目が用意されており、アンインストールすることもできることから、可能な限り本方法で対応することをお勧めする。

インストール対象のmsiファイルを共有フォルダに配置する。今回は以下のように共有設定を行いファイルを配置した。Authenticated Usersに権限がないと権限不足でインストールに失敗するようなので追加をしている。
- 共有：Everyone/フルコントロール
- セキュリティ：Authenticated Users/フルコントロールを追加
- パス：\\t1081w219\share
インストール対象のコンピュータアカウントをOUに所属させ、そのOUに適用するGPOを作成する。今回は「msi_test」という名前でOU及びGPOを作成した。
GPOを編集し、「コンピューターの構成」→「ポリシー」→「ソフトウェアの設定」→「ソフトウェアインストール」を選択する。
右クリック→「新規作成」→「パッケージ」を選択する。
ファイル選択のダイアログボックスが表示されるので、共有フォルダに配置したmsiファイルを選択する。
展開方法は「割り当て」を選択する。これでGPOの設定は完了となる。
GPO適用対象のコンピュータを再起動すると、GPOが適用され、ソフトウェアのインストールが自動で実行される。なお、インストール中は「Group Policy Client の処理が完了するのをお待ちください」と表示され、ログインが待機されるようだ。

方法②：exe形式のインストーラの場合

グループポリシーでソフトウェアのインストール制御を行う場合は、インストール・アンインストールの制御が可能なmsi形式のファイルを使った方法①で行うことが望ましい。しかし、msi形式のインストーラが提供されない場合もあるので、その場合は、スタートアップスクリプトとしてexeファイルを指定して実行させることが可能である。

ただし、この方法ではコンピュータを再起動するたびにインストーラが起動してしまうことや、アンインストールの制御は手動対応となる点に注意する必要がある。

インストール対象のexeファイルを共有フォルダに配置する。今回は以下のように共有設定を行いファイルを配置した。Authenticated Usersに権限がないと権限不足でインストールに失敗するようなので追加をしている。
- 共有：Everyone/フルコントロール
- セキュリティ：Authenticated Users/フルコントロールを追加
- パス：\\t1081w219\share
インストール対象のコンピュータアカウントをOUに所属させ、そのOUに適用するGPOを作成する。今回は「msi_test」という名前でOU及びGPOを作成した。
GPOを編集し、「コンピューターの構成」→「Windowsの設定」→「スクリプト」を選択する。
「スタートアップ」をダブルクリックし、「スクリプト」タブで「追加」ボタンを選択する。
「スクリプト名」の「参照」ボタンを選択し、共有フォルダに配置したexeファイルを選択する。これでGPOの設定は完了となる。
GPO適用対象のコンピュータを再起動すると、GPOが適用され、ソフトウェアのインストールが自動で実行される。

2019年11月5日火曜日

Windows ファイアウォールで特定のアプリケーションのみインターネット通信を許可する

WSUSの更新ファイルの取得や、ウイルス対策ソフトの定義ファイル更新などで、Windowsサーバをインターネットと通信させる要件がある場合、単純にインターネット通信をすべて許可してしまうと、ブラウザ等でもインターネット閲覧ができてしまうため、セキュリティ的に問題となる場合がある。

インターネット通信を行うソフトウェアの実行ファイルを特定できる場合は、Windowsファイアウォール (Windows Defenderファイアウォール)にて通信制御を行うことができる。

ただし、Windowsファイアウォールは若干癖のある設定が必要となるので、今回はその設定方法を記載する。

今回の通信要件

以下通信をできるようWindowsファイアウォールを構成する。

対象はWSUSサーバ
ドメインに所属
WSUSのみインターネットから更新ファイルの取得を許可 (WsusService.exeはインターネット通信を許可)
その他の通信はインターネット接続をブロック

それでは、上記を満たすようWindowsファイアウォールを構成してみよう。

Windowsファイアウォールのデフォルトの許可・拒否の動作

Windowsファイアウォールは「受信の規則」と「送信の規則」で分かれており、それぞれのデフォルトの動作は以下の通りとなる。

受信の規則はデフォルト「ブロック」 (変更可)
送信の規則はデフォルト「許可」 (変更可)
規則の中に「許可」と「ブロック」がある場合は、「ブロック」が優先される (変更不可)

拒否が優先して処理される仕様があり、一部許可ルールを書いてからその他をすべて拒否するといった使い方はできないので注意が必要。今回はWSUSのみインターネット通信を許可する必要があるため、送信の規則のデフォルトの動作を「ブロック」に変更する。

デフォルト「ブロック」にするとドメインコントローラとの通信もできなくなる

しかし、送信の規則に対して、デフォルト「ブロック」に変更すると、もともと通信が必要なものまでブロックされてしまうため、サーバ動作に支障をきたしてしまう。ドメイン環境の場合はドメインコントローラとの通信もブロックされてしまう。
以下、送信の規則をデフォルト「ブロック」にした際のドメインコントローラとの通信確認 (ログイン認証及びNTP) の通信を確認した結果となる。どちらもエラーになっていることがわかる。

PS C:\> nltest.exe /SC_QUERY:intrat.local
フラグ: 0
信頼された DC 名
信頼された DC 接続状態 Status = 1311 0x51f ERROR_NO_LOGON_SERVERS
コマンドは正常に完了しました

PS C:\> w32tm /resync
再同期コマンドをローカル コンピューターに送信しています
時刻データが利用できなかったため、コンピューターは同期をとり直しませんでした。

PS C:\> w32tm /query /status
閏インジケーター: 3 (同期未実行)
階層: 0 (未指定)
精度: -23 (ティックごとに 119.209ns)
ルート遅延: 0.0004561s
ルート分散: 14.3052780s
参照 ID: 0x00000000 (未指定)
最終正常同期時刻: 2019/11/02 20:17:15
ソース: t1061w216.intrat.local
ポーリング間隔: 6 (64s)

上記も考慮し、Windowsファイアウォールの規則の追加を行う。

Windowsファイアウォールの規則の追加

今回の通信要件を満たすためには、以下2つの規則を追加すればよい。

ルール1：WSUSのインターネット通信を許可

操作：接続を許可する
名前：WSUSダウンロード
プログラム：%ProgramFiles%\Update Services\Services\WsusService.exe
スコープ：リモートIPアドレスにて「事前定義されたコンピューターセット」を選択し、「インターネット」を指定 (下図参照)

ルール2：ドメインコントローラとの通信を許可

操作：接続を許可する
名前：Active Directory
スコープ：リモートIPアドレスに「ドメインコントローラのIPアドレス」を指定

以下の通り2つの規則が追加

インターネット通信の確認

まず、ブラウザでインターネット通信を試みると以下の通りエラーとなって接続できないことがわかる (プロキシ環境となるため、プロキシ通信がエラーとなる)。

一方、WSUSは以下の通りインターネット通信が成功することがわかる (プロキシ環境となるが、問題なく成功した)。

ドメインコントローラとの通信確認

先ほどエラーとなったドメインコントローラの通信も確認しておこう。
ドメインコントローラの認証はSuccessになっていることがわかる。

PS C:\> nltest.exe /SC_QUERY:intrat.local
フラグ: 30 HAS_IP  HAS_TIMESERV
信頼された DC 名 \\t1061w216.intrat.local
信頼された DC 接続状態 Status = 0 0x0 NERR_Success
コマンドは正常に完了しました

NTPによる時刻同期の状況も問題なし。

PS C:\> w32tm /resync
再同期コマンドをローカル コンピューターに送信しています
コマンドは正しく完了しました。

PS C:\> w32tm /query /status
閏インジケーター: 0 (警告なし)
階層: 2 (二次参照 - (S)NTP で同期)
精度: -23 (ティックごとに 119.209ns)
ルート遅延: 0.0010275s
ルート分散: 18.2840513s
参照 ID: 0xC0A80B3D (ソース IP:  192.168.11.61)
最終正常同期時刻: 2019/11/02 20:20:14
ソース: t1061w216.intrat.local
ポーリング間隔: 6 (64s)

以上でWindowsファイアウォールを使って、特定のアプリケーションのみインターネット接続を許可することができた。

2019年9月4日水曜日

RHEL 7やCentOS7でPolicy Based Routing (PBR)を設定する

RHELのサーバにてNICを複数持つ場合、両方のNICから適切に通信できるよう設定しないと、通信の行きと戻りが異なる「非対称ルーティング」となる場合がある。非対称ルーティングの場合、途中にファイアウォール等があると正常に通信を許可することができず、想定した通信ができない。

このような状況を解消するため、RHELにてPolicy Based Routing (PBR)を設定し検証してみた。以下に検証内容と設定手順を記載する。

環境

OS : RHEL 7
NIC1 (ens192) : 192.168.11.191/24
NIC2 (ens224) : 192.168.33.191/24

通信要件

以下通信要件を実現するルーティングテーブルを作成する。

NIC1で受けた通信はNIC1から返す
NIC2で受けた通信はNIC2から返す
対象サーバから送信する通信はNIC1側から行う

通信概要図を以下に記載する。図示されているすべての矢印で問題なく通信できるようにすることが目的となる。

Policy Based Routing設定手順

デフォルトゲートウェイの設定
デフォルトゲートウェイは「サーバ自身から通信を行うNIC」に対して設定する。今回はNIC1 (ens192)で設定しておく。

# ip route show
default via 192.168.11.31 dev ens192 proto static metric 100    ←★NIC1 (ens192)にデフォルトゲートウェイを設定
192.168.11.0/24 dev ens192 proto kernel scope link src 192.168.11.191 metric 100
192.168.33.0/24 dev ens224 proto kernel scope link src 192.168.33.191 metric 101

NIC2用のルーティングテーブルを追加
NIC1用のIPアドレスから送信する場合のルーティングテーブルを作成する。

# ip rule add from 192.168.33.191 table 100 prio 100
# ip rule show
0:      from all lookup local
100:    from 192.168.33.191 lookup 100    ←★追加されたテーブル
32766:  from all lookup main
32767:  from all lookup default

NIC2用のルーティングテーブルにルーティングを設定
NIC1用のテーブルにデフォルトゲートウェイと同セグのルーティングテーブルを追加する。

# ip route add 192.168.33.0/24 dev ens224 proto kernel scope link metric 100 table 100
# ip route add default via 192.168.33.31 table 100
# ip route show table 100
default via 192.168.33.31 dev ens224
192.168.33.0/24 dev ens224 proto kernel scope link metric 100

NIC1用のルーティングテーブルを追加
NIC2用のIPアドレスから送信する場合のルーティングテーブルを作成する。

# ip rule add from 192.168.11.191 table 101 prio 101
# ip rule show
0:      from all lookup local
100:    from 192.168.33.191 lookup 100
101:    from 192.168.11.191 lookup 101    ←★追加されたテーブル
32766:  from all lookup main
32767:  from all lookup default

NIC1用のルーティングテーブルにルーティングを設定
NIC2用のテーブルにデフォルトゲートウェイと同セグのルーティングテーブルを追加する。

# ip route add 192.168.11.0/24 dev ens192 proto kernel scope link metric 100 table 101
# ip route add default via 192.168.11.31 table 101
# ip route show table 101
default via 192.168.11.31 dev ens192
192.168.11.0/24 dev ens192 proto kernel scope link metric 100

これで完了となる。

一見すると、NIC1とNIC2の両方にデフォルトゲートウェイが設定されているため、通常のルーティングテーブル(ip route showで表示されるテーブル)は不要となるように見えるが、サーバ自身から通信を行う場合は、通常のルーティングテーブルを使用するようなので、設定は必要となる。試しに通常のデフォルトゲートウェイを設定せずにpingを実行してみると、ルーティングがないためネットワークに到達できない旨のエラーが表示された。

[root@localhost ~]# ping 192.168.55.1
connect: ネットワークに届きません

動作確認

NIC1側のクライアントからping

192.168.11.0/24のセグメントにいるクライアントからpingを実施して確認してみる。

# ping -c 1 192.168.11.191
PING 192.168.11.191 (192.168.11.191) 56(84) bytes of data.
64 bytes from 192.168.11.191: icmp_seq=1 ttl=64 time=0.114 ms    ←★OK！

--- 192.168.11.191 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.114/0.114/0.114/0.000 ms

# ping -c 1 192.168.33.191
PING 192.168.33.191 (192.168.33.191) 56(84) bytes of data.
64 bytes from 192.168.33.191: icmp_seq=1 ttl=63 time=0.365 ms    ←★OK！

--- 192.168.33.191 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.365/0.365/0.365/0.000 ms

NIC2側のクライアントからping

192.168.33.0/24のセグメントにいるクライアントからpingを実施して確認してみる。

# ping -c 1 192.168.11.191
PING 192.168.11.191 (192.168.11.191) 56(84) bytes of data.
64 bytes from 192.168.11.191: icmp_seq=1 ttl=63 time=0.219 ms    ←★OK！

--- 192.168.11.191 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.219/0.219/0.219/0.000 ms

# ping -c 1 192.168.33.191
PING 192.168.33.191 (192.168.33.191) 56(84) bytes of data.
64 bytes from 192.168.33.191: icmp_seq=1 ttl=64 time=0.110 ms    ←★OK！

--- 192.168.33.191 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.110/0.110/0.110/0.000 ms

再起動してもルーティングテーブルが消えないようにする

NetworkManager-dispatcher-routing-rulesをインストール
NetworkManager-dispatcher-routing-rulesは、以前はNetworkManager-config-routing-rulesと呼ばれていたパッケージとなるが、以下にある通り、パッケージ名が変更されているだけで同じものになるようだ。
- Bug 1334876 - rename package NetworkManager-config-routing-rules to NetworkManager-dispatcher-routing-rules
NetworkManager-dispatcher-routing-rulesは、RHELのインストールISOイメージに含まれていないので、RHELのサイトからRPMファイルをダウンロードしてインストールする。インストール後、NetworkManager-dispatcher.serviceが自動起動するよう設定する。

# rpm -ivh NetworkManager-dispatcher-routing-rules-1.18.0-5.el7.noarch.rpm
警告: NetworkManager-dispatcher-routing-rules-1.18.0-5.el7.noarch.rpm: ヘッダー V3 RSA/SHA256 Signature、鍵 ID fd431d51: NOKEY
準備しています...              ################################# [100%]
更新中 / インストール中...
   1:NetworkManager-dispatcher-routing################################# [100%]
# systemctl enable NetworkManager-dispatcher.service
# systemctl start NetworkManager-dispatcher.service

NIC1用のルーティング設定を追加
以下のようにrule-<デバイス名>とroute-<デバイス名>のファイルを作成する。先ほど手動で設定する際に使ったコマンドから、ip rule addやip route addを省略して書けばよい。

# cat /etc/sysconfig/network-scripts/rule-ens192
from 192.168.11.191 table 101 prio 101
# cat /etc/sysconfig/network-scripts/rule-ens192
default via 192.168.11.31 table 101
192.168.11.0/24 dev ens192 proto kernel scope link metric 100 table 101

NIC2用のルーティング設定を追加
同様にNIC2用のファイルを作成する。

# cat /etc/sysconfig/network-scripts/rule-ens224
from 192.168.33.191 table 100 prio 100

# cat /etc/sysconfig/network-scripts/route-ens224
default via 192.168.33.31 table 100
192.168.33.0/24 dev ens224 proto kernel scope link metric 100 table 100

OS再起動
OS再起動してルーティングテーブルを確認すると、以下の通り問題なく設定されていることがわかる。

# ip rule show
0:      from all lookup local
100:    from 192.168.33.191 lookup 100
101:    from 192.168.11.191 lookup 101
32766:  from all lookup main
32767:  from all lookup default

# ip route show table 100
default via 192.168.33.31 dev ens224
192.168.33.0/24 dev ens224 proto kernel scope link metric 100

# ip route show table 101
default via 192.168.11.31 dev ens192
192.168.11.0/24 dev ens192 proto kernel scope link metric 100

(参考) 削除コマンド

参考までに、削除コマンドは以下の通りとなる。

# ip route del default table 100
# ip route del 192.168.33.0/24 table 100
# ip rule del table 100

# ip route del default table 101
# ip route del 192.168.11.0/24 table 101
# ip rule del table 101

参考

登録: 投稿 (Atom)