NETWORK ENGINEER BLOG

Tips and Reviews for Engineers

VM のディスク容量を拡張(CentOS LVM)

syslog サーバーの /var 領域を拡張する必要があったのでメモです。

仮想ディスクの拡張

事前に仮想マシンの電源はオフにする必要があります。現状60GBとなっています。
f:id:FriendsNow:20190303183555p:plain

本例では160GBに拡張します。
f:id:FriendsNow:20190303183702p:plain

var 領域の拡張

ディスク容量確認

[root@hostname ~]# df -h
Filesystem            Size  Used Avail Use% マウント位置
/dev/mapper/vg1-lv_root
                       15G  2.0G   12G  15% /
tmpfs                1004M     0 1004M   0% /dev/shm
/dev/sda1             291M   32M  244M  12% /boot
/dev/mapper/vg1-lv_var
                       44G  485M   41G   2% /var  ★現状44G

新規パーティション作成

[root@hostname ~]# fdisk /dev/sda
コマンド (m でヘルプ): n  ★「n」を入力
コマンドアクション
   e   拡張
   p   基本パーティション (1-4) 
p  ★今回は基本領域を作成するので「p」を入力
パーティション番号 (1-4): 3  ★ここでは「3」を入力
最初 シリンダ (7833-20886, 初期値 7833): 
初期値 7833 を使います
Last シリンダ, +シリンダ数 or +size{K,M,G} (7833-20886, 初期値 20886): 
初期値 20886 を使います
コマンド (m でヘルプ): w ★「w」を入力
パーティションテーブルは変更されました!

再起動

[root@hostname ~]# sushudtdown -r now

ボリュームグループ確認

[root@hostname ~]# vgdisplay
  --- Volume group ---
  VG Name               vg1
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  4
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               3
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               59.70 GiB  ★現状60GiB
  PE Size               4.00 MiB
  Total PE              15284
  Alloc PE / Size       15284 / 59.70 GiB
  Free  PE / Size       0 / 0   
  VG UUID               UJpQRG-2HYx-K3fY-TJN3-2L2N-LWYL-htxET4

物理ボリューム作成

[root@hostname ~]# pvcreate /dev/sda3

ボリュームグループを拡張

[root@hostname ~]# vgextend vg1 /dev/sda3

ボリュームグループ確認

[root@hostname ~]# vgdisplay
  --- Volume group ---
  VG Name               vg1
  System ID             
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  5
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               3
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               159.70 GiB  ★160GiBに拡張
  PE Size               4.00 MiB
  Total PE              40882
  Alloc PE / Size       15284 / 59.70 GiB
  Free  PE / Size       25598 / 99.99 GiB
  VG UUID               UJpQRG-2HYx-K3fY-TJN3-2L2N-LWYL-htxET4

var 領域のボリューム状況確認

[root@hostname ~]# lvdisplay
  --- Logical volume ---
  LV Name                /dev/vg1/lv_var
  VG Name                vg1
  LV UUID                I69N3A-MKcB-ZUdd-vnPB-YG0O-UQcc-Rf0WjA
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                44.08 GiB   ★現状44GiB	
  Current LE             11284
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2

拡張したボリューム領域を var に割り当て

[root@hostname ~]# lvextend -l +100%FREE /dev/mapper/vg1-lv_var 

var領域のボリューム状況確認

[root@hostname ~]# lvdisplay
  --- Logical volume ---
  LV Name                /dev/vg1/lv_var
  VG Name                vg1
  LV UUID                I69N3A-MKcB-ZUdd-vnPB-YG0O-UQcc-Rf0WjA
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                144.07 GiB  ★144GiBに拡張
  Current LE             36882
  Segments               2
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2

ファイルシステムサイズの変更

[root@hostname ~]# resize2fs /dev/mapper/vg1-lv_var 

ディスク容量確認

[root@hostname ~]# df -h
Filesystem            Size  Used Avail Use% マウント位置
/dev/mapper/vg1-lv_root
                       15G  2.0G   12G  15% /
tmpfs                1004M     0 1004M   0% /dev/shm
/dev/sda1             291M   32M  244M  12% /boot
/dev/mapper/vg1-lv_var
                      142G  492M  135G   1% /var  ★142GiBへ拡張

以上

Postfix から Gmail へリレーする設定

Gmail の設定

Gmail の設定で安全性の低いアプリを許可します。

Postfix の設定

