投稿者「hat」のアーカイブ

別リージョン間VPCのVPN接続設定

朝晩はだいぶ過ごしやすくまだ快適ですが、昼間は暑く少々つらいなと感じているhatです。
今回は別リージョンのVPC間のVPN接続設定について書きたいと思います。

はじめに

同じリージョン内のVPCであればVPC PeeringにてVPN接続が可能となりますが、別リージョン間では利用することができません。今回の環境利用する手法としては、AWS VPCの機能にあるVPN接続を利用します。またVPN接続用のソフトウェアルータとしてはVyattaがありますが、今回はWindowsServer2008 R2を準備し設定を進めていきます。環境構成については次の項目で記載します。

環境構成

[東京リージョン]

  • デフォルトのVPC(172.31.0.0/16)とサブネット(172.31.0.0/20)を利用
  • カスタマーゲートウェイには、WindowsServer2008 R2のEC2インスタンスを作成
  • 接続確認用インスタンスに、WindowsのEC2インスタンスを作成

[シドニーリージョン]

  • VPC(10.0.0.0/16)を作成し、プライベートサブネット(10.0.150.0/24)を作成
  • VPCにはInternetGatewayは作成しない。
  • 接続確認用インスタンスに、WindowsのEC2インスタンスを作成
      [概要構成図]

VPN接続検証環境構成図_改

①カスタマーゲートウェイ(cgw)
VPN接続ルーターとして利用。シドニーリージョンの仮想プライベートゲートウェイからの接続先となります。
②仮想プライベートゲートウェイ(vgw)
AWS VPCの機能として存在しており、シドニーリージョン側にて設定します。

作業概要

東京リージョンとシドニーリージョンを交互に作業していく形となります。
以降に詳細手順を記載していきますが、作業リージョンにはご注意ください。
また詳細手順のキャプチャ画面ですが英語版インスタンスを利用しているため、キャプチャは英語表示となっています。

1. カスタマーゲートウェイとなるWindowsサーバ設定(東京リージョン)
1-1.EC2インスタンスのインターフェース設定
1-2.Windowsアダプタの設定の更新
1-3.Windows Server にルーティングとリモートアクセスサービスのインストール
1-4.ルーティングおよびリモートアクセスサービスの設定と有効化

2. VPN接続設定(シドニーリージョン)
2-1.カスタマーゲートウェイの作成
2-2.仮想プライベートゲートウェイの作成
2-3.VPN接続ルーティング設定
2-4.VPN接続の作成
2-5.VPN接続設定ファイルのダウンロード

3. VPN接続設定(東京リージョン)
3-1.カスタマーゲートウェイにて接続設定の反映
3-2.Windowsファイアウォールの設定
3-3.停止しているゲートウェイの検出のため設定

4.接続確認用のWindowsのEC2インスタンスの作成
作成するタイミングは最後としていますが、最初に作成しても問題ありません。
このインスタンスの作成の手順については割愛いたします。

それでは、実際に作業内容を順に記載していきます。

1.カスタマーゲートウェイとなるWindowsサーバ設定(作業リージョン:東京)

1-1.EC2インスタンスのインターフェース設定

・WindowsServer2008 R2インスタンスを作成し起動します。
・起動したらインスタンスにEIPを割り当てます。
・インスタンスを立ち上げたら、インスタンスを右クリックし、「ネットワーキング」→「送信元 / 送信先の変更チェック」を選択
・無効化するをクリックします。
挿絵001_改

1-2.Windowsアダプタの設定の更新

・リモートデスクトップにてインスタンスに接続
・[コントロールパネル] を開き、[デバイスマネージャー] を起動
・[ネットワークアダプター] ノードを展開
・[Citrix network adapter] を右クリックし、[Properties] をクリック
挿絵002_改

・[Advanced] タブで、[IPv4 Checksum Offload]、[TCP Checksum Offload (IPv4)]、および [UDP Checksum Offload (IPv4)] プロパティを無効にし、[OK] をクリック
挿絵003

1-3.Windows Server にルーティングとリモートアクセスサービスのインストール

・[Server Manager] を開き、[役割] を選択して、[役割の追加] をクリック
挿絵004_改

・[サーバーの役割の選択] ページで、[ネットワークポリシーとアクセスサービス] をチェックして、[次へ] をクリック
挿絵005_改

・[役割サービスの選択] ページで [ルーティングとリモート アクセス サービス] をチェック
挿絵006_改

・[インストールオプションの確認] ページで、[インストール] をクリック

