IPCOMのログを見て通信が成功しているのか失敗しているのか、それともログからは成功しているが実はデータが少ししか送れていないなど確認する為にセッションログの見方をざっとまとめる。
この記事は、
- ファイアウォールを通過した時の表示を知りたい
- 通信がファイアウォールで拒否されているのか確認したい
- 通信が失敗する原因をファイアウォールのログから調べたい
こんな疑問を解決します。
見方よりとりあえず問題がありそうかどうか調べたい方はこちらの記事を参考にしてください。
許可とその理由、拒否のログ出力パターン
ファイアウォールを通過したことを表す文字は３つあります。
- IP packet passed
- UDP session initiated
- TCP connection initiated
この文字が含まれていれば通過できています。
ファイアウォールで拒否はされていません。
通過できているのに通信がうまくいかない場合は、ログ後方にあるreasonを確認します。
- reason=reset-by-peer ・・非同期の終了
- reason=fin ・・同期の終了
- reason=cut-off ・・IPCOMが原因の終了
- reason=idle-timeout ・・時間切れの終了
この理由を確認して対処しましょう。
また、ファイアウォールで拒否されたことを表す文字も３つです。
- IP packet denied
- UDP session denied
- TCP connection denied
この文字があるログはファイアウォールで拒否されています。
ファイアウォールを通過したログ
ICMP
ICMPの行きはicmp-typeが8になる
ICMPの戻りはicmp-typeが0になる。
行きのログはあるが戻りのログが出てこない場合は戻りルーティングが誤っている事が考えられる。
UDP
UDP session initiatedはUDP開始を表す。
UDP session terminatedはUDP終了を表す。
TCP
TCP connection initiatedはTCP開始を表す。
TCP connection terminatedはTCP終了を表す。
UDPのセッションやTCPのコネクションがはれてもアプリレベルで失敗する場合はログの中を見ていく。
通信が失敗する原因
終了の理由reasonを見る
通過できているのに通信がうまくいかない場合は、ログ後方にあるreasonを確認します。
- reason=reset-by-peer ・・非同期の終了
- reason=fin ・・同期の終了
- reason=cut-off ・・IPCOMが原因の終了
- reason=idle-timeout ・・時間切れの終了
reset-by-peerは、送信元と送信先の装置間で同期された終了ではなく、どちらか片方が一方的にリセットを出して終了させた理由です。
例えばテラタームを使いTelnet接続している画面を×で閉じるとセッションだけが残ってしまい、結果的に接続された側からリセットを出す事になる。
なのでアプリケーションとしてリセットが考えられる場合は問題ないと言える。
finは、送信元と送信先の装置間で同期された終了になる。
アプリケーション上も成功しているはずなので特に問題ないが、
それでもうまく通信できないという状態の場合、アプリケーションの何が成功なのか、失敗なのか再確認しましょう。
cut-offは、ファイアウォールが終了させたことになるので、ログがでた直前にファイアウォールで何かしら異常が発生していないか調べましょう。
idle-timeoutは、送信元と送信先の装置間で一定時間どちらからも通信が行われなかなった場合にファイアウォールのタイマーで終了させた理由です。
例えばテラタームを使いTelnet接続したまま放置するとこの理由で終了される。
この場合FWは通過したがその先のルーティングでdstへ到達できなかったり別のFWで拒否されていたり、dst自体のiptable/aclやそもそもサービスが起動していないなど様々が原因が考えられる。
送受信のデータ量から想定する
データ量はsentとrcvdを見ると分かる。
- sent ・・送信元が送信先に送信したデータのbyte量
- rcvd ・・送信先が送信元に送信したデータのbyte量
ここのデータ量が想定より少ない場合は、途中で問題が起きて終了した可能性がある。
通信時間から想定する
durationは開始から終了までの時間を秒で表している。
この時間が短すぎると途中で問題があって終了している可能性が考えられる。
他にキリのいい時間の場合は無通信のタイマーによる切断も考えられる。
デフォルトタイマー
- TCPのFINやRSTが送信されてから１０秒後にコネクション終了
- UDPは無通信が90秒でセッション終了
- TCPはコネクション確立後に無通信が１時間でコネクション終了
なので１０秒、90秒、６０分などの数字が続いていると通信がなくタイマーで機械的に切断されたと推測できる。
無通信の監視タイマー変更コマンドは３つある。
- monitor tcp-disconnecting-timer
- monitor tcp-idle-timer
- monitor udp-idle-timer
これらで設定していない場合はデフォルトタイマーになる。
ファイアウォールで拒否されたログ
ICMP
UDP
TCP
deniedがあれば拒否されている事がわかる。
設定しているルールが原因で拒否されている場合は、後方にこんなログが出る。
rule=9999数字はコンフィグにあるrule access 9999の数字を示しているので、ルールの内容を確認しましょう。
ネットワークはどうやって覚える？
ネットワークといっても基本用語が分からないと都度ネットで調べたりして時間がかかってしまいます。基礎から学ぶと実際のネットワークを見た時に、その構成の理由を理解できるようになります。
無料でやるならネット上の学習サイトを参考にするといいです。
こちらはネットワークの基礎から説明している無料のWEBサイトになります。
>>基礎から学べるWEBサイトを見てみる
実際に使われるコマンドなど実戦形式で覚えたい方はCCNAの学習をおススメします。
私もこのWEBサイトで勉強して資格を取りました。
>>CCNA学習用WEBサイトを見てみる
過去にネットでの学習でつまずいた方には専門書をオススメします。
本なら基礎から学べる事はもちろん、読者視点で分かりやすい解説になっています。
一人で集中してコツコツ進めたい方は書籍を試してください。
本ではわからない所が多すぎたり、誰かに質問したい場合はオンラインスクールを見てみましょう。
カウンセリングから目的に応じた学習プランと教材を提供してくれるので、ネットワークを覚える敷居がとても低くなります。
誰かに相談できるのは心強いです。
>>ネットワークの基本資格CCNAのオンラインスクールを見てみる
まとめ
ファイアウォールのログから許可と拒否の見方がわかるようになりました。
また許可された場合でも、通信がうまくいかない場合は理由を見て対処することができます。
ですが、ファイアウォールのログはセッションまでしか見れないので実際のパケットのやり取りは分からない。
セッションログ以上の事はパケットをキャプチャしてシーケンスを見るしかない。
一つ一つログを見るのは大変だ。と言う方はこちらの記事を参考にしてください。