Postfix と SASL インストール
# yum install -y postfix
# yum -y install cyrus-sasl-plain cyrus-sasl-md5
Postfix の設定
# vi /etc/postfix/main.cf
myhostname = host.example.com
mydomain = example.com
myorigin = $mydomain
inet_interfaces = all
inet_protocols = ipv4
mynetworks = 127.0.0.0/8
relayhost = [smtp.gmail.com]:587
smtp_sasl_auth_enable  = yes
smtp_sasl_password_maps = hash:/etc/postfix/smtp-auth-passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_mechanism_filter = plain
#tls setting
smtp_use_tls = yes
smtp_tls_security_level = may
smtp_tls_loglevel = 1
パスワードファイル作成
# vi /etc/postfix/smtp-auth-passwd
[smtp.gmail.com]:587 xxxxxx@gmail.com:PASSWORD
パスワードファイルからデータベースを作成
# postmap /etc/postfix/smtp-auth-passwd
Postfix 再起動
# /etc/init.d/postfix restart
動作確認

Mailx インストール

# yum -y install mailx

Mail コマンド

# echo "test" | mail -s "test" xxxxx@gmail.com

Gmail へメールが送信できます。

以上

GPO でドライブマップ

ユーザー GPO により、ログオンしたサーバーでドライブマップを構成することが可能です。

GPO の場所と設定

「ユーザーの構成」➡「基本設定」➡「Windows の設定」➡「ドライブマップ」で、以下のように設定します。
f:id:FriendsNow:20181201233204p:plain

GPO を有効化した後、ログオンするとドライブマップが構成されています。
f:id:FriendsNow:20181201233243p:plain

RDP 接続する場合

ドライブマップを構成したサーバーに RDP で接続すると、ドライブマップが表示されませんでした。
f:id:FriendsNow:20181201233300p:plain

原因調査中ですが、ひとまず以下のポリシーを有効化することで、RDP で接続時にドライブマップが表示されることを確認しました。
「コンピューターの構成」➡「管理テンプレート」➡「Windows コンポーネント」➡「リモートデスクトップサービス」➡「リモートデスクトップセッションホスト」➡「プロファイル」➡「リモート デスクトップサービス ユーザーのホーム ディレクトリを設定する」
f:id:FriendsNow:20181201233326p:plain

ポリシーを有効化した後、再起動すると以下のような形で、RDP 経由でもドライブマップが表示されます。
f:id:FriendsNow:20181201233412p:plain

以上

Horizon 7 RDSH URL コンテンツリダイレクション

VMware Horizon 7 の新機能である URL コンテンツリダイレクションを試してみました。
VMware Horizon View 7 簡易構築手順の環境を使用しました。
クライアント端末から VDI に接続し、そこから RDSH で仮想ブラウザを使用する前提です。

View Agent のインストール

仮想ブラウザをホストする RDS サーバーに View Agent をインストールします。
リダイレクトを使用する場合は、コマンドプロンプトで以下を実行してインストールします。

VMware-Horizon-Agent-x86_64-7.6.0-9539447.exe /v URL_FILTERING_ENABLED=1

f:id:FriendsNow:20181201165355p:plain

Horizon Client のインストール

仮想ブラウザを使用する VDI 上にインストールします。
View Agent と同様にリダイレクトを使用する場合は、コマンドプロンプトで以下を実行してインストールします。

VMware-Horizon-Client-4.9.0-9539668.exe /v URL_FILTERING_ENABLED=1 /v URL_FILTERING_ENABLED=1

f:id:FriendsNow:20181201165445p:plain

インストールが完了すると、RDS サーバーと VDI のそれぞれの Internet Explorer に以下のアドオンが追加されます。

VMware Horizon View URL Filtering Plugin

f:id:FriendsNow:20181201165500p:plain

URL リダイレクトの設定

Horizon 7.4.0 View GPO Bundleをドメインコントローラにインポートします。
URL リダイレクトは"urlRedirection.admx"ポリシーで設定します。
f:id:FriendsNow:20181201165559p:plain

各パラメータの概要は以下のとおりです。

  • clientRules
    • クライアントのブラウザを使いたい URL*1
  • brokerHostname
    • Connection Server 名
  • agentRules
    • 仮想ブラウザを使いたい URL*2
  • remoteItem
    • 仮想ブラウザで URL へアクセスする際に起動するリソース名
      • VDI の場合はプール名(表示名)
      • RDSH の場合はアプリケーション名(表示名)

f:id:FriendsNow:20181201165620p:plain

動作確認

ローカルブラウザで"agentRules"に登録した URL へアクセスします。
f:id:FriendsNow:20181201165648p:plain

自動で仮想ブラウザが起動します。
f:id:FriendsNow:20181201165712p:plain

以上

*1:vmware.com を含む場合:.*.vmware.com

*2:vmware.com を含む場合:.*.vmware.com

VMware Horizon View 7 で RDSH 環境を構築

以前掲載したVMware Horizon View 7 簡易構築手順の環境に追加で実装しました。

RDS サーバーインストール