1-4.ルーティングおよびリモートアクセスサービスの設定と有効化

・サーバーマネージャーで [役割] を展開して、次に[ネットワーク ポリシーとアクセス サービス]を展開
・[ルーティングとリモート アクセス サーバー]を右クリックして、[ルーティングとリモート アクセスの構成と有効化] を選択
挿絵007

・[ルーティングとリモート アクセス サーバーのセットアップウィザード] の [ルーティングとリモート アクセス サーバーのセットアップ ウィザードの開始] ページで、[次へ] をクリック
・[構成] ページで、[カスタム構成] をチェックし、[次へ] をクリック
挿絵008_改

・[LAN ルーティング] をチェックし、[次へ] をクリック
挿絵009

・[ルーティングとリモート アクセス サーバーのセットアップ ウィザードの完了] ページで、[完了] をクリック

・[ルーティングとリモート アクセス] のダイアログボックスが表示されるので、[サービスの開始] をクリック
挿絵010

2.VPN接続設定 (作業リージョン:シドニー)

2-1.カスタマーゲートウェイの作成

・AWSコンソールよりVPCを開き、左側ペインのカスタマーゲートウェイを選択
挿絵011_改

・カスタマーゲートウェイをの作成をクリック
ネームタグ:任意
ルーティング:動的
IPアドレス:東京リージョンのWindowsServerのEIP
挿絵012_改

2-2.仮想プライベートゲートウェイの作成

・AWSコンソールのVPCを開き、左側ペインの仮想プライベートゲートウェイを選択し、仮想プライベートゲートウェイの作成をクリック
挿絵013_改

・VPCにアタッチをクリック
接続したいVPCをアタッチ
挿絵014_改

2-3.VPN接続ルーティング設定

・ルートテーブルにルートを追加する。
送信先:172.31.0.0/16
ターゲット:作成した仮想プライベートゲートウェイ
挿絵015_改

・完了後、ルート伝達のタブをクリックし、編集をクリックし伝達にチェックをつけ保存。
挿絵016_改

2-4.VPN接続の作成

・AWSコンソールのVPCを開き、左側ペインのVPN接続をクリックし、VPN接続の作成をクリック
仮想プライベートゲートウェイ:作成したvgw
カスタマーゲートウェイ:作成したcgw
ルーティングオプション:静的
IPプレフィックス:172.31.0.0/16
挿絵017_改

2-5.VPN接続設定ファイルのダウンロード

・Microsoft Windows2008 R2を選択しダウンロード
挿絵018_改

・ダウンロードしたファイルの中身を修正します。
修正箇所はダウンロードしたファイルの下のほうにあります。
以下部分のパラメータを置き換えて利用します。

[Windows_Server_Private_IP_address]
└Windows Server のプライベート IP アドレスで置き換え

[Your_Static_Route_IP_Prefix]
└Windows Server が存在するネットワークの CIDR で置き換え

[Your_VPC_CIDR_Block]
└ シドニーリージョンのVPC の CIDR で置き換え

~中略~
! Script for Tunnel 1:
netsh advfirewall consec add rule Name="vgw-050****** Tunnel 1" ^
Enable=Yes Profile=any Type=Static Mode=Tunnel ^
LocalTunnelEndpoint=[Windows_Server_Private_IP_address] ^
RemoteTunnelEndpoint=52.63.230.211 Endpoint1=[Your_Static_Route_IP_Prefix] ^
Endpoint2=[Your_VPC_CIDR_Block] Protocol=Any Action=RequireInClearOut ^
Auth1=ComputerPSK Auth1PSK=************************************ ^
QMSecMethods=ESP:SHA1-AES128+60min+100000kb ^
ExemptIPsecProtectedConnections=No ApplyAuthz=No QMPFS=dhgroup2

! Script for Tunnel 2:
netsh advfirewall consec add rule Name="vgw-050****** Tunnel 2" ^
Enable=Yes Profile=any Type=Static Mode=Tunnel ^
LocalTunnelEndpoint=[Windows_Server_Private_IP_address] ^
RemoteTunnelEndpoint=54.66.221.68 Endpoint1=[Your_Static_Route_IP_Prefix] ^
Endpoint2=[Your_VPC_CIDR_Block] Protocol=Any Action=RequireInClearOut ^
Auth1=ComputerPSK Auth1PSK=************************************ ^
QMSecMethods=ESP:SHA1-AES128+60min+100000kb ^
ExemptIPsecProtectedConnections=No ApplyAuthz=No QMPFS=dhgroup2
~以下省略~

