Tech Karte::

できることをひとつずつ。

CentOS 7にyumパッケージからApacheを導入~設定・動作確認

今回はネットワークの勉強から少し離れて、CentOSApache(httpサーバ)を導入してみたのでその備忘録に。

参考にしたのはこちら。
blog.apar.jp
CentOS 7.0 でWebサーバー構築・公開(Apache)
httpd(apache)をインストールする(CentOS,ScientificLinux編) | レンタルサーバー・自宅サーバー設定・構築のヒント

Apacheのインストール

$sudo yum -y install httpd

Apache初期設定

/etc/httpd/conf/httpd.confファイルの編集を行いました。

$sudo vi /etc/httpd/conf/httpd.conf

あまりにも長いので、編集した部分だけ抜粋してあります。

ServerAdmin hoge@*****.com ←サーバ管理者用メールアドレスを設定。
ServerName hogehoge.com:80 ←サーバ名を設定。

<Directory "/var/www/html"> 
Options Includes ExecCGI FollowSymLinks ←"/var/www/html"ディレクトリ配下では、CGIが実行できるように設定。
AllowOverride FileInfo AuthConfig Limit 
Require all granted 

<IfModule dir_module>
DirectoryIndex index.html index.cgi index.php ←URLでファイル名を省略した場合の表示しようとする優先順位を設定

#ScriptAlias /cgi-bin "/var/www/cgi-bin ←#を付加してコメントアウト(無効)

#<Directory "/var/www/cgi-bin"> ←すべてコメントアウト
#AllowOverride None
#Options None
#Require all granted
#</Directory>

AddHandler cgi-script .cgi .pl ←cgiスクリプトの拡張子に.plを追加

#AddDefaultCharset UTF-8 ←#を付加してコメントアウト


------------------以下httpd.conf末尾に追記-----------
ServerTokens Prod ←HTTPヘッダ情報の出力設定。ここでは最低限の出力のみ設定。
ServerSignature OFF ←Server管理者情報を表示しない。
HostnameLookups OFF 
KeepAlive ON ←接続の定期的チェックをオン


<Directory "/var/www/html/adm"> ←バーチャルホスト用ディレクトリの設定
Options All
DirectoryIndex index.html index.htm index.cgi index.php ←URLでファイル名を省略した場合の表示しようとする優先順位を設定
AllowOverride All
Order allow,deny
Allow from all
</Directory>

<VirtualHost *:80> ←バーチャルホスト設定
Servername www.*******.jp
DocumentRoot "/var/www/html/adm"
ServerAlias *******.jp

ErrorLog /var/log/httpd/adm-error.log
CustomLog /var/log/httpd/adm-access.log
</VirtualHost>

その他設定

index.htmlファイルの作成

$mkdir /var/www/html/adm ←[adm]ディレクトリを作成。
$echo "<h1>Hello.</h1>" >> /var/www/html/adm/index.html ←[adm]ディレクトリに「Hello.」と表示されるindex.htmlを作成。


SELINUXの無効化

$vi /etc/sysconfig/selinux ←SELinux設定を編集

SELINUX=enforcing 
↓
SELINUX=disabled ←SELinuxをdisabled(無効)に設定。

ポート開放

$firewall-cmd --zone=public --add-service=http --permanent ←ファイアウォールにhttp許可を指定。
[success]で完了
$firewall-cmd --reload ←ファイアウォールを再起動。
[success]で完了


ここまで設定が完了したので、以下コマンドでApacheを起動・有効化しました。

$systemctl start httpd ←Apache起動
$systemctl enable httpd ←次回以降の起動時に自動でApacheを有効化
認証を入力すると起動・有効化される。

Apache起動中に実機(windows10)側からアクセスした結果が以下。
f:id:k-matsuda0901:20160509154323p:plain

先ほど作成したindex.htmlの内容が表示されました。



試しにApacheをストップしてアクセスしてみた結果が以下。

$systemctl stop httpd ←Apacheストップ

f:id:k-matsuda0901:20160509154420p:plain

アクセスできませんでした。止まってます。


とりあえずアクセスできることは分かったので、今日はここまで。

GLBPによるレイヤ3冗長化・ロードバランシング

今回はデフォルトゲートウェイ障害対策として、GLBPによる冗長化と動的ロードバランシングの概要学習・GNS3での検証を行いました。

GLBP概要