こちらの「RDS サーバーインストールの事前作業」を参考頂ければと思います。

アプリケーションのインストール

仮想化したいアプリケーションを RDS サーバーへインストールします。本例ではインストール済の Internet Explorer を仮想化しますので、省略します。

View Agent のインストール

RDS サーバー上で以下のファイルを実行します。

VMware-Horizon-Agent-x86_64-7.6.0-9539447.exe

Connection Server のアドレスを指定してインストールします。
f:id:FriendsNow:20181201110718p:plain

ファームの作成

View Administrator にて、[ファーム]を選択し[追加]をクリックします。
「手動ファーム」を選択し、RDS ホストの登録及び、セッション動作を指定します。
f:id:FriendsNow:20181201110818p:plain

アプリケーションプールの作成

View Administrator にて、[カタログ]-[アプリケーションプール]を選択し[追加]をクリックします。
仮想化したいアプリケーションを選択します。
f:id:FriendsNow:20181201110843p:plain

資格の割り当て

アプリケーションを使用するユーザーを指定します。
f:id:FriendsNow:20181201110906p:plain

VMware Horizon View Client 接続

VMware Horizon View Client で接続先サーバにログインんすると、アプリケーションのアイコンが追加されます。
f:id:FriendsNow:20181201110917p:plain

アイコンをクリックするとアプリケーションが起動します。
f:id:FriendsNow:20181201110924p:plain

以上

Hrizon 7 Administrator で(みつかりません)エラー

例えば、vCenter サーバーから仮想デスクトップを削除してしまった場合、接続サーバーまたは、View Composer のデーターベース上の不整合が発生し、「デスクトッププール」➡「インベントリ」の仮想デスクトップで、以下のエラーとなる場合があります。

メンテナンスモード(みつかりません)

この場合、KB2015112に記載されている、"接続サーバ上の ADAM データベースから仮想マシンを削除"を実施することで解決する場合があります。

具体的な手順は以下のとおりです。

  • View Administrator で対象プールのプロビジョニングを無効化
  • いずれかの接続サーバーに、ドメイン管理者アカウントでログオン
  • [開始] > [管理ツール] > [ADSI エディタ] をクリック
  • コンソール ウィンドウで、[ADSI エディタ] を右クリックし、[接続先] をクリック
  • [名前] フィールドに、次のように入力
View ADAM データベース
  • [識別名または名前付けコンテキストを選択または入力する] を選択
  • [識別名または名前付けコンテキストを選択または入力する] の下のフィールドに、次のように入力
 dc=vdi,dc=vmware,dc=int
  • [ドメインまたはサーバを選択または入力する] を選択
  • [ドメインまたはサーバを選択または入力する] の下のフィールドに、次のように入力
 localhost:389
  • [OK] をクリック
  • [View ADAM データベース [localhost:389]] をクリックしてデプロイ
  • [DC=vdi,dc=vmware,dc=int] をクリックしてデプロイ
  • [接続] View ADAM データベース [localhost:389] を右クリックし、[新規作成] > [クエリ] をクリック
  • たとえば「VM Search」など、適当なクエリ名を入力
  • [検索のルート] で、[参照] をクリックし、[サーバ] の構成単位を選択
  • [OK] をクリック
  • [クエリ文字列] に次の検索文字列を貼り付け
 (&(objectClass=pae-VM)(pae-displayname=VirtualMachineName))
※VirtualMachineName は GUID を検索する仮想マシン名
  • [OK] をクリックしてクエリを作成
  • 左側のペインでクエリをクリック。 検索に適合する仮想マシンが右ペインに表示
  • プロパティにて、対象の仮想デスクトップであることが確認できたら、pae-VM オブジェクトを削除
  • View Administrator で対象プールのプロビジョニングを有効化

以上

cDOTで NFS マウントエラー

久しぶりに触ったら、NFS マウントでハマってしまったのでメモしておきます。

まず、以下のエラーでマウントに失敗

# mount -t nfs -v 10.1.1.21:/vol1 /mnt/test
mount.nfs: timeout set for Wed Nov 28 08:50:58 2018
mount.nfs: trying text-based options 'vers=4,addr=10.1.1.21,clientaddr=10.1.1.251'
mount.nfs: mount(2): Connection refused
mount.nfs: trying text-based options 'addr=10.1.1.21'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: portmap query retrying: RPC: Program not registered

こちらは、LIF の -data-protocol が CIFS になっていました。
なお、-modify で変更できなかったので、再作成しました。

LIF を削除

cl::> network interface modify -vserver vs -lif lif1 -status-admin down
cl::> network interface delete -vserver vs -lif lif1

LIF 再作成

