読者です 読者をやめる 読者になる 読者になる

designetwork

ネットワークを軸としたIT技術メモ

Kibana 5でDiscoverタブの検索結果をCSVエクスポートする

ログ可視化 ログ可視化-Kibana

f:id:daichi703n:20170327005406p:plain

Kibanaで要望されつつもなかなか実装されない機能の一つに、Discover画面からのエクスポートがある。Githubでもissueとして長期的に要望されている。

github.com

その中で、次の通り機能実装版を提供してくれている方がいる。

If you are adventurous enough, you can implement it yourselves. It is fairly simple. For example this commit for version 5.1. Build instructions here.

Here is the screenshot:

f:id:daichi703n:20170326234449p:plain

今回は機能追加版のKibanaをビルドして動作確認をした。また、より簡単に導入できるようDockerコンテナを作成したので公開する。

前提条件

本記事の前提条件・知識は以下の通り。

  • Elasticsearchをインストールして使用している。
  • Kibanaの設定変更箇所が分かる。
  • Dockerを通常使用できる。

ちなみに、私はDocker歴が非常に浅いため至らない点が多いですがご了承ください。また、本記事ではKibana5.2.3を使用していますので、Elasticsearchのバージョンも合わせる必要があります。

公開手順でビルドする

公開いただいている手順でエクスポート機能追加版のKibanaをインストール・設定する。

github.com

つまづいた点はいくつがあるが、どうにかビルドできた。

  • 説明に記載はないがgit clone https://github.com/tongwang/kibana.gitする
  • nvm install "$(cat .node-version)"したときに存在しないと言われるときは~/.nvm/nvm.sh install "$(cat .node-version)"する

Kibanaを起動する

Kibanaの設定はファイルは/etc/kibana/config/kibana.yml。通常通りserver.port, server.host, server.name, elasticsearch.url, (kibana.indexもコメント外す必要あり?)等を設定する。

kibanaの起動方法は以下の通り。

cd /etc/kibana (when cloned kibana into /etc/)
npm start

このときにProxy?がどうのこうのでアクセス出来ないことがあった。kibana.ymlでserver.host: 0.0.0.0を指定していると0.0.0.0にリダイレクトされてしまった。起動オプションから--devを除外したらアクセス可能になった。

vi /etc/kibana/package.json

-  "start": "sh ./bin/kibana --dev",
+  "start": "sh ./bin/kibana",

各種設定後にnpm startして指定ポートにアクセスするとエクスポート機能付きKibanaにアクセスできる。再掲にはなるが、このようにexport付きの画面が表示される。

f:id:daichi703n:20170327001735p:plain

エクスポートしてみる

さっそくエクスポートしてみたが、CSVファイルをダウンロードできるものの出力されていない…

f:id:daichi703n:20170327001920p:plain

いろいろと試したところ、単純なDiscoverの状態ではだめで、左ペインでindexをAddした状態でないとエクスポートされないようだ。次の画面のようにカラムが表示されていればよい。

f:id:daichi703n:20170327002624p:plain

次の通りエクスポートできた。

f:id:daichi703n:20170327002710p:plain

Dockerコンテナで簡単に導入する

正直、git cloneして、ビルドして、と導入のハードルはやや高い(私自身が経験浅く難しかった)。また、Proxy環境では、Git(Port9418)の通信が発生するため、Proxyサーバの設定次第では通信できず、ビルドを完了できない。

導入を簡単にするために、ビルド済みのDockerコンテナを作成しました。ただし、Dockerhubへの自作コンテナpushも今回が初めてなので、全く最適化できていません…。容量もでかいですがご了承ください。(3GB程度)

https://hub.docker.com/r/daichi703n/kibana-exp-52/

導入手順

導入手順はこちらの通り。オフィシャルと同様、Elasticsearchのパスを起動オプションで指定できるようにしたいが、未実装。設定ファイルを編集ください。

docker pull daichi703n/kibana-exp-52
docker images
// daichi703n/kibana-exp-52 があることを確認する

docker run -d -p 5605:5601 --name some-kibana daichi703n/kibana-exp-52 /sbin/init
docker ps -a
// CONTAINER ID        IMAGE                      COMMAND             CREATED             STATUS              PORTS                    NAMES
// 2098d63548c3        daichi703n/kibana-exp-52   "/sbin/init"        3 minutes ago       Up 3 minutes        0.0.0.0:5605->5601/tcp   some-kibana