GLBPGateway Load Balancing Protocol)
Cisco開発のデフォルトゲートウェイ冗長化を提供するプロトコル

単一のグループに設定した複数の転送ルータを使用して、ロードバランシング(負荷分散)が可能。

GLBPではグループ内で1個の仮想IPアドレス複数の仮想MACアドレスを用意し、ホスト端末からの仮想IPアドレスARPリクエストに対して、複数の仮想MACアドレスで負荷を分散しながら応答する。
これによって、サブネット上のすべてのホスト端末に同じ仮想IPアドレスデフォルトゲートウェイとして設定し、実際には複数のルータによってルーティングすることが可能。

f:id:k-matsuda0901:20160426150849p:plain
f:id:k-matsuda0901:20160426150856p:plain

GLBPが設定されたルータ群をGLBPグループと呼ぶ。
グループは最大4台のルータが設定可能。この設定されたルータをAVFActive Virtual Forwarder)と呼ぶ。

GLBPグループ内では1台のルータをAVGActive Virtual Gateway)として選出する。
AVGは自GLBPグループの管理を行い、
・どのルータがAVFとして転送処理を行うか
・仮想MACアドレスの割り当て
を行う。

また、AVGはホスト端末からのARPリクエスト(通信要求)に対し、複数のAVFに負荷を分散しながら応答する。

ロードバランシング動作

  • ウェイト付きロードバランス(weighted)

各AVFがアドバタイズしているウェイト(重み)によるロードバランス。
ウェイト値が大きいほど負荷が高くなる。

  • ホスト依存ロードバランス(host-depended)

ホストのMACアドレスに基づいて仮想MACアドレスを決定する。
各ホストが使用するデフォルトゲートウェイの仮想MACアドレスが常に同一になるロードバランス。

各ホストからのARPリクエストに対して複数のAVFのMACアドレスが順番に応答されるロードバランス。

GNS3上でのGLBP設定

以下のトポロジでR1-R3にGLBPを設定し、動作を検証しました。

f:id:k-matsuda0901:20160426174240p:plain

上図の四角で囲ってある部分以外のIPアドレス、ルーティングはあらかじめ設定済み。

  • RT1設定
R1(config)#interface fastethernet 1/0
R1(config-if)#ip address 10.1.1.201 255.255.255.0
R1(config-if)#no shutdown

R1(config-if)#glbp 1 ip 10.1.1.200
R1(config-if)#glbp 1 priority 200
R1(config-if)#glbp 1 preempt
  • RT2設定

RT1同様、IPアドレスの設定とGLBPの有効化を行いました。

R2(config)#interface fastethernet 1/0
R2(config-if)#ip address 10.1.1.202 255.255.255.0
R2(config-if)#no shutdown

R2(config-if)#glbp 1 ip 10.1.1.200
R2(config-if)#glbp 1 preempt
  • RT3設定

設定はRT1・2と同様。

R3(config)#interface fastethernet 1/0
R3(config-if)#ip address 10.1.1.203 255.255.255.0
R3(config-if)#no shutdown

R3(config-if)#glbp 1 10.1.1.200
R3(config-if)#glbp 1 preempt

あらかた設定が終わると、R1-R3でリンクが取れたようなメッセージが。
RT1コンソール上で以下のコマンドを入力し確認。

RT1#show glbp brief

f:id:k-matsuda0901:20160426175428p:plain

また、以下のコマンドでGLBP設定を確認。

RT1#show glbp

f:id:k-matsuda0901:20160426175514p:plain

斜め読みすると、グループ仮想IPアドレス[10.1.1.200]でRT1-RT3のFastethernet 1/0(トポロジ図の四角で囲った部分)がGLBP[1]に設定されているようです。
ロードバランスの設定はデフォルトのラウンドロビンで検証します。

動作検証

PC1-3コンソールでping・traceによる疎通・経路確認を行いました

  • PC1

f:id:k-matsuda0901:20160426175936p:plain

  • PC2

f:id:k-matsuda0901:20160426175944p:plain

  • PC3

f:id:k-matsuda0901:20160426175954p:plain


各PCのGatewayは10.1.1.200(GLBPグループ[1]の仮想IPアドレス)で統一してありますが、traceの情報を見てみると最初に通過するルータがラウンドロビンロードバランスによって順番に切り替わっていました。


今回の動作検証はここまで。

動的ルーティング(EIGRP for IPv6編)