cl::> network interface create -vserver vs -lif lif-nfs -role data -data-protocol nfs -home-node cl-01 -home-port e0a -address 10.1.1.21 -netmask 255.255.255.0

次に以下のエラー

# mount -t nfs -v 10.1.1.21:/vol1 /mnt/test
mount.nfs: timeout set for Wed Nov 28 08:59:16 2018
mount.nfs: trying text-based options 'vers=4,addr=10.1.1.21,clientaddr=10.1.1.251'
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting 10.1.1.21:/vol1

こちらはマウント対象の"vol1"が所属する vserver のルートボリューム"svm_root" に適切な Export-Policy が適用されていないことが原因でした。

"vol1"には"policy1"が適用されていますが、"svm_root"は"default"となっています。

cl::> volume show -vserver vs -fields policy
vserver volume   policy
------- -------- -------
vs      svm_root default
vs      vol1     policy1
vs      vol22    policy1
3 entries were displayed.

"svm_root"に"policy1"を適用

cl::> volume show -vserver vs -fields policy
vserver volume   policy
------- -------- ------
vs      svm_root policy1
vs      vol1     policy1
vs      vol22    policy1
3 entries were displayed.

なお、"policy1"の内容は以下のとおりです。

cl::> vserver export-policy rule show -policyname policy1
             Policy          Rule    Access   Client                RO
Vserver      Name            Index   Protocol Match                 Rule
------------ --------------- ------  -------- --------------------- ---------
vs           policy1         1       any      0.0.0.0/0             any

無事マウントできました。

# mount -t nfs -v 10.1.1.21:/vol1 /mnt/test
mount.nfs: timeout set for Wed Nov 28 09:59:32 2018
mount.nfs: trying text-based options 'vers=4,addr=10.1.1.21,clientaddr=10.1.1.251'
10.1.1.21:/vol1 on /mnt/test type nfs (rw)

# ll
total 7726916
-rwxrwxrwx. 1 nobody nobody 4386213888 Aug 11  2017 test.txt

以上

GPO でログオフ時間を記録する方法について

ドメイン環境化において、ユーザが端末からログオフした時間を、AD サーバーのイベントビューワーへ出力方法についてご紹介します。

ログオフスクリプトの作成

ログオフスクリプトはこちらを参考にさせて頂きました。
“\\AD01”は、スクリプトを配置する DC 名を指定します。

On Error Resume Next

' EVENTLOG_DC_NAME: イベントログを記録させたいDC名をUNCで指定
Const EVENTLOG_DC_NAME = "\\AD01"

' SCRIPT_PRE_MESSAGE: イベントログに書き込むメッセージの最初の文言
Const SCRIPT_PRE_MESSAGE = "[端末からログオフしました。] "

' WshShellオブジェクトとADSIオブジェクトを生成、取得
Set objShell = WScript.CreateObject("WScript.Shell")
Set objADSystemInfo = WScript.CreateObject("ADSystemInfo")

' ADのユーザーオブジェクトを取得
Set objUser = GetObject("LDAP://" & objADSystemInfo.UserName)

' ADのユーザーオブジェクトのGroupsプロパティから、所属グループ名を取得
strGroupNames = "MemberOf: CN=Domain Users"
For Each objGroup In objUser.Groups
    strGroupNames = strGroupNames & "," & objGroup.Name
Next

' EventCreateコマンドでイベントログを書き込む。
objShell.Run "EVENTCREATE /S " & EVENTLOG_DC_NAME & " /T INFORMATION /L APPLICATION /ID 8 /D " & """" & SCRIPT_PRE_MESSAGE & strGroupNames & """", 7, True

' 事後処理
Set objShell = Nothing
Set objADSystemInfo = Nothing
Set objUser = Nothing

スクリプトの配置

スクリプトは以下のパスに配置します。※任意のパスでは実行されないので注意してください。

\\DC名\sysvol\ドメイン名\scrpits\

本例では、以下のパスに配置しています。

\\ad01\sysvol\example.com\scripts

GPO の設定

GPO を設定します。本例では「DaaS Users」というユーザ OU に、「Audit」と名前のポリシーをリンクしています。
f:id:FriendsNow:20181104150241p:plain

「Audit」ポリシーで「ログオフスクリプト」を指定します。
f:id:FriendsNow:20181104150357p:plain

GPO を更新します。

gpupdate /force

アクセス権の設定

通常、イベントビューワーへの書き込みは Domain_Admins グループに属するアカウントでのみ許可されています。一般ユーザーで書き込みができるようDC 上で、以下のコマンドを実行します。

wevtutil sl application /ca:O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)(A;;0x3;;;S-1-5-33)(A;;0x1;;;S-1-5-32-573)(A;;0x3;;;DU)

イベントビューワーの出力結果