docker exec -it some-kibana /bin/bash  // dockerコンテナにログインする。
cd /etc/kibana/
vi ./config/kibana.yml  //環境にあわせて調整
npm start  // 以下のように表示されればOK

> kibana@5.2.3 start /etc/kibana
> sh ./bin/kibana

  log   [15:41:48.351] [info][status][plugin:kibana@5.2.3] Status changed from uninitialized to green - Ready
  log   [15:41:48.424] [info][status][plugin:elasticsearch@5.2.3] Status changed from uninitialized to yellow - Waiting for Elasticsearch
  log   [15:41:48.457] [info][status][plugin:console@5.2.3] Status changed from uninitialized to green - Ready
  log   [15:41:48.494] [warning] You're running Kibana 5.2.3 with some different versions of Elasticsearch. Update Kibana or Elasticsearch to the same version to prevent compatibility issues: v5.2.2 @ 192.168.1.81:9200 (192.168.1.81)
  log   [15:41:49.815] [info][status][plugin:timelion@5.2.3] Status changed from uninitialized to green - Ready
  log   [15:41:49.823] [info][status][plugin:elasticsearch@5.2.3] Status changed from yellow to green - Kibana index ready
  log   [15:41:49.824] [info][listening] Server running at http://0.0.0.0:5601
  log   [15:41:49.825] [info][status][ui settings] Status changed from uninitialized to green - Ready

これでhttp://<サーバIP>:<Kibanaフォワーディングポート>にアクセスすれば使用可能。ポート番号はコンテナ起動時 -p パラメータで変更可能。

まとめ - Kibana 5でDiscoverタブの検索結果をCSVエクスポートする

エクスポート機能が実装されたKibanaを導入して、DiscoverからCSVエクスポートできることを確認した。また、ビルド済みのDockerコンテナを作成したため、簡単に導入できる。

Cisco ASAシリーズはCDP/LLDPを未サポート

ネットワーク設計 ネットワーク設計-FW

f:id:daichi703n:20170317005408p:plain

Cisco ASAはセキュリティデバイスであるため、隣接NW機器の情報を収集するCDP/LLDPをサポートしていない

Ciscoサポートコミュニティの情報

ASAのCDP/LLDPの対応状況に関する質問がいくつかされている。質問はASA5505についてだが、ASAシリーズ全般で同仕様となっている。

supportforums.cisco.com

ASA5505のPoEポートを使う際の注意

こちらの記事に記載した通り、ASA5505のPoEポートに無線APを接続する際、ASAを越えて別のCisco機器(Catalystスイッチなど)とCDPネイバーを張ってしまうと、PoEで正常に給電できない場合がある。

Cisco AIR1131AGでDot11Radioがresetになる原因のひとつ

ネットワーク設計 自宅ネットワーク

f:id:daichi703n:20170317004520p:plain

自宅ラボの無線AP Cisco Aironet AIR1131AGで、停電から復旧後にDot11Radioインタフェースのステータスがresetになるトラブルが発生した。

停電の原因は単純な家の電源容量超過で、すべてのNW機器で突然の電源断となってしまった。configの保存はしてあったため変更は発生していない。切り分けで分かったこと、原因と対策を記載する。

Aironet AIR1131AGの接続構成

以下の通り、Cisco ASA5505のPoEインタフェース経由でPoE給電で接続している。なお、PC, サーバ接続にはCatalyst2960を使用し、各VLANのGWはASAにしている。

AIR1131AG
 |(access vlan 1)
ASA5505
 |   |(各VLAN access)
Cat2960
 |   |
(V1) (trunk)
 PC   ESXi

エラー調査

AP上部の通常は緑のランプが、明らかに異常な赤となっていた。インタフェース状態は以下の通り。

AIR1131#sh ip int b
Interface                  IP-Address      OK? Method Status                Protocol
BVI1                       192.168.1.11    YES NVRAM  up                    up      
Dot11Radio0                unassigned      YES NVRAM  reset                 down    
Dot11Radio1                unassigned      YES NVRAM  reset                 down    
FastEthernet0              unassigned      YES NVRAM  up                    up     