前回はIPv4領域でのEIGRPの動作検証を行いましたが、今回はEIGRP for IPv6について学習・検証してみたいと思います。

EIGRP for IPv6概要

IPv4IPv6のEIGRPサポートは異なるモジュールとして追加され、別々に設定・管理する。
基本的な動作メカニズムはIPv4版EIGRPと同じ。

EIGRP for IPv6実装

先のIPv6学習で使用したトポロジに変更を加え、EIGRPを実装しました。
トポロジは以下の通り。

f:id:k-matsuda0901:20160425164242p:plain


PC1・PC2のIPv6アドレスは手動で設定済。

  • RT1設定

以下のコマンドでIPv6アドレスとEIGRP for IPv6を有効化。

R1(config)#ipv6 unicast-routing         ←ルータレベルでIPv6ルーティング有効化
R1(config)#ipv6 router eigrp 1          ←EIGRPをAS[1]で設定

R1(config-rtr)#eigrp router-id 0.0.0.1      ←ルータIDを設定
R1(config-rtr)#interface fastethernet 1/0    ←Fastethernet1/0(PC1側)設定に移行

R1(config-if)#ipv6 address 2001:db8:1:1::254/64 ←IPv6アドレスを設定
R1(config-if)#ipv6 eigrp 1            ←インターフェイスレベルでEIGRPを有効化
R1(config-if)#no shutdown            ←IPv6アドレスを有効化

R1(config)#interface gigabitethernet 0/0     ←Gigabitethernet0/0(RT2側)設定に移行
R1(config-if)#ipv6 address 2001:db8:2:2::1/64  ←IPv6アドレスを設定
R1(config-if)#ipv6 eigrp 1            ←インターフェイスレベルでEIGRPを有効化
R1(config-if)#no shutdown            ←IPv6アドレスを有効化
  • RT2設定

RT1設定と同様に行いました。

R2(config)#ipv6 unicast-routing
R2(config)#ipv6 router eigrp 1

R2(config-rtr)#eigrp router-id 0.0.0.2
R2(config-rtr)#interface gigabitethernet 0/0

R2(config-if)#ipv6 address 2001:db8:2:2::2/64
R2(config-if)#ipv6 eigrp 1
R2(config-if)#no shutdown

R2(config)#interface fastethernet 1/0
R2(config-if)#ipv6 address 2001:db8:3:3::1/64
R1(config-if)#ipv6 eigrp 1
R1(config-if)#no shutdown
  • RT3設定

RT1・2と同様に行いました。

R3(config)#ipv6 unicast-routing
R3(config)#ipv6 router eigrp 1

R3(config-rtr)#eigrp router-id 0.0.0.3
R3(config-rtr)#interface gigabitethernet 0/0

R3(config-if)#ipv6 address 2001:db8:3:3::2/64
R3(config-if)#ipv6 eigrp 1
R3(config-if)#no shutdown

R3(config)#interface fastethernet 1/0
R3(config-if)#ipv6 address 2001:db8:4:4::254/64
R3(config-if)#ipv6 eigrp 1
R3(config-if)#no shutdown

ルーティングテーブル確認

以下のコマンドでルーティングテーブルを確認。

R1#show ipv6 route eigrp

f:id:k-matsuda0901:20160425164511p:plain

疎通確認

PC1からPC2へping・traceで疎通・ルート確認。
結果が以下のコンソール。

f:id:k-matsuda0901:20160425164300p:plain


EIGRP for IPv6の基本的な動作は確認できました。

動的ルーティング(EIGRP基本設定・動作検証編)

先の更新で概要の学習が済んだところで、GNS3上のルータにEIGRPを設定し動作検証を行いました。

今回のトポロジは下図の通り。
f:id:k-matsuda0901:20160422140642p:plain

各ルータのインターフェイス・VPCSのIPアドレスは手動で設定済。

EIGRP基本設定

R1設定

以下のコマンドでEIGRPを有効化し、有効ネットワーク範囲を指定。

RT1(config)#router eigrp 1 ←EIGRPをAS(自律システム)[1]で有効化

RT1(config-router)#network 192.168.1.0 0.0.0.255
RT1(config-router)#network 192.168.12.0 0.0.0.255 ←RT1-RT2間のネットワーク範囲を指定
RT1(config-router)#network 192.168.13.0 0.0.0.255 ←RT1-RT3間のネットワーク範囲を指定
R2・R3設定