ドメイン環境化の端末からユーザーがログオフすると、AD のイベントビューワーの「WIndows ログ」「Application」でログオフ時間を確認できます。
f:id:FriendsNow:20181104151059p:plain

以上

ONTAP 9.4 の重複排除効果監視について

ONTAP Simulator 9.4 を使用したテスト環境の構築と、重複排除効果を監視する方法をご紹介します。

環境構築手順(簡易版)

disk 追加~Aggr 作成

storage disk assign -all true -node cl-01
storage aggregate create -aggregate aggr1 -raidtype raid_dp -diskcount 20 -nodes cl -maxraidsize 28

※root volume 拡張(オプション)
ONTAP Simulator の初期セットアップ後、以下のエラーが出力される場合があります。

CRITICAL: This node is not healthy because the root volume is low on space
(<10MB). The node can still serve data, but it cannot participate in cluster
operations until this situation is rectified. Free space using the nodeshell or
contact technical support for assistance.

そのため、以下の手順で root volume のサイズを拡張しておきます。

storage aggregate add-disks -aggregate aggr0_cl_01 -diskcount 3
run -node cl-01 vol size vol0 +1g
storage aggregate show -node cl-01 -root true
volume show -node cl-01 -aggregate aggr0_cl_01

※2018.12.09 追記
なお、運用中に上記エラーがでた際は、以下の方法で vol0 のサイズを拡張することが可能です。

> node run local
> vol size vol0 +1g

SVM 作成~LIF(CIFS 用)作成

vserver create -vserver vs -aggregate aggr1
network interface create -vserver vs -lif lif-cifs -role data -data-protocol cifs -home-node cl-01 -home-port e0a -address 10.1.1.21 -netmask 255.255.255.0

ライセンス登録~volume 作成

license add -license-code "License Code"
volume create -vserver vs -volume vol1 -aggregate aggr1 -size 10g -security-style ntfs -space-guarantee none -junction-path /vol1

時刻設定~CIFS 設定

timezone Asia/Tokyo
system date modify -dateandtime 201810201926.48
vserver services dns create -vserver vs -domains example.com -name-servers 10.1.1.120
cifs create -cifs-server cifs -domain example.com -vserver vs
Enter the user name: Administrator
Enter the password:
vserver cifs share create -vserver vs -share-name vol1 -path /vol1

重複排除設定と効率の確認

volume efficiency on -vserver vs -volume vol1

効率化によるスペース削減量の表示(出力結果抜粋)

volume show -vserver vs -volume vol1
<...snip...>
Space Saved by Deduplication: 119.6MB	<---重複排除によって節約された領域
Percentage Saved by Deduplication: 2%	<---重複排除によって節約された割合
<...snip...>

重複排除効率の監視

NetApp PowerShell Toolkit Installerとタスクスケジューラを使用して、重複排除効率化の定期的な監視を行うことができそうです。以下のファイルを実行してインストールします。

NetApp_PowerShell_Toolkit_4.6.0.msi 

PowerShell スクリプトを利用して重複排除効率を確認可能です。
スクリプト例

$netapp = "192.168.1.21"
$user = "admin"
$pass = "password"
$volname = "vol1"