AIR1131#sh int Dot11Radio0
Dot11Radio0 is reset, line protocol is down 
  Hardware is 802.11G Radio, address is 001e.136e.1250 (bia 001e.136e.1250)

機器再起動、インタフェースshut/no shutをしても状態は変わらなかった。起動ログを見ると以下のようになっている。

AIR1131#sh log
<snip>
*Mar  1 00:58:26.214: %LINK-5-CHANGED: Interface Dot11Radio1, changed state to reset
*Mar  1 00:58:26.214: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
*Mar  1 00:58:26.215: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0, changed state to up
*Mar  1 00:58:26.906: %LINEPROTO-5-UPDOWN: Line protocol on Interface BVI1, changed state to up
*Mar  1 00:58:27.214: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio1, changed state to down
*Mar  1 00:58:27.214: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down
*Mar  1 00:58:39.279: �P_PD-2-POWER_LOW: All radios disabled - LOW_POWER_CLASSIC_NO_INJECTOR_CONFIGURED WS-C2960-24-S (0022.bd42.1d01)
*Mar  1 00:58:39.280:  -Verify the required power-injector is installed on this port: WS-C2960-24-S(Fas 0/1).
*Mar  1 00:58:39.280:  -If a power-injector is installed, issue the command:"power inline negotiation injector installed"

%CDP_PD-2-POWER_LOW: All radios disabled - LOW_POWER_CLASSIC_NO_INJECTOR_CONFIGURED WS-C2960-24-S (0022.bd42.1d01)

CDPでCat2960と情報交換し、PoEの状態確認に失敗しているようにみえる。上記構成の通り、PoE給電元はASA5505であり、Cat2960ではない。そのため、エラーになるのは当然だ。なお、CDPネイバーは正常に張れているので、動作そのものは異常ではない。

AIR1131#sh cdp neighbors 

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
CAT2960          Fas 0              154          S I      WS-C2960- Fas 0/1

停電前からCDPネイバーは張っていたが、Cat2960接続前にASAに接続しPoE給電が始まっていたため、起動時の確認がなく継続動作していたものと考えられる。

対策方法

シンプルに、AIR1131でCDPを無効化する。

AIR1131(config)#no cdp run 

(復旧しない場合はDot11 shut/no shut or reload)

*Mar  1 01:11:42.212: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio1, changed state to down
*Mar  1 01:11:42.213: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down
*Mar  1 01:12:42.711: �P_PD-4-POWER_OK: Full power - NON_CISCO-NO_CDP_RECEIVED inline power source
*Mar  1 01:12:42.742: %DOT11-6-FREQ_SCAN: Interface Dot11Radio1, Scanning frequencies for 14 seconds
*Mar  1 01:12:42.771: %DOT11-6-FREQ_SCAN: Interface Dot11Radio0, Scanning frequencies for 24 seconds
*Mar  1 01:12:56.524: %DOT11-6-DFS_SCAN_START: DFS: Scanning frequency 5260 MHz for 60 seconds.
*Mar  1 01:12:56.524: %DOT11-6-FREQ_USED: Interface Dot11Radio1, frequency 5260 selected
*Mar  1 01:12:56.524: %LINK-3-UPDOWN: Interface Dot11Radio1, changed state to up
*Mar  1 01:12:57.524: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio1, changed state to up
*Mar  1 01:13:07.030: %DOT11-6-FREQ_USED: Interface Dot11Radio0, frequency 2467 selected
*Mar  1 01:13:07.030: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
*Mar  1 01:13:08.030: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up
*Mar  1 01:13:30.867: %DOT11-6-ASSOC: Interface Dot11Radio0, Station   0c3e.9f69.656f Associated KEY_MGMT[WPAv2 PSK]
*Mar  1 01:13:57.008: %DOT11-6-DFS_SCAN_COMPLETE: DFS scan complete on frequency 5260 MHz

AIR1131#
AIR1131#sh ip int b
Interface                  IP-Address      OK? Method Status                Protocol
BVI1                       192.168.1.11    YES NVRAM  up                    up      
Dot11Radio0                unassigned      YES NVRAM  up                    up      
Dot11Radio1                unassigned      YES NVRAM  up                    up      
FastEthernet0              unassigned      YES NVRAM  up                    up      

正常にDot11(無線)インタフェースが使用可能な状態になった。