3.VPN接続設定 (作業リージョン:東京)

3-1.カスタマーゲートウェイにて接続設定の反映

・シドニーリージョンでダウンロード取得し書き換えた内容を、リモートデスクトップにて接続しWindowsサーバのコマンドプロンプトにて実行する。
挿絵020_改

・ダウンロードファイルを利用して接続設定を実施しましたが、手動にて設定していくことも可能です。手動設定については割愛させていただきます。

3-2.Windowsファイアウォールの設定

・[サーバーマネージャー] を開き、[構成]、[セキュリティが強化された Windows ファイアウォール]、[プロパティ] を選択
挿絵021_改

・[IP sec の設定] タブで [IP sec 既定] の項目の [カスタマイズ] をクリック
挿絵022

・[キー交換 (メイン モード)] の項目の [詳細設定] にチェックを入れて [カスタマイズ] をクリック
挿絵023_改

・[キー交換オプション] の [Diffie-Hellman を使用してセキュリティを強化する] をチェックして、[OK] をクリック
挿絵024_改

・[データ保護 クイックモード)] の項目の [詳細設定] にチェックを入れて、[カスタマイズ] をクリック
挿絵025_改

・[この設定を使用するすべての接続セキュリティ規則に暗号化を要求する] にチェックを入れて、[OK] をクリック
挿絵026_改

3-3.停止しているゲートウェイの検出のため設定

・サーバーで、[スタート] をクリックし、regedit と入力して [レジストリエディタ] を起動
・[HKEY_LOCAL_MACHINE]、[SYSTEM]、[CurrentControlSet]、[Service]、[Tcpip]、[Paremeters] と展開
・右側のペインで右クリックし、[新規]、[DWORD (32-bit) Value]
・名前は [EnableDeadWDetect]と入力
挿絵027_改

・[値のデータ] に [1] を入力し、[OK] をクリック
挿絵028

・完了後エディタを終了し、WindowsServerを再起動する。

設定作業はここまでとなります。

VPN接続確認テスト

ここからは設定後の確認となります。
お互いのVPC上のホストからPingが通るかどうかにより確認していきます。

・確認その1: シドニーリージョンVPC から 東京リージョンVPC
・シドニーのwindowsホスト(10.0.150.165)から東京のWindowsホスト(172.31.13.2)へpingにて疎通確認

C:\Users\Administrator>ipconfig

Windows IP Configuration

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : ap-southeast-2.compute.internal
   Link-local IPv6 Address . . . . . : fe80::c1db:3156:****:*****
   IPv4 Address. . . . . . . . . . . : 10.0.150.165
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.0.150.1

Tunnel adapter isatap.ap-southeast-2.compute.internal:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : ap-southeast-2.compute.internal

Tunnel adapter Local Area Connection* 11:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

C:\Users\Administrator>ping 172.31.13.2

Pinging 172.31.13.2 with 32 bytes of data:
Reply from 172.31.13.2: bytes=32 time=106ms TTL=127
Reply from 172.31.13.2: bytes=32 time=106ms TTL=127
Reply from 172.31.13.2: bytes=32 time=106ms TTL=127
Reply from 172.31.13.2: bytes=32 time=106ms TTL=127

Ping statistics for 172.31.13.2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 106ms, Maximum = 106ms, Average = 106ms

・確認その2: 東京リージョンVPC から シドニーリージョンVPC
・東京のwindowsホスト(172.31.13.2)からシドニーのWindowsホスト(10.0.150.165)へpingにて疎通確認

C:\Users\Administrator>ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : ap-northeast-1.compute.internal
   IPv4 Address. . . . . . . . . . . : 172.31.13.2
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . : 172.31.0.1

Tunnel adapter isatap.ap-northeast-1.compute.internal:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : ap-northeast-1.compute.internal

Tunnel adapter Local Area Connection* 11:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

C:\Users\Administrator>ping 10.0.150.165

Pinging 10.0.150.165 with 32 bytes of data:
Reply from 10.0.150.165: bytes=32 time=106ms TTL=127
Reply from 10.0.150.165: bytes=32 time=106ms TTL=127
Reply from 10.0.150.165: bytes=32 time=106ms TTL=127
Reply from 10.0.150.165: bytes=32 time=106ms TTL=127

Ping statistics for 10.0.150.165:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 106ms, Maximum = 106ms, Average = 106ms

さいごに