#-------------------------------------------------------------------------
# function Efficiency-Status
#-------------------------------------------------------------------------
function Efficiency-Status()
{
   $outfile = "C:\Efficiency_status.log"
   $logdata = "Efficiency_Status"
   $logdata | out-file $outfile -append
   Get-Date -Format g >> $outfile
   Get-NcVol $volname | select @{Name="Volume"    ; Exp={$_.name}}, 
               @{Name="Total(MB)" ; Exp={[math]::Truncate(($_ | Get-NcVol).TotalSize/1MB)}},
               @{Name="Used(%)"   ; Exp={($_ | Get-NcVol).Used}},
               @{Name="Avail(MB)" ; Exp={[math]::Truncate(($_ | Get-NcVol).Available/1MB)}},
               @{Name="Saved(MB)" ; Exp={[math]::Round(($_ | Get-NcEfficiency $volname).Returns.Dedupe/1MB)}} | Format-Table -autosize >> $outfile
   write-output ""`n >> $outfile
}

#-------------------------------------------------------------------------
# Do-Initialize
#-------------------------------------------------------------------------
$password = ConvertTo-SecureString $pass -asplaintext -force
$cred = New-Object System.Management.Automation.PsCredential $user,$password

Import-Module DataOnTap
Connect-NaController $netapp -cred $cred 

#-------------------------------------------------------------------------
# Main Application Logic
#-------------------------------------------------------------------------
Efficiency-Status

参考書籍

以上

OVF デプロイ時のエラーについて

VCSA6.7 で OVF テンプレートをデプロイした際、以下のエラーが発生して失敗することがあります。

不明な理由で操作が失敗しました。この問題は、ブラウザが証明書を信頼できない場合に発生します。
自己署名証明書またはカスタム証明書を使用している場合は、下記の URL を新しいブラウザで開いて証明書を受け入れてから、操作を再試行してください。
https://"ESXi の IP アドレス"

f:id:FriendsNow:20181013220718p:plain

対処方法

VCSA にアクセスして「信頼されたルート CA 証明書をダウンロード」をクリックします。
f:id:FriendsNow:20181013220727p:plain

ダウンロードした zip を解凍すると、「.crt」と「.crl」のファイルが展開されますので、それぞれ「信頼されたルート証明機関」にインポートします。
f:id:FriendsNow:20181013220736p:plain

ブラウザを再起動すると「保護された通信」に遷移し、正常にデプロイができるようになります。
f:id:FriendsNow:20181013220753p:plain

以上

IPsec の暗号化アルコリズムについて

IPsec の暗号アルゴリズムに TDEA を使用しているのを時折みかけますが、TDEA は、平文のデータを取得される脆弱性(sweet32)が確認されており、NIST(アメリカ国立標準技術研究所)が可能な限り早期に TEDA から AES に切り替えていくことを推奨しています。

NIST urges all users of TDEA to migrate to AES as soon as possible.
NIST is developing a draft deprecation timeline for the 3-key variant of TDEA including a sunset date.
NIST requests comments on the current plan described in this announcement, including suggestions for the deprecation timeline.
出典:COMPUTER SECURITY RESOURCE CENTER

AES は TDEA と比較して、セキュリティ性が高く、負荷も軽いことから、急速に普及しつつある暗号アルゴリズムです。
IETF IPsec ワーキンググループも、いずれは AES を IPsec の必須アルゴリズムとする方向性のようです。

It is the intention of the IETF IPsec Working Group that AES will eventually be adopted as the default IPsec ESP cipher and will obtain the status of MUST be included in compliant IPsec implementations.
出典:The AES-CBC Cipher Algorithm and Its Use with IPsec

以上

VCSA6.7 インストール

アプライアンスのデプロイ

任意の OS*1 に iso イメージをマウントして、以下の実行ファイルを実行します。

E:\vcsa-ui-installer\win32\installer.exe

インストーラーが起動後、「インストール」をクリックします。
f:id:FriendsNow:20181006185425p:plain

「次へ」をクリックします。
f:id:FriendsNow:20181006185451p:plain

「使用許諾契約書の条項に同意します」にチェックし、「次へ」をクリックします。
f:id:FriendsNow:20181006185456p:plain

「Platform Services Controller が組み込まれた vCenter Server」を選択して、「次へ」をクリックします。
f:id:FriendsNow:20181006185506p:plain

デプロイターゲット情報を入力して、「次へ」をクリックします。
f:id:FriendsNow:20181006185511p:plain

「はい」をクリックします。
f:id:FriendsNow:20181006185517p:plain

仮想マシン名、root パスワードを入力して、「次へ」をクリックします。
f:id:FriendsNow:20181006185526p:plain

デプロイサイズを選択して、「次へ」をクリックします。
f:id:FriendsNow:20181006185532p:plain

データストアを選択して、「次へ」をクリックします。
f:id:FriendsNow:20181006185602p:plain

ネットワーク設定をして、「次へ」をクリックします。
f:id:FriendsNow:20181006185620p:plain

「完了」をクリックします。
f:id:FriendsNow:20181006185634p:plain

デプロイ完了後、「続行」をクリックします。
f:id:FriendsNow:20181006185711p:plain

アプライアンスの設定

「次へ」をクリックします。
f:id:FriendsNow:20181006185724p:plain

アプライアンス設定後、「次へ」をクリックします。
f:id:FriendsNow:20181006185738p:plain

SSO 設定後、「次へ」をクリックします。
f:id:FriendsNow:20181006185744p:plain

CEIP 設定後、「次へ」をクリックします。
f:id:FriendsNow:20181006185750p:plain

「完了」をクリックします。
f:id:FriendsNow:20181006185756p:plain

「OK」をクリックします。
f:id:FriendsNow:20181006185805p:plain

セットアップ完了後、「閉じる」をクリックします。
f:id:FriendsNow:20181006185820p:plain

vSphere Client の起動

以下の URL へアクセスします。

https://"仮想マシン名 or IP アドレス":443

vSphere Client(HTML5)をクリックします。
f:id:FriendsNow:20181006185831p:plain

vSphere Client(HTML5)が起動します。
f:id:FriendsNow:20181006185841p:plain

以上

*1:本例では Windows 10 を使用しています。

Linux の Traceroute について

Linux の Traceroute では、ポートを指定して、ネットワーク経路上で該当ポートを使用する通信が許可されているかどうかを確認することができます。

Traceroute とは

IP パケットの TTL*1を活用し、最初に TTL を 1 に設定して ICMP パケットを送信する。
1番目のルータが受け取った時点で TTL は1減算されるため、ルータは TTL の生存時間が過ぎたことを通知する”ICMP Time Exceeded (TYPE=11)"を自身の情報と共に返す。これを受けて、ホストは TTL を 2 にして送信、2台目のルータの情報を入手。これを繰り返すことで、目的のホストまでの経路情報を取得する。
参考:@IT

Traceroute の使い方

TCP 389番を使用して Traceroute をする場合

traceroute -T -p 389 100.64.1.90

UDP 53番を使用して Traceroute をする場合

traceroute -U -p 53 100.64.1.90

Traceroute の実行例

以下の環境で実際に試してみます。
NW 装置で TCP389 をブロックし、UDP53 を許可している場合、Traceroute の実行結果は以下となります。

f:id:FriendsNow:20180622163410p:plain:w570

Traceroute(TCP389)の結果

NW 装置でブロックしているため通信不可

[root@hostname ~]# traceroute -T -p 389 100.64.1.90
gateway (10.1.1.254)  0.910 ms  0.841 ms *
* * *6  * gateway (10.1.1.254)  0.789 ms !X
Traceroute(UDP53)の結果

NW装置で許可しているため通信可

[root@hostname ~]# traceroute -U -p 53 100.64.1.90
traceroute to 100.64.1.90 (100.64.1.90), 30 hops max, 60 byte packets
 1  gateway (10.1.1.254)  0.917 ms  1.570 ms  1.531 ms
 2  100.64.1.90 (100.64.1.90)  2.856 ms * * 

Tracerouteの留意事項

Traceroute(ポート指定)では、IP到達性があれば、応答を得ることができます。
例として、サーバが該当ポートを使用するサービスをリッスンしていなくても、応答を得ることができることから、Traceroute では、ネットワーク経路上や、宛先サーバで、該当ポートを使用した通信がブロックされていないことを確認できるだけで、サービスレベルの確認はできない点に留意が必要です。

f:id:FriendsNow:20180622170603p:plain:w570

Traceroute(TCP389)の結果

サーバで LDAP をリッスンしていないが、 NW 装置とサーバで ALL 許可しているため通信可

[root@hostname ~]# traceroute -T -p 389 100.64.1.90
traceroute to 100.64.1.90 (100.64.1.90), 30 hops max, 60 byte packets
1  gateway (10.1.1.254)  1.328 ms  1.744 ms *
6  * 100.64.1.90 (100.64.1.90)  1.445 ms  3.007 ms

サービスのアクティブ性確認

サービスのアクティブ性を確認するため、実際のサービス通信以外で確認する方法として、Telnet があります。Telnet でサービスポートを指定することで、サービスが該当ポートで、待ち受けているかの確認することが可能です。

f:id:FriendsNow:20180622180506p:plain:w570

Telnet(TCP389)の結果

サーバで LDAP をリッスンしている場合は、以下のとおりとなる。

telnet 100.64.1.90 389
Trying 100.64.1.90...
Connected to 100.64.1.90.
Escape character is '^]'.

サーバで LDAP をリッスンしていない場合は、以下のとおりとなる。

telnet 100.64.1.90 389
Trying 10.1.1.254...
telnet: connect to address 100.64.1.90
: Connection refused
tcpdump によるパケットキャプチャ

サービスをリッスンしている場合

[root@hostname ~]# tcpdump port 389 -i ens34
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens34, link-type EN10MB (Ethernet), capture size 262144 bytes
IP localhost.localdomain.57498 [root@hostname ~]# 100.64.1.90.ldap:
 Flags [S], seq 2076959109, win 29200, options [mss 1460,sackOK,TS val 1279295 ecr 0,nop,wscale 7], length 0
IP 100.64.1.90.ldap [root@hostname ~]# localhost.localdomain.57498:
 Flags [S.], seq 2434335086, ack 2076959110, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 1711531 ecr 1279295], length 0
IP localhost.localdomain.57498 [root@hostname ~]# 100.64.1.90.ldap: 
 Flags [.], ack 1, win 229, options [nop,nop,TS val 1279296 ecr 1711531], length 0

サービスをリッスンしていない場合*2

[root@hostname ~]# tcpdump port 389 -i ens34
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens34, link-type EN10MB (Ethernet), capture size 262144 bytes
IP localhost.localdomain.57502 [root@hostname ~]# 100.64.1.90.ldap:
 Flags [S], seq 3028605199, win 29200, options [mss 1460,sackOK,TS val 1695981 ecr 0,nop,wscale 7], length 0
IP 100.64.1.90.ldap [root@hostname ~]# localhost.localdomain.57502: 
 Flags [R.], seq 0, ack 3028605200, win 0, length 0

RST について

前述のとおり、通常、サーバはリッスンしていないサービスに対するリクエストに応じてRSTを送信します。[RFC793, RFC1122, Ste94]
また、一部のファイアウォール等では不正と判断したパケットに対して、RSTを送信します。*3
RST をサーバが送信しているのか、経路上の NW が送信しているのかを見極める方法として、パケットキャプチャで送信元 IP や TTL を確認する方法が考えられます。

f:id:FriendsNow:20180622181831p:plain
TTL が同じ値の場合はサーバ、TTL に差異がある場合は、NW 装置が RST を送信している可能性が高くなります。

以上

*1:Time To Live

*2:サービスをリッスンしていない場合は、通信先サーバは TCP RST パケットを送信します。

*3:NW 装置が RST を返す場合、クラサバ間の通信整合性をとるため、送信元アドレスをサーバとして RST を送信する場合があります。

CentOS 7 の基本設定

CentOS 7 の設定メモです。

インターフェースの設定

インターフェース名が従来の eth から ens という名前に変わっています。
インターフェースの自動有効化

[root@hostname ~]# nmcli c m ens33 connection.autoconnect yes

インターフェースの設定確認

[root@hostname ~]# nmcli device show ens33

インターフェースの IP アドレス設定

[root@hostname ~]# nmcli c modify ens33 ipv4.addresses 192.168.1.21/24

インターフェースの Default Gateway の設定

[root@hostname ~]# nmcli c modify ens33 ipv4.gateway 192.168.1.2

インターフェースの DNS の設定

[root@hostname ~]# nmcli c modify ens33 ipv4.dns 8.8.8.8

インターフェースの IP アドレスの確認

[root@hostname ~]# ip addr

ネットワークの再起動

[root@hostname ~]# systemctl restart network

インターフェースのステータス確認

[root@hostname ~]# nmcli device status

ネットワークの設定

スタティックルートの追加

[root@hostname ~]# ip route add 100.64.1.0/24 via 10.1.1.254 dev ens34

スタティックルートの削除

[root@hostname ~]# ip route del 100.64.1.0/24

スタティックルートの確認

[root@hostname ~]# ip route list

再起動後も反映させたい場合は、以下の設定ファイルを更新します。

[root@hostname ~]# vi /etc/sysconfig/network-scripts/route-ens34
100.64.1.0/24 via 10.1.1.254

Default Gateway の設定

[root@hostname ~]# route add default gw 192.168.1.2

Default Gateway の削除

[root@hostname ~]# route delete default

参考書籍

以上

Internet Explorer 11 のプロキシ設定について

SBC 方式で運用しているシンクライアント環境において、エンドユーザーが使用する Internet Explorer 11にプロキシを設定したいといった要望があり、調査した結果、GPO とレジストリの編集で対応可能な事がわかったので、紹介します。*1
Internet Explorer 11 のプロキシ設定は、グループポリシー(レジストリベース)で配布する事が可能です。

グループポリシーの設定

  • [ユーザーの構成] ➡ [基本設定] ➡ [Windows の設定] ➡ [レジストリ]
  • 右クリックから[新規作成] ➡ [レジストリ項目]を押下する。

f:id:FriendsNow:20180610203819p:plain

プロキシサーバーの有効化

以下のレジストリを変更します。

キー : HKEY_CURRENT_USER\OFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
名前 : ProxyEnable
種類 : REG_DWORD
データ : 1

f:id:FriendsNow:20180610203918p:plain

プロキシサーバーの指定

以下のレジストリを作成します。

キー : HKEY_CURRENT_USER\OFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
名前 : ProxyServer
種類 : REG_SZ
データ : (例)127.0.0.1:8080

f:id:FriendsNow:20180610203940p:plain

プロキシサーバーの除外設定

以下のレジストリを作成します。

キー : HKEY_CURRENT_USER\OFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
名前 : ProxyOverride
種類 : REG_SZ
データ : (例)10.1.1.*;172.16.*;192.168.1.*;<local>

f:id:FriendsNow:20180610204008p:plain

グループポリシーの適用

Internet Explorer 11 をホストしているサーバで、以下のコマンドを実行します。

gpupdate /force

上記を全て設定した場合、Internet Explorer 11 のプロキシ設定は以下のとおりとなります。
f:id:FriendsNow:20180610204032p:plainf:id:FriendsNow:20180610204044p:plain

以上

*1:サーバーは、Windows Server 2016 を使用する前提です。