まとめ - Cisco AIR1131AGでDot11Radioがresetになる原因

Cisco Aironet AIR1131AGはPoE起動時に、可能な場合はCDPで対向PoE機器との接続状態を確認する。停電復旧後にその確認でFailとなり、PoE異常でDot11インタフェースが起動できなかった。

AIR1131のCDPを無効化することで、通常通りPoE受電しDot11インタフェースが起動、無線通信が可能となった。

Express + Node.jsでDNS名前解決の状況を確認する

プログラミング プログラミング-Node.js

サーバ間のAPI連携などの際のDNS名前解決確認ツールをExpress + Node.jsで作成した。サーバ上でNode.jsで名前解決をするため、実際のアプリケーションと同じ環境での確認ができる。

確認できること

DNSの名前解決 (Webアプリケーション自身から)

以下の通り、FQDNに対するAレコード、PTRレコードを確認できる。

f:id:daichi703n:20170311201728p:plain

公開プログラム

Herokuにてプログラムを公開している。(フリープランなので立ち上がり遅い場合あり)

DNS Checker - Heroku

できないこと・修正したい点

こちらと同様

designetwork.hatenablog.com

ソースコード

Express + Node.jsのソースコードはこちらで公開している。ご自由にお持ちください。

仕組みとしては、jadeのformでFQDNを入力し、クエリとしてNode.jsで読み込む。与えられたFQDN(クエリ)に対してnpm dnsモジュールでアクセスして名前解決情報を取得する。なお、localhostについてはDNSでの名前解決ができないため、npm pingモジュールで同様情報を取得する。

www.npmjs.com

www.npmjs.com

まとめ - Express + Node.jsでDNS名前解決の状況を確認する

Express + Node.js dns, pingモジュールにより、アプリケーション自身がFQDNの名前解決して結果を表示するプログラムを作成した。Webアプリケーション, API基盤の動作確認等の用途に使用できる。

ASAでDMZを構築するときのセキュリティレベル設定

ネットワーク設計 ネットワーク設計-FW 自宅ネットワーク

f:id:daichi703n:20170311162820j:plain

Cisco ASA5505で自宅ラボにDMZを構築している。単純なinside-outside設定の場合はセキュリティレベルをinside:100, outside:0とし、必要な外からの通信をFWとNATで許可すればよい。

しかし、DMZを含めるとセキュリティレベルだけでは制御しきれなくなる。一般的にDMZ:50としてセキュリティレベルを設定する。これにより、以下のようなアクセス制御になる。

o inside -> outside
o inside -> dmz
x dmz -> inside
o dmz -> outside
x outside -> inside
x outside -> dmz

ACLを適用すると上書きされる

上記のxの通信についても、要件に応じて通信可能とする必要がある。例えばインターネット公開サーバなど。outsideからの通信はACLとNATで実現できる。しかし、問題となるのはdmzからinsideへの通信。

基本的には、セキュリティレベル低->高(dmz->inside)の通信はACLで穴あけしていくことになるが、そのときにdmz->outsideへの通信も考慮が必要となる。セキュリティレベルでの動作を期待すると、以下のように、insideへの必要通信のみを設定しがちだ。

access-list dmz extended permit ip <dmz> <inside>
access-group dmz_in in interface dmz

しかし、このACLを適用してしまうと、dmzからoutside(インターネット)への通信ができなくなってしまう。つまり、ACLでセキュリティレベルの設定が上書きされてしまう。

そのため、以下のようにinsideの特定ホスト宛は許可、他は拒否、その上でany(outside)宛は許可とする必要がある。(ACLの書き方はOSバージョン等による)

access-list dmz extended permit <protocol> <dmz> <inside_host>
access-list dmz extended deny ip <dmz> <inside>
access-list dmz extended permit ip <dmz> any
access-group dmz_in in interface dmz

設計メモ

設計ポイント、エラーの対処などはこちらを参照

まとめ - ASAでDMZを構築するときのセキュリティレベル設定

自宅ラボASA5505でDMZを構築するときは、セキュリティレベルでの制御はしきれず、DMZからの通信はすべてACLで制御する必要がある。

自宅ラボASAでDMZからinsideに通信できない問題に対応する

ネットワーク設計 ネットワーク設計-FW 自宅ネットワーク