AWSのサービスのみを組み合わせるだけで、別リージョンVPC間の接続を実現することができました。AWS VPCはVPN接続を作成した時点から課金(1時間あたり0.05 USD)が発生しますのでご注意ください。インターネット経由では接続できず別リージョン間VPCにてアクセスを実現したいことは意外とあると思いますので、参考になれば幸いです。

参考サイト:http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/NetworkAdminGuide/CustomerGateway-Windows.html#CreateVPNConnection

VM Import/ExportにてAMIイメージ作成

花粉のシーズンも過ぎだいぶ楽になってきました。こんにちはhatです。
VMWareのESXi上で作成された仮想マシンをAWSに移行する機会があり、その際に利用したVM Import/Exportの内容について備忘録を兼ねてまとめてみました。

注意事項

一部対応していないOSのバージョンがありますので、対象のバージョンがありますので作業前に公式サイトにて確認の上実施してください。

作業準備

作業するにあたり、下記の準備が終わっていることを前提として話をしていきます。

  • AWS CLIがインストール済みであること
  • インポート用のvmdkファイルの準備できていること

S3バケットの作成とファイルアップロード

まずは準備したvmdkファイルのアップロード先のバケットを作成します。

aws s3 mb s3://<任意のバケット名>

コマンド例) aws s3 mb s3://vm-import-tmp

 

続いて作成したバケットにファイルをアップロードします。
標準出力でアップロードの進捗が表示されるので完了するまで待ちます。

aws s3 cp <vmdk名> s3://<作成したバケット名>

コマンド例) aws s3 cp /tmp/CentOS6.1_disk1.vmdk s3://vm-import-tmp

 

VMImport用にサービスロールの作成

続いてインポート実行できるようにするためにポリシーを作成し権限を与えます。
詳しくは公式のサイト(http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/VMImportPrerequisites.html)の中盤くらいに記述がありますので、ご確認いただければと思います。

VM Import では、実行に AWS アカウントのロールが使用されます。
vmimport という名前のロールを作成する必要があります。
ポリシーを定義した trust-policy.json という名前のファイルを作成していきます。
以下準備するtrust-policy.jsonファイルの内容は、変更箇所はないのでそのまま記述します。

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"",
         "Effect":"Allow",
         "Principal":{
            "Service":"vmie.amazonaws.com"
         },
         "Action":"sts:AssumeRole",
         "Condition":{
            "StringEquals":{
               "sts:ExternalId":"vmimport"
            }
         }
      }
   ]
}

 

上記のファイルを利用し、vmimportに権限を与えます。

aws iam create-role --role-name vmimport --assume-role-policy-document file://trust-policy.json

 

続いてrole-policy.json という名前のファイルを作成します。

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "s3:ListBucket",
            "s3:GetBucketLocation"
         ],
         "Resource":[
            "arn:aws:s3:::<ディスクイメージを配置したS3のバケット名>"
         ]
      },
      {
         "Effect":"Allow",
         "Action":[
            "s3:GetObject"
         ],
         "Resource":[
            "arn:aws:s3:::<ディスクイメージを配置したS3のバケット名>/*"
         ]
      },
      {
         "Effect":"Allow",
         "Action":[
            "ec2:ModifySnapshotAttribute",
            "ec2:CopySnapshot",
            "ec2:RegisterImage",
            "ec2:Describe*"
         ],
         "Resource":"*"
      }
   ]
}

 

作成したポリシーをロールに追加します。

aws iam put-role-policy --role-name vmimport --policy-name vmimport --policy-document file://role-policy.json

 

IAMユーザーとしてログインしている場合、IAM ポリシーに下記のアクセス許可が必要となるため設定をします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListAllMyBuckets"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:CreateBucket",
        "s3:DeleteBucket",
        "s3:DeleteObject",
        "s3:GetBucketLocation",
        "s3:GetObject",
        "s3:ListBucket",
        "s3:PutObject"
      ],
      "Resource": ["arn:aws:s3:::<ディスクイメージを配置したS3のバケット名>","arn:aws:s3:::<ディスクイメージを配置したS3のバケット名>/*"]
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CancelConversionTask",
        "ec2:CancelExportTask",
        "ec2:CreateImage",
        "ec2:CreateInstanceExportTask",
        "ec2:CreateTags",
        "ec2:DeleteTags",
        "ec2:DescribeConversionTasks",
        "ec2:DescribeExportTasks",
        "ec2:DescribeInstanceAttribute",
        "ec2:DescribeInstanceStatus",
        "ec2:DescribeInstances",
        "ec2:DescribeTags",
        "ec2:ImportInstance",
        "ec2:ImportVolume",
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:TerminateInstances",
        "ec2:ImportImage",
        "ec2:ImportSnapshot",
        "ec2:DescribeImportImageTasks",
        "ec2:DescribeImportSnapshotTasks",
        "ec2:CancelImportTask"
      ],
      "Resource": "*"
    }
  ]
}