RT2・3も同様にEIGRPを有効化し、有効ネットワーク範囲を指定。

RT2(config)#router eigrp 1 ※AS番号を統一しておかないとEIGRPはネイバーを検出しない

RT2(config-router)#network 192.168.2.0 0.0.0.255
RT2(config-router)#network 192.168.12.0 0.0.0.255 ←RT1-RT2間のネットワーク範囲を指定
RT2(config-router)#network 192.168.23.0 0.0.0.255 ←RT2-RT3間のネットワーク範囲を指定


RT3(config)#router eigrp 1 ※同上

RT3(config-router)#network 192.168.3.0 0.0.0.255
RT3(config-router)#network 192.168.13.0 0.0.0.255 ←RT1-RT3間のネットワーク範囲を指定
RT3(config-router)#network 192.168.23.0 0.0.0.255 ←RT2-RT3間のネットワーク範囲を指定

各ルータの設定が完了したところでRT1のコンソールに戻ると以下のメッセージが…
f:id:k-matsuda0901:20160422142050p:plain

各ルータでEIGRPを設定して相互にネットワーク範囲を指定したことで、DUALがネイバーとしてルータを認識しました。

※アジャセンシー(Adjacency)とは

ネイバー(隣接)であり、実際に経路情報を交換する関係のこと。
上のメッセージでは、RT1とRT2(192.168.12.2)、RT1とRT3(192.168.13.2)が新しいアジャセンシー(New Adjacency)として認識されたことになる。



ここでR1のルーティングテーブルを見てみると…
f:id:k-matsuda0901:20160422142817p:plain

分かりづらかったのでEIGRPで設定されたルーティングのみを見てみると…
f:id:k-matsuda0901:20160422142911p:plain

各ネットワークへのルーティング情報が表示されました。

斜め読みすると、
192.168.2.0ネットワーク(PC2方面)にはRT2を経由するルート
192.168.3.0ネットワーク(PC3方面)にはRT3を経由するルート

が自動設定されているようです。

設定検証

PC1からPC2・3への疎通と経路情報をpingとtraceで取ってみました。結果が下図の通り。
f:id:k-matsuda0901:20160422144413p:plain

ルーティングテーブルの情報通りに疎通が取れていることが確認できました。

続きを読む

動的ルーティング(概要編)

これまでは端末間のルーティングを学習し手動で設定していましたが、今回は動的ルーティングを学習し仮想環境上で設定・検証します。


ルーティングの概要

ルーティングとは

パケット(通信データ)を宛先ホスト(端末)に届けるために最適な経路を選択して転送するプロセスのことを指す。
ルータは内部にルーティングテーブル(経路情報)を保持しており、受信したパケット内の宛先IPアドレスとルーティングテーブルから最適な経路選択・転送を行う。

ルーティング方法

ルータがルーティングテーブル(経路情報)を学習する方法には以下の3つがある。

  • 直接接続ルートを使用する

ルータに物理的に接続されているネットワークを指す。
インターフェイスIPアドレスサブネットマスクを設定すると自動的に登録される。

  • スタティックルートを使用する

管理者が手動で経路情報を設定する。

  • ダイナミックルートを使用する

ルーティングプロトコルによって経路情報が自動的にルーティングテーブルに登録される。



ダイナミックルーティングの概要

ルータでルーティングプロトコルを有効にすると、経路情報を他のルータと交換する。
各ルータは交換した情報を基に最適経路を選択し、ルーティングテーブルに学習する。
また、経路に障害が発生しネットワーク構成に変更が生じた場合には変更情報をルータ間でアドバタイズ(通知)し、ルーティングテーブルを更新する。

スタティック(静的)ルーティングに比べ自動化される部分が多く、管理者の負担は削減できる。
大規模ネットワークで特に効果的だが機器への負荷が大きい。

ルーティングプロトコルの概要

プロトコルの種類

  • IGP(Interior Gateway Protocol):AS内部ルーティングに使用する。
  • EGP(Exterior Gateway Protocol):AS外部ルーティングに使用する。(※CCNAの学習範囲を超えるため省略)

※ASとは
AS(Autonomous System):自律システムのこと。
同じ運用ポリシーの下で動作するネットワーク(ルータ)の集合を指す。
大規模ネットワークをASによって小さく分割することで管理が容易になるメリットがある。

メトリックによる最適経路選択