自宅ラボのASA5505でDMZを構築していたら、DMZからinsideへの通信ができない事象が発生したので対応メモ。

前提構成

  • Cisco ASA5505(基本ライセンス・BASE License, Ver.9.2(3))
  • Cisco Catalyst2960
  • VMware ESXi

ASA5505はセキュリティライセンスがないとVLAN trunkができないためCatalystaccessで各々接続して束ねている。

DMZからinsideへの通信ができない

適切なACLをインタフェースに適用して疎通確認をしたが、DMZからinsideへの通信ができない。

インタフェースの設定・セキュリティレベル等はこちらの通り。insideのVLAN名はmanagement。

ASA5505# sh run int

interface Vlan1
 nameif management
 security-level 100
 ip address 192.168.1.x 255.255.255.0 
!
interface Vlan50
 no forward interface Vlan1
 nameif dmz
 security-level 50
 ip address 192.168.50.xx 255.255.255.0 
!
interface Vlan99
 description internet
 nameif outside
 security-level 0
 pppoe client vpdn group nifty
 ip address pppoe setroute 

no forward interface Vlan1についてはこちら

NATとACLの設定はこちら。サーバ数が少なく、随時試験中のためACLは広めに空けている。NATのルールは見直しの余地あり。

ASA5505# sh run nat
nat (outside,management) source static any any destination static interface Web-01 service OpenWeb Web
nat (management,outside) source dynamic Internet-PAT interface
nat (dmz,management) source static any any unidirectional  //Does not work because of no forward
nat (dmz,outside) source dynamic Internet-PAT interface

ASA5505# sh run access-list 
access-list Web extended permit tcp any any eq www 
access-list dmz extended permit ip any any 

ASA5505# sh run access-group 
access-group Web in interface outside
access-group dmz in interface dmz

ASA内部のパケットトレーサーでキャプチャすると以下の通り。no-forward-ruleによってパケットがドロップされている。

ASA5505# packet-tracer input dmz icmp 192.168.50.x 0 0 192.168.1.x 

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
in   192.168.1.0     255.255.255.0   management

Phase: 2
Type: ACCESS-LIST
Subtype: no-forward-rule
Result: DROP
Config:
Additional Information:

Result:
input-interface: dmz
input-status: up
input-line-status: up
output-interface: management
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

そんなACLは設定していないが、パケットトレーサーの出力の通り、インタフェース設定のno forwardによって拒否されている。

interface Vlan50
 no forward interface Vlan1

Cisco ASA5505のVLAN構成

Cisco ASA 5505 適応型セキュリティ アプライアンス用スイッチ ポートおよ び VLAN インターフェイスの設定 - Cisco Systems

設定ガイドの中では以下のようなVLAN構成が記載されている。

f:id:daichi703n:20170222004855j:plain

図中のホームVLANno forward interface Vlanビジネスが設定されていることになる。

これを見直して、インターネット接続のoutsideからmanagement(inside)へをno forwardとするのが妥当ではないかと考える。

f:id:daichi703n:20170222010649p:plain

outsideインタフェースにno forwardを設定する

DMZからinsideへの通信はR-Proxyなど各種通信で必要となる。そのため、DMZのno forwardを解除し、その代わりにoutsideにno forwardを設定する。

単純にno forwardの設定を追加しようとするとエラーになる。

ASA5505(config-if)# interface Vlan99
ASA5505(config-if)# no forward interface vlan 1
ERROR: Interface Vlan1 is already used in another no forward command
ASA5505(config-if)# no forward interface vlan 50
ERROR: Interface Vlan50 is already used in another no forward command

試しに使用していないVLAN宛のno forward設定をしたら、正常に設定できた。実際の通信も問題なく、各インタフェース間ですべてルーティングできる。ただし、dmzからinsideへの通信にはACLが必要。ACL適用時にはinternet宛もpermitが必要。

outsideからinside(Vlan 1)への通信を捨てるつもりだったが、移行のしやすさを考慮して継続通信できるに越したことはない。

ASA5505(config-if)# no forward interface Vlan 10
ASA5505(config-if)# exit
ASA5505(config)# interface Vlan50
ASA5505(config-if)# forward interface Vlan 1

最終的なインタフェースの設定は以下の通り。