Import-Imageの実行

イメージをインポートするための設定ファイルを作成します。
ここでは、params.jsonという名でファイルを準備します。
必要最低限の設定のみ記載しています。

{
    "Description": "vm-import",
    "DiskContainers": [
        {
            "Description": "vm-import",
            "UserBucket": {
                "S3Bucket": "<ディスクイメージを配置したS3のバケット名>",
                "S3Key": "<vmdk名>"
            }
        }
    ]
}

 

下記コマンドにてインポート実施します。

aws ec2 import-image --cli-input-json file://./params.json

すると下記のような出力が表示されます。

{
    "Status": "active",
    "Description": "vm-import",
    "Progress": "2",
    "SnapshotDetails": [
        {
            "UserBucket": {
                "S3Bucket": "<ディスクイメージを配置したS3のバケット名>",
                "S3Key": "<vmdk名>"
            },
            "DiskImageSize": 0.0
        }
    ],
    "StatusMessage": "pending",
    "ImportTaskId": "<払い出されたID>"
}

 

コマンド実施後標準出力には進捗状況がわかりませんので、
逐次以下のコマンドにて状況を確認してください。

aws ec2 describe-import-image-tasks --import-task-ids <払い出されたID>
{
    "ImportImageTasks": [
        {
            "Status": "completed",   ---->★完了するとこの状態に
            "LicenseType": "BYOL",
            "Description": "vm-import",
            "ImageId": "ami-******",
            "Platform": "Linux",
            "Architecture": "x86_64",
            "SnapshotDetails": [
                {
                    "DeviceName": "/dev/sda1",
                    "Description": "",
                    "Format": "VMDK",
                    "DiskImageSize": 5251216896.0,
                    "SnapshotId": "******",
                    "UserBucket": {
                        "S3Bucket": "<ディスクイメージを配置したS3のバケット名>",
                        "S3Key": "<vmdk名>"
                    }
                }
            ],
            "ImportTaskId": "<払い出されたID>"
        }
    ]
}

AWSコンソールにログインし、EC2->イメージ->AMIを確認してみてください。
イメージが作成されていることが確認できます。
現状ではAMIイメージを作成し終わった状態ですので、実際に利用する場合は
イメージからEC2インスタンス作成してください。

まとめ

以上が作業の流れとなります。事前準備について時間がかかりましたが、
準備後に実施するコマンドはそう多くありません。比較的簡単にできますので、
触れたことない方は実践してみてはいかがでしょうか。

同一セグメントにて複数インターフェースがある時のNW設定

はじめまして、hatです。

EC2上にてCentOSのマシンを稼動させ、複数のIPを持たせる必要があり作業をしたときのことです。
NWに詳しい方は想定できるかもしれませんが、備忘録をかねて作業内容を書いていきたいと思います。

環境情報

・EC2インスタンス (CentOS5.4を利用)
・ENIを2つ追加し、複数のIPアドレスを追加
・IFのセグメントはすべて同一(eth0,eth1,eth2)

  • eth0:10.6.3.92
  • eth1:10.6.3.96
  • eth2:10.6.3.100

最初にAWSコンソールにてログインし、EC2インスタンスのネットワークインターフェースの追加し、
それぞれのインターフェースにEIPを割り当てました。それではsshにてアクセスしてみます。
結果は下記のようになりました。

  • eth0 → sshアクセス可能
  • eth1  → 応答なし
  • eth2 → 応答なし

あれ、なぜつながらない・・・。ここでしばらく悩んでしまいました。
ふとルーティングテーブルを見てみると下記の状態になっていることに気づきました。

 

【ルーティングテーブルの情報】

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.6.3.0        *               255.255.255.0   U     0      0        0 eth0
10.6.3.0        *               255.255.255.0   U     0      0        0 eth1
10.6.3.0        *               255.255.255.0   U     0      0        0 eth2
169.254.0.0     *               255.255.0.0     U     0      0        0 eth2
default         10.6.3.1        0.0.0.0         UG    0      0        0 eth0

 