ある特定の宛先ネットワークに対して複数の経路が存在する場合、ルーティングプロトコルは最適経路を決定するため経路ごとにメトリックという数値を生成し、この数値が最小の経路を最適経路とみなす。

IGP分類

IGPは、ルーティングアルゴリズムの違いにより次に分類される。

ルーティングテーブルの情報を交換し、距離(Distance)方向(Vectorに基づいて最適経路を決定する方式。
受信したパケットが宛先に到達するために「どれだけの距離(ルータのホップ数)が必要か」、「どのネクストホップ(ルータ)を経由するか」を基準に最適経路を選択する。

ディスタンスベクターの問題点・解決法

 - 無限カウント
あるネットワークに障害が発生したためにそのネットワークへの誤った経路情報がルータ間で交換され、ルーティングテーブルのアップデート送信が続き、メトリック値が増え続ける状態。
各ディスタンスベクタープロトコルではメトリック値に最大値を定義することが可能。
経路情報のメトリック値が上限に達した場合、他のルータへのアドバタイズ(通知)が停止する仕組みになっている。

 - ルーティングループ
メトリックの上限値を定義することで無限カウントは防止できるが、誤った経路情報がルータ間で交換されるのを防ぐことはできない。
複数のルータが到達不能なネットワークへの誤った経路情報を学習した状態で、メトリックが最大になるまでに到達不能ネットワーク宛のパケットを受信した場合、ルーティングループが発生する。

解決法1:スプリットホライズン
あるインターフェイスから受信した経路情報を同じインターフェイスから送り返さない手法。
「経路情報は、それを受け取った方向に返しても意味がない」という考えに基づく。

解決法2:ルートポイズニング
リンク障害を検知したルータがメトリックを最大値(∞)にして、経路情報がダウンしたことを通知する手法。

解決法3:ポイズンリバース
メトリックが最大値の経路情報を受信した場合、同じインターフェイスから当該経路情報を最大値のまま送り返す手法。

通常はスプリットホライズンのルールが適用されるため同じインターフェイスからアドバタイズ(通知)することはないが、メトリックが最大値(ポイズン)の経路情報を受信した場合はスプリットホライズンよりも優先してメトリックが最大値の情報を返送(リバース)する。

解決法4:ホールドダウンタイマー
ダウンした経路情報が誤って再登録されるのを防止する待ち時間を作る機能。
タイマーがセットされた経路は、その期間中「Possibly down」情報が付加される。ただし、ルータはダウンした経路ネットワーク宛のパケットを受信した場合でも通常のルーティングを行う。

タイマーセット期間中に、元のメトリック値もしくはそれよりメトリック値が大きい(優先度が低い)経路情報を受信した場合はその情報を無視する。
元のメトリックより値が小さい(優先度が高い)経路情報を受信した場合は、「より適切な経路情報」と判断しホールドダウンタイマーを解除し、受信した経路情報をルーティングテーブルに格納する。

解決法5:トリガードアップデート
ディスタンスベクタープロトコルでは、ネットワーク構成に変更がない場合も定期的にアップデートを送信する。

トリガードアップデートは定期アップデートを待たずネットワーク構成の変更を検知すると、即時にアップデートを送信する機能。
この機能を利用することで通常よりもコンバージェンス(ネットワーク内経路情報学習の収束)
高速化されるが、ルータからルータへ段階的に伝播するため、以下の問題点もある。

1:全てのルータに瞬時にトリガードアップデートが届くわけではないため、トリガードアップデート受信前に定期アップデートを送信してしまう可能性がある。
2:トリガードアップデートを含むパケットが転送途中で破棄・破損する可能性があり、適切なルータへの到達が保証されない。


上記の問題を解決するために、トリガードアップデートはホールドダウンタイマーと組み合わせて使用される。


  • リンクステート型:OSPF・IS-IS

各ルータが保持するインターフェイスのリンク(Link)の状態(State)を交換し、そのリンク情報に基づいて最適経路を決定する方式。
各ルータはネットワーク全体のトポロジ(構成)を把握し、SPF(Shortest Path First)というアルゴリズムを使用して宛先ごとの最適経路を計算する。

  • ハイブリッド型:EIGRP

ディスタンスベクター型とリンクステート型、両方の機能を合わせたルーティングアルゴリズム

EIGRP(Enhanced IGRP)は、ディスタンスベクタープロトコルのIGRPにリンクステートの機能をいくつか付加したもの。