ASA5505# sh run int vlan 1 
!
interface Vlan1
 nameif management
 security-level 100
 ip address 192.168.1.5 255.255.255.0 
ASA5505# sh run int vlan 50
!
interface Vlan50
 nameif dmz
 security-level 50
 ip address 192.168.50.1 255.255.255.0 
ASA5505# sh run int vlan 99
!
interface Vlan99
 description internet
 no forward interface Vlan10
 nameif outside
 security-level 0
 pppoe client vpdn group nifty
 ip address pppoe setroute 

まとめ - 自宅ASA(BASE License)でDMZからinsideに通信できない

自宅ラボで使用しているASA5505で、DMZからinsideへの通信ができない事象が発生した。問題はASA5505 基本ライセンスでは設定が必要となるno forward interfaceの影響だった。最終的に、no forward interfaceをoutsideに設定し、かつ、指定VLANを未使用のものにすることで、(ACLポリシーで制御した上で)全インタフェース間で通信が可能となった。

Ansibleの動作が遅いときに確認・修正する項目

ネットワーク管理 ネットワーク管理-構成管理

f:id:daichi703n:20170307232809p:plain

Ansibleを使い始めたときに、設定量が多くなってくると動作が遅くなった。原因切り分けして解消したので確認ポイントをメモする。(CentOS7.3 ansible 2.2.1.0)

結果としてDNSタイムアウト待ちが発生していた。なお、FQDN以外のlocalhostでのAレコード(正引き)、IPアドレスでの指定でもPTRレコード(逆引き)の問い合わせをする。

tcpdumpによる切り分け

ansible-playbookを実行すると毎回決まった時間がかかっているように見える。固定的に遅い場合は大抵何かのタイムアウト待ちで、DNSが多い。tcpdumpで動作を確認する。

まず、インタフェース情報を確認する。

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    ...
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    ...

確認したインタフェースでDNS(53)のパケットのみをキャプチャする。-nnオプションを付けることで、Well-Knownポート番号の文字列変換を無効化する。ポート53の場合はdomainと表示されるが逆に分かりづらい。(キャプチャは正常時のシーケンス)

$ sudo tcpdump -i ens192 -nn port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), capture size 65535 bytes
07:30:16.609964 IP 192.168.1.75.40927 > 192.168.1.77.53: 19540+ A? h-cent-mng01.designet.local. (45)
07:30:16.610591 IP 192.168.1.77.53 > 192.168.1.75.40927: 19540* 1/0/0 A 192.168.1.75 (61)
07:30:16.610660 IP 192.168.1.75.40927 > 192.168.1.77.53: 1216+ AAAA? h-cent-mng01.designet.local. (45)
07:30:16.611196 IP 192.168.1.77.53 > 192.168.1.75.40927: 1216* 0/1/0 (106)
07:30:16.822439 IP 192.168.1.75.43660 > 192.168.1.77.53: 18414+ PTR? 75.1.168.192.in-addr.arpa. (43)
07:30:16.822750 IP 192.168.1.77.53 > 192.168.1.75.43660: 18414* 1/0/0 PTR h-cent-mng01.designet.local. (84)

このようにDNSでA, AAAA, PTRの各レコードを問い合わせていることが分かる。

Ansible hostsファイルでの指定による差異

DNSの問題と聞くと、FQDN指定の場合を想定するかと思う。しかし、Ansibleではlocalhost及びIPアドレスでの対象サーバ指定の場合でも各レコードの名前解決を試みる。そのため、「まだDNS登録していないから暫定でIPアドレス指定で…」としている場合に、動作遅延の問題が顕在化する。

Ansible動作遅延の解消

解消方法は単純で、以下のいずれかの対応をすれば良い。

  • A, AAAA, PTRレコードをDNSサーバに登録する
  • DNSサーバでNon-Exist(NXDomain)を返すようにする(タイムアウト待ち防止)

まとめ - Ansibleの動作が遅いときに確認・修正する項目

Ansibleの動作が遅いときは、DNSタイムアウトを疑うといい。tcpdumpで原因調査し、DNSの問題だと分かったら、DNSサーバに必要なレコードを登録するか、DNSサーバでNXDomainを返すようにすることで問題が解消する。

他にもyumのProxyなどの要因はあるが、tcpdumpで異常通信を確認する今回のプロセスは有効に機能する。