ローカルリンクの接続は問題ありませんが、eth1とeth2の外部からの通信は
デフォルトGWであるeth0を通って返されてしまっていました。
これでは正常な通信のやり取りができません。

調べてみるとipコマンドにてルーティングの設定ができるようなので
こちらを利用して設定の導入を進めて行くことにしました。
以下はその時に実施した内容です。

ルーティングテーブルの作成

まずはルーティングテーブルを追加します。
1~252の範囲(0、253~255は予約されている)から作成します。
ここでは100、101を利用しました。

【コマンド】

vi /etc/iproute2/rt_tables

【記載内容】

#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep
100     subroute-eth1    → ★追加
101     subroute-eth2    → ★追加

 

ルーティングの追加

ルートテーブルにルーティングを追加します。

【コマンド】(eth1の設定)

ip route add table subroute-eth1 10.6.3.0/24 dev eth1 scope link proto kernel
ip route add table subroute-eth1 default via 10.6.3.1 dev eth1

 

【コマンド】(eth2の設定)

ip route add table subroute-eth2 10.6.3.0/24 dev eth2 scope link proto kernel
ip route add table subroute-eth2 default via 10.6.3.1 dev eth1

 

実際に反映されているか確認します。

【コマンド】

ip route show table subroute-eth1

【表示結果】

10.6.3.0/24 dev eth1  proto kernel  scope link
default via 10.6.3.1 dev eth1

 

【コマンド】

ip route show table subroute-eth2

【表示結果】

10.6.3.0/24 dev eth2  proto kernel  scope link
default via 10.6.3.1 dev eth2

ルートテーブル参照条件のルールを追加

作成したルーティングテーブルが参照されるようにルールへ追加します。
mainのテーブル(routeコマンドで参照できるもの)よりも優先的に参照するように
優先度を上げておきます。

【コマンド】

ip rule add from 10.6.3.96 table subroute-eth1 prio 100
ip rule add from 10.6.3.100 table subroute-eth2 prio 110

 

ルーティングテーブルのルール情報を確認します。
【コマンド】

ip rule show

【表示結果】

0:      from all lookup 255
100:    from 10.6.3.96 lookup subroute-eth1   →★追加
110:    from 10.6.3.100 lookup subroute-eth2  →★追加
32766:  from all lookup main                  →routeコマンドで表示されるテーブル
32767:  from all lookup default

OS起動時/ネットワーク再起動時の対処

1.OS起動時対応用、スクリプトを作成しておきます。

【コマンド】

vi /usr/local/sbin/subroute.sh

【記載内容】

#!/bin/sh

#ルーティングルートテーブル追加
#[eth1用]
ip route add table subroute-eth1 10.6.3.0/24 dev eth1 proto kernel scope link
ip route add table subroute-eth1 default via 10.6.3.1 dev eth1

#[eth2用]
ip route add table subroute-eth2 10.6.3.0/24 dev eth2 proto kernel scope link
ip route add table subroute-eth2 default via 10.6.3.1 dev eth1

#ルーティングルール追加
#[eth1用]
ip rule add from 10.6.3.96 table subroute-eth1 prio 100

#[eth2用]
ip rule add from 10.6.3.100 table subroute-eth2 prio 110

 

2.ネットワークコマンド実行時用のファイルを作成します。

【コマンド】

vi /usr/local/sbin/subroute2.sh

【記載内容】

#!/bin/sh

#ルーティングルートテーブル追加
#[eth1用]
ip route add table subroute-eth1 10.6.3.0/24 dev eth1 proto kernel scope link
ip route add table subroute-eth1 default via 10.6.3.1 dev eth1

#[eth2用]
ip route add table subroute-eth2 10.6.3.0/24 dev eth2 proto kernel scope link
ip route add table subroute-eth2 default via 10.6.3.1 dev eth1

 

3.ツールに実行権限を付与

chmod 755 /usr/local/sbin/subroute.sh
chmod 755 /usr/local/sbin/subroute2.sh

 

4.自動起動に対応させるための修正

OS起動時用の登録

vi /etc/rc.local

【記載内容】

sh /usr/local/sbin/subroute.sh

 

5.ネットワークコマンド実行時用の登録

vi /etc/init.d/network

【記載内容】

[抜粋]
         sh /usr/local/sbin/subroute2.sh
         ;; ←閉じ前に記載すること
  stop)  
[抜粋]

終わりに

何とか想定どおりの動きになってくれました。ルーティングについては、奥が深く難しく感じましたが、苦労して分つながるとうれしいものです。すこしでも参考になっていただければ幸いです。