元パチ屋店員NWエンジニアの技術ブログ

元パチ屋店員NWエンジニアが技術のアウトプット化を目的に、好き勝手な事を書いてるブログです

AWSにGNS3サーバを立ててみた

f:id:hayato-ota-rf:20171028190256p:plain

CCNPの勉強の為にNWの検証ツールとしてGNS3を使いたいから、その設定方法をメモがてらアゲ

GNS3の環境

①クライアントOSでローカルサーバとして動かす

②サーバOSでリモートサーバとして動かす

③クライアントOSのVM上でローカルサーバorリモートサーバとして動かす

④GNS3専用クラウド?でリモートサーバとして動かす(名前忘れた)

多分この中で一般的なのは③ですが、今回は②でいこうと思います。

※自宅PCをリモート起動できるようになったら、自宅PCのVM上でリモートサーバとして動かしてみようかな?スペック的に自宅PC強いし

けど借りてたラズパイを返却しちゃったから、自宅PCをリモート起動できんのや\(^o^)/

raptor-falcon.hatenablog.com

設定手順

GNS3サーバの構築

GNS3 | The software that empowers network professionals

Install on a remote server - GNS3

↑のサイトを参考にして貰えば、大体上手く行きます

今回私はUbuntu16.04を使用

オープンVPNのインストールはなしで、Cisco IOU / IOL のインストールを行なってます

Cisco IOU / IOL

Cisco IOU ( IOS on Unix ) / IOL ( IOS on Linux )とは、Unix/Linuxサーバ上で動作させる事ができるCisco IOSです

通常のGNS3だとルータのIOSしか動かせず、L2スイッチやL3スイッチの検証ができません

無理やりNM-16ESWモジュールが使えるIOSで検証できなくはないんですが、やはりコマンドの構文が若干違ったり、RSTP, MST, etherchannelの検証ができなかったりするので、CCNP以上の検証がしたいならCisco IOU / IOLはインストールしときましょう 

Cisco IOSの入手

Google先生に聞いて下さい

Cisco IOU / IOL ライセンスキーの発行

Google先生に聞いて下さい

※ヒント

Python

クライアント側GNS3の設定

GNS3 Windows版の使い方

↑のサイト参考にして貰えば、大体上手く行きます

GNS3のバージョンや形態によって若干設定方法に違いがあるので、その点を補足

今回使用しているGNS3のバージョンは2.0.3です

・サーバの指定

1.Edit→Preferences→Server→Main server

2.Enable local serverのチェックを外す

3.HostにGNS3サーバのIPを指定

※ローカルサーバとリモートサーバを兼用したい場合はこの限りではありません

f:id:hayato-ota-rf:20171029092032p:plain

 Cisco IOU / IOL – IOS のアップロード

1.Edit→Preferences→IOS on UNIX→IOU Devices→New

2.NAMEに適当な名前を入力

3.ラジオボタンでNew Imageを選択

4.TypeでアップロードするIOSのタイプを選択(L2orL3)

5.IOU imageにBrowse...からIOSを選択

f:id:hayato-ota-rf:20171029092221p:plain

 Cisco IOU / IOL – ライセンスキーのアップロード

1.メモ帳を起動

2.以下の形式で入力し、ファイル名:iourc.txtで保存

AAA

→GNS3サーバのホスト名

BBBBBBBBBBBB

→発行したライセンスキー

[license]

AAA = BBBBBBBBBBBB;

3.Edit→Preferences→IOS on UNIX

4.Browse...から2.で作成したテキストファイルを指定

f:id:hayato-ota-rf:20171029093619p:plain

結果

これでCCNP勝つるお(^ω^≡^ω^) 

f:id:hayato-ota-rf:20171029095646p:plain

補足

バグメモ

・HSRP等のデフォゲ冗長化プロトコルでHelloパケットが正常に送出されない

→no ip igmp snoopingの設定を入れる

GNS3 | The software that empowers network professionals

・L3イーサチャネルが正常動作しない

→対策なし

GNS3 | The software that empowers network professionals

・ループしてないのにGARPがフラッティングし、CPU使用率が上昇する

 

 

EC2の連続稼働時間をLINEに通知してみた

f:id:hayato-ota-rf:20171023025805p:plain

AWS上のEC2を一定時間操作しなかったら、EC2を自動停止するような運用をしているんですが、CloudWatchのアラーム状態がアラートのままだと正常に自動停止してくれません
頻発する事象ではなかったので放置かましてましたが、今日AWSにログインしたらEC2が三日間稼働しっぱなしでした・・・ont
CloudWatchのアラーム状態がアラート⇒OKになる条件が、EC2を起動したあとのログインなので(ActiveSessionsを監視している為)
EC2を起動するだけしてログインせず放置すると、今回のような事象が発生します
なんで、正常に自動停止してくれなかった時に気が付けるように、EC2の連続稼働時間が12時間and24時間を超えた時にLINEに通知させるようにします

参考手順

raptor-falcon.hatenablog.com

 

raptor-falcon.hatenablog.com

 

raptor-falcon.hatenablog.com

手順

カスタムメトリクスの設定(Windows

※参考手順と被っている個所は省きます

①Systems Manager Run Commandに設定してある、JSONファイルの編集

1.EC2 コンソールのステートマネージャー→既存の設定をチェック→アクション→関連付けの編集

f:id:hayato-ota-rf:20171022230822p:plain

2.パラメータのPropertiesをJSON形式で編集し→関連付けの編集

f:id:hayato-ota-rf:20171022231155p:plain

JSON

{

"IsEnabled":true,

"EngineConfiguration": {

  "PollInterval": "00:00:15",

  "Components": [

    {

      "Id": "ApplicationEventLog",

      "FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,

AWS.EC2.Windows.CloudWatch",

      "Parameters": {

        "LogName": "Application",

        "Levels": "1"

      }

    },

    {

      "Id": "SystemEventLog",

      "FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,

AWS.EC2.Windows.CloudWatch",

      "Parameters": {

        "LogName": "System",

        "Levels": "7"

      }

    },

    {

      "Id": "SecurityEventLog",

      "FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,

AWS.EC2.Windows.CloudWatch",

      "Parameters": {

        "LogName": "Security",

        "Levels": "7"

      }

    },

    {

      "Id": "ETW",

      "FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,

AWS.EC2.Windows.CloudWatch",

      "Parameters": {

        "LogName": "Microsoft-Windows-WinINet/Analytic",

        "Levels": "7"

      }

    },

    {

      "Id": "IISLogs",

      "FullName": "AWS.EC2.Windows.CloudWatch.CustomLog.CustomLogInputComponent,

AWS.EC2.Windows.CloudWatch",

      "Parameters": {

        "LogDirectoryPath": "C:\\inetpub\\logs\\LogFiles\\W3SVC1",

        "TimestampFormat": "yyyy-MM-dd HH:mm:ss",

        "Encoding": "UTF-8",

        "Filter": "",

        "CultureName": "en-US",

        "TimeZoneKind": "UTC"

      }

    },

    {

      "Id": "CustomLogs",

      "FullName": "AWS.EC2.Windows.CloudWatch.CustomLog.CustomLogInputComponent,

AWS.EC2.Windows.CloudWatch",

      "Parameters": {

        "LogDirectoryPath": "C:\\CustomLogs\\",

        "TimestampFormat": "MM/dd/yyyy HH:mm:ss",

        "Encoding": "UTF-8",

        "Filter": "",

        "CultureName": "en-US",

        "TimeZoneKind": "Local"

      }

    },

    {

      "Id": "PerformanceCounterMemory",

      "FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.

PerformanceCounterInputComponent,

             AWS.EC2.Windows.CloudWatch",

      "Parameters": {

        "CategoryName": "Memory",

        "CounterName": "Available MBytes",

        "InstanceName": "",

        "MetricName": "Available-Memory",

        "Unit": "Megabytes",

        "DimensionName": "InstanceId",

        "DimensionValue": "{instance_id}"

      }

    },

    {

      "Id": "PerformanceCounterCPU",

      "FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.

PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch",

      "Parameters": {

        "CategoryName": "Processor",

        "CounterName": "% Processor Time",

        "InstanceName": "_Total",

        "MetricName": "CPU",

        "Unit": "Percent",

        "DimensionName": "InstanceId",

        "DimensionValue": "{instance_id}"

      }

    },

    {

      "Id": "PerformanceCounterActiveSessions",

      "FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.

PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch",

      "Parameters": {

        "CategoryName": "Terminal Services",

        "CounterName": "Active Sessions",

        "InstanceName": "",

        "MetricName": "ActiveSessions",

        "Unit": "Count",

        "DimensionName": "InstanceId",

        "DimensionValue": "{instance_id}"

      }

    },

===================今回追記した部分===================

    {

      "Id": "PerformanceCounterSystemUpTime",

      "FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.

PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch",

      "Parameters": {

        "CategoryName": "System",

        "CounterName": "System Up Time",

        "InstanceName": "",

        "MetricName": "SystemUpTime",

        "Unit": "Count",

        "DimensionName": "InstanceId",

        "DimensionValue": "{instance_id}"

      }

    },

================================================

    {

      "Id": "CloudWatchLogs",

      "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatchLogsOutput,

AWS.EC2.Windows.CloudWatch",

      "Parameters": {

        "AccessKey": "",

        "SecretKey": "",

        "Region": "us-east-1",

        "LogGroup": "Default-Log-Group",

        "LogStream": "{instance_id}"

      }

    },

    {

      "Id": "CloudWatch",

      "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatch.CloudWatchOutputComponent,

AWS.EC2.Windows.CloudWatch",

      "Parameters": {

        "AccessKey": "",

        "SecretKey": "",

        "Region": "us-east-1",

        "NameSpace": "Windows"

      }

    }

  ],

  "Flows": {

    "Flows":

    [

      "(ApplicationEventLog,SystemEventLog),CloudWatchLogs",

      "(PerformanceCounterActiveSessions),CloudWatch",

===================今回追記した部分===================

      "(PerformanceCounterSystemUpTime),CloudWatch"

================================================

    ]

  }

 }

}

②カスタムメトリクスが取得できているか確認

f:id:hayato-ota-rf:20171022235701p:plain

カスタムメトリクスの設定(Linux

※参考手順と被っている個所は省きます

①カスタムメトリクス送信用スクリプトを編集

vi /home/hayato/cloudwatch cloudwatch

#!/bin/bash

 

############ACTIVESESIONS############

 

#VariableDefine

PROFILE=CloudWatch

METRIC_NAME_1=ActiveSessions ←変数名を変更

METRIC_NAME_2=SystemUpTime ←追加

NAMESPACE=Linux

VALUE_1=$(who | wc -l) ←変数名を変更

VALUE_2=$(cat /proc/uptime | awk '{print $1}') ←追加

UNIT=Count

INSTANCE_ID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)

 

#CLI

aws cloudwatch put-metric-data --profile ${PROFILE} --metric-name ${METRIC_NAME_1}

--namespace ${NAMESPACE} --value ${VALUE_1} --unit ${UNIT} --dimensions "InstanceId=${INSTANCE_ID}" ←変数名を変更

aws cloudwatch put-metric-data --profile ${PROFILE} --metric-name ${METRIC_NAME_2}

--namespace ${NAMESPACE} --value ${VALUE_2} --unit ${UNIT} --dimensions "InstanceId=${INSTANCE_ID}" ←追加

##################################

※コマンド補足

cat /proc/uptime

→「システムが起動してから経過した合計秒数」と「各コアがアイドル状態で経過した合計時間の秒数」が記録されているので、それをcatで確認

awk '{print $1}'

→カスタムメトリクスとして必要なのはシステムが起動してから経過した合計秒数だけなので、パイプでawkコマンドに渡して、一番目のフィールドだけが出力されるようにしている

 

②カスタムメトリクスが取得できているか確認

f:id:hayato-ota-rf:20171023012806p:plain

LINEへの通知設定

※参考手順と被っている個所は省きます

①CloudWatchの設定

カスタムメトリクスで起動してからの時間を秒数でカウントしているので、秒数が一定数を超えたらアラームが警告になるよう設定

f:id:hayato-ota-rf:20171023014542p:plain

※12時間=43200秒

 24時間=86400秒

②Lambdaの設定

1.Lambdaコンソールのダッシュボード→関数の作成

f:id:hayato-ota-rf:20171023015950p:plain

2.一から作成

f:id:hayato-ota-rf:20171023020056p:plain

3.各パラメータを設定→関数の作成

f:id:hayato-ota-rf:20171023020341p:plain

4.各パラメータを設定→モジュールとコードを含んだZIPファイルをアップロード

f:id:hayato-ota-rf:20171023022254p:plain

※コード

#coding:UTF-8

import requests

 

def lambda_handler(event, context):

    url = "https://notify-api.line.me/api/notify"

    token = "CH9wwDm7N6zt2WooZoorKccgMT06rkdYbLVbduXCJ2D"

    message = ""EC2つけっぱなしにしてない?(12時間連続稼働中)""

    stickerPackageId = 2

    stickerId = 149

 

    headers = {"Authorization": "Bearer " + token}

    payload = {"message" : message , "stickerPackageId" : stickerPackageId, "stickerId" :stickerId}

    r = requests.post(url, headers = headers, data = payload)

 

5.トリガータブ→トリガーを追加

f:id:hayato-ota-rf:20171023022410p:plain

6.各パラメータを指定→送信

f:id:hayato-ota-rf:20171023022503p:plain

7.テストイベントの設定

f:id:hayato-ota-rf:20171023023800p:plain

8.各パラメータを指定→作成

f:id:hayato-ota-rf:20171023023559p:plain

9.テスト

f:id:hayato-ota-rf:20171023023904p:plain

10.実行結果が成功で、LINEに通知が届けばOK

f:id:hayato-ota-rf:20171023024055p:plain

LINE通知例

f:id:hayato-ota-rf:20171023025147p:plain

まとめ

EC2の連続稼働時間程度なら、標準メトリクスとしてAWSが用意してくれてもいいような・・・

 

AWS VPCと自宅LANをVPN接続してみた


f:id:hayato-ota-rf:20170927024441p:plain

構成図

f:id:hayato-ota-rf:20170927031058p:plain

AWS側の設定

①仮想プライベートゲートウェイの設定

1.VPCコンソールで、仮想プライベートゲートウェイの作成をクリック

f:id:hayato-ota-rf:20170927031846p:plain

2.、各パラメータを設定し、仮想プライベートゲートウェイの作成をクリック

f:id:hayato-ota-rf:20170927033042p:plain

②カスタマーゲートウェイの設定

1.VPCコンソールで、カスタマーゲートウェイの作成をクリック

f:id:hayato-ota-rf:20170927032237p:plain

2.各パラメータを設定し、カスタマーゲートウェイの作成をクリック

f:id:hayato-ota-rf:20170927032849p:plain

VPN接続の設定

1.VPCコンソールで、VPN接続の作成をクリック

f:id:hayato-ota-rf:20170927033246p:plain

2.各パラメータを設定し、VPN接続の作成をクリック

f:id:hayato-ota-rf:20170927033633p:plain

VPCルートテーブルの設定

1.宛先が自宅LANのIP(172.16.1.0/24)は、①で作成した仮想プライベートゲートウェイに向くように設定

f:id:hayato-ota-rf:20170927035127p:plain

自宅側の設定

AWS VPCVPN接続できるルータには制限があります

私はYAMAHACiscoルータを持っていないので、ホスト型VMwereを利用し仮想NW上にVyOSを構築します

今回は検証なので良いのですが、実際に運用するとなると物理マシンにVyOSを導入したものを使用するか、YAMAHACiscoルータを使用する必要がありそうですね

仮想NW構成図

f:id:hayato-ota-rf:20170927043013p:plain

仮想マシンの設定

1.ISOのダウンロード

↓のサイトからISOをダウンロード

VyOS Wiki

CentOS Project

2.仮想マシンの作成

詳細はVMwereでググって下さい

 

3.VyOSの仮想NIC設定

f:id:hayato-ota-rf:20170927043926p:plain

f:id:hayato-ota-rf:20170927044030p:plain

4.CentOSの仮想NIC設定

f:id:hayato-ota-rf:20170927044339p:plain

②NATルータの設定

1.VyOSのeth0のIPを固定

DHCP側で固定させます 

※先にVyOS側のDHCP有効にしてないと、一覧に表示されないかもです

 

2.ポートフォワードの設定

VyOSのeth0に4500と500のUDPが転送されるように設定

何故4500と500のUDPなのかはNATトラバーサルを参照

f:id:hayato-ota-rf:20170927052123p:plain

③VyOSの設定

1.デフォルトログイン

初期ユーザ名:vyos

初期パスワード:vyos

2.初期設定

$ install image

画面に従って入力

Would you like to continue? (Yes/No) [Yes]: [return]

Partition (Auto/Parted/Skip) [Auto]: [return]

Install the image on? [sda]: [return]

Continue? (Yes/No) [No]: Yes

How big of a root partition should I create? (1000MB – 2147MB) [2147]MB: [return]

Which one should I copy to sda? [/config/config.boot]: [return]

Enter password for user 'vyos': [パスワード]

Retype password for user 'vyos': [パスワード]

Which drive should GRUB modify the boot partition on? [sda]: [return]

3.sshの設定

VM上だと超設定し辛いので、取り合いずssh出来るように設定

$ configure

# set interfaces ethernet eth0 address dhcp

# set service ssh

# commit

# save

# exit

$ reboot

4.rootパスワードの設定

ここからTeraTarmを使用

$ configure

# set system login user root authentication plaintext-password [パスワード]

# commit

# save

5.キーボードの設定

# su -

Password:

# vi /etc/default/keyboard

[変更前]

XKBMODEL=”pc105”

XKBLAYOUT=”us”

[変更後]

XKBMODEL=”pc106”

XKBLAYOUT=”jp”

# exit

# exit

$ reboot

6.タイムゾーンの設定

$ configure

# set system time-zone Asia/Tokyo

# commit

# save

# exit

正常な時刻か確認

$ date

7.インターフェイスの設定

$ configure

# set interfaces ethernet eth0 description OutSide

# set interfaces ethernet eth1 address 172.16.1.1/24

# set interfaces ethernet eth1 description InSide

8.VPNインターフェースとNATトラバーサルの設定

# set vpn ipsec nat-traversal enable

# set vpn ipsec ipsec-interfaces interface eth0

# set vpn ipsec nat-networks allowed-network 0.0.0.0/0 ←VPN接続を許可するIPを指定

8.AWS configのダウンロード

f:id:hayato-ota-rf:20170927052938p:plain

9.AWS configの流し込み

③の8でダウンロードしてきたテキストファイルに記載してあるコマンドをコピペして流し込み

10.VPNトンネルのローカルアドレスをVyOSのeth0のアドレスへ変更

トンネルが二つある理由は、冗長化されているからです

# set vpn ipsec site-to-site peer xxx.xxx.76.184 local-address 192.168.1.10

# set vpn ipsec site-to-site peer xxx.xxx.98.6 local-address 192.168.1.10

10.VPN IPsecプロセスの再起動及び、設定の適用

# sudo /etc/init.d/ipsec restart

# commit

# save

CentOSの設定

eth0のIPは172.16.1.2に設定

デフォルトゲートウェイは172.16.1.1に設定

DNSは192.168.11.1に設定

正常性の確認

VPNステータスがアップになっているか確認

正しく設定できていれば、ステータスがアップになる

f:id:hayato-ota-rf:20170927054057p:plain

AWSのEC2からVMnet上のCentOSにプライベートIPでPing疎通確認

EC2側の様子

f:id:hayato-ota-rf:20170927055257p:plain

CentOS側の様子

f:id:hayato-ota-rf:20170927055512p:plain

結果

自宅であっても割りと簡単にAWS VPCVPN張れるようですね

ただAWS VPNは接続時間毎の課金&自宅ルータの固定IPが必要になってくるので、家庭レベルで実用的かどうかといわれると・・・

おまけ

NATトラバーサル

詳しくは↓のリンクを見て下さい

IPsec - NATトラバーサルとは(仕組み)

簡単に説明すると、IPsecは通常だとNAPTを超えることができません

それを可能にするのがNATトラバーサルです

なんでIPsecは通常だとNAPTを超えることができないかというと

まず前提としてNAPTって何と何を変換してるでしたっけ?

送信元IPと送信元ポート番号でしたね

でわ↓のIPsecのパケット構造を見て下さい

f:id:hayato-ota-rf:20170905061529g:plain

 

NW詳しい方ならもうお分かりですよね

そうIPsecTCP/UDPヘッダを暗号化範囲に含んでいるので、パケットを受け取ったNAPTは( ゚Д゚)ハァ?ってなってしまうんですね

そうならないようにNATトラバーサルでは、暗号化した後のIPsecパケットにUDPヘッダを新たに付与します

f:id:hayato-ota-rf:20170927061852p:plain

その付与するUDP番号が、4500(IPsec NAT-T)と500(IKE)なんで②の2では、4500と500のUDPをポートフォワーディングさせたんです

参考サイト

VyOS - VyOSの初期設定

VyOSを利用してルータを自作する。導入編 | インフラエンジニアになりたいSIerのwebサイト

VMware Playerの仮想ネットワーク | NAT、ブリッジ、ホストオンリーの仕組み

Raspberry Piを使って自宅PCをリモート起動してみた

f:id:hayato-ota-rf:20170915014710j:plain

外出先で何か検証を行う時、簡単ものであればクラウドとかVPSで事足りるんだけど、それなりのスペックが必要な検証はちょっとしんどい・・・

その点、自宅PCのスペックはというと

プロセッサ:Intel Core i7 950

メモリ:11 GB RAM

SSD:128 GB

私の用途では結構なオーバスペックなPCちゃんなので、こいつを使わないのは勿体無いよね!

けど、電源ユミットが750Wもあるので常時つけっぱだと電気代がががが

あんまりパーツに負荷も掛けたくないし・・・

色々ググったりした結果、Wake on LANといったリモート起動を可能にする技術があるみたいなので、レッツトライ!

要件

・外出先から自宅PCをリモート起動

・外出先から自宅PCをリモート操作

・出来る範囲でセキュリティは高めに

設計

リモート起動方法

・アクセスルータに外部からWebログインし、そこからマジックパケットを送信

セキュリティ的に却下

 

・アクセスルータにマジックパケットをポートフォワードさせる

セキュリティ的に却下

 

Raspberry PiSSHし、そこからマジックパケットを送信

ラズパイなら電気代しれてるし、一回SSHを挟むからセキュリティもなんぼか高いと思うので、この方法を採用

アクセスルータのグローバルIPの特定方法

・固定IP取得

月額1000円もするから却下

 

・アクセスルータ指定のダイナミックDNSを使用

いずれも有料なので、却下

DynDNSは昔は無料だったらしいです・・・

 

・Route53を使用

ホストゾーンと独自ドメインを持っているので、使わないともったいない!

なのでこの方法を採用

Raspberry PiSSHする方法

・アクセスルータにSSH通信をポートフォワードさせる

これが一番手っ取り早い

リモート操作方法

Raspberry PiSSHポートフォワードさせてSSL-VPN確立後、RDP

クライアント側に特定のソフトを入れる必要もないし、レスポンスも一番良いと思うので、この方法を採用したかったんですが

Windows10 HomeはRDPサーバになることができないだと・・・

初めて知ったわ

Gitに海賊版RDPサーバソフトみたいなのもあったけど、WindowsUpdateのせいで今は使えないみたい

まあ使えたとしてもバックドアとか仕込まれてても文句言えないから、セキュリティ的にあれだけど

Proへのアップグレードには13824円もかかるし・・・

ぐぬぬ

 

Chrome リモートデスクトップやTeam Viewer等の、一旦別NW経由してリモートアクセスするソフトを使用

せっかくRaspberry PiSSHまでしてるのに、この方法を使用するのはなんだかな・・・

 

Raspberry PiSSHポートフォワードさせてSSL-VPN確立後、VNC

大学のサーバ構築の授業で使ってたから、その名残でこの方法を採用

構成図

f:id:hayato-ota-rf:20170915010517j:plain

構築手順

Raspberry Piの初期設定

今使ってるRaspberry Pi借り物だから、初期設定済んでるんだよね~

ここの手順は自分の買った時に、追記します

↓はメモ

SSH用ユーザを作成

sudo adduser hayato

※useraddではホームディレクトリが作成されない

 

sudo グループに追加

sudo gpasswd -a hayato sudo

Raspberry PiとRoute53の連携

1.Raspberry Piにログイン

 

2.AWS CLIをインストール

sudo pip install awscli

3.認証情報の設定

aws configure --profile Route53

AWS Access Key ID [None]: XXXXXXXXXXXXXXXXXXXX

AWS Secret Access Key [None]: XXXXXXXXXXXXXXXXXXXXXXX 

Default region name [None]: us-east-1

Default output format [None]:

4.設定の確認

aws configure list --profile Route53

5.作業ディレクトリを作成

mkdir /home/hayato/Route53

6.jsonファイルを作成

vi /home/hayato/Route53/dyndns.tmpl

{

     "Changes":

     [

          {

          "Action": "UPSERT",

          "ResourceRecordSet":

               {

               "Name": "{%HOST%}.raptor-aws.net.",

               "Type": "A",

               "TTL": 300,

               "ResourceRecords":

                    [

                         {

                         "Value": "{%IP%}"

                         }

                    ]

                }

           }

     ]

}

※パラメータ補足

・"Action": "UPSERT"

レコードに対して行うアクションを指定

UPSERT=更新  

CREATE=作成

DELETE=削除

・"Name": "{%HOST%}.raptor-aws.net."

FQDNを指定

・"Value": "{%IP%}"

IPを指定

 

7.シェルスクリプトを作成

vi /home/hayato/Route53/dyndns.sh

#!/bin/bash

 

#VariableDefine

PROFILE=Route53

ROUTE53_PATH=/home/hayato/Route53/

ZONEID=XXXXXXXXXXX

IP=$(curl -s inet-ip.info)

HOSTNAME=$(hostname)

 

#filecreate

sed -e "s/{%IP%}/${IP}/g;s/{%HOST%}/${HOSTNAME}/g" ${ROUTE53_PATH}dyndns.tmpl > ${ROUTE53_PATH}${HOSTNAME}.json

 

#CLI

aws route53 change-resource-record-sets --profile ${PROFILE} --hosted-zone-id ${ZONEID} --change-batch file://${ROUTE53_PATH}${HOSTNAME}.json

・PROFILE

CLIで使用するプロファイルを指定

・ROUTE53_PATH

5で作成したjsonファイルがあるディレクトリを指定

・ZONEID

対象のゾーンIDを指定

f:id:hayato-ota-rf:20170907034825p:plain

・IP

グローバルIPを調べるコマンド

・HOSTNAME

サーバ名を指定

 

8.シェルスプリクトの動作確認

sh /home/hayato/Route53/dyndns.sh

設定ファイル等に誤りがなければ、次のような結果が返ってきます

{

    "ChangeInfo": {

        "Status": "PENDING",

        "SubmittedAt": "2017-09-06T17:34:26.414Z",

        "Id": "/change/C21B4F9LM6BATC"

     }

}

しばらくするとRoute53のレコードが更新されます

 

9.シェルスプリクトの権限設定

sudo chmod 755 /home/hayato/Route53/dyndns.sh

10.cronの設定

アクセスルータがISPから割当られているグローバルIPの変動頻度はよく分かりませんが、一日一回と再起動時にレコード更新でいいかな?

crontab - e

00 00 * * * /home/hayato/Route53/dyndns.sh

@reboot /home/hayato/Route53/dyndns.sh

動作確認の為、1分毎実行にしてからログ確認しといたほうがいいかも

*/1 * * * * /home/hayato/Route53/dyndns.sh

正常に動作している場合は下記のようなログが出力されます

Sep 20 20:02:01 raspberrypi2 CRON[19858]: (hayato) CMD (/home/hayato/Route53/dyndns.sh)

正常動作を確認できたら、動作確認用のcronは削除しときましょう 

③アクセスルータのポートフォワード設定

アクセスルータのベンダや型番によって設定画面が違うと思うので、下記の手順は参考程度と捉えて下さい

 

1.Raspberry Piと自宅PCのIPを固定

ホストに直接設定してもいいけど、DHCPで固定したほうが楽な気がする

f:id:hayato-ota-rf:20170920231931j:plain

2.IPv6が有効になっていないか確認

IPv6接続サービスが有効になってると、どうあがいてもアクセスルータのWAN側に到達できません

私はここで○そハマリました

 

3.ポートフォワードの設定

BUFFALOのアクセスルータだと、ポート変換といった名前みたいです

念の為、WAN側のポートは22番以外にしといた方が良いと思います

まあ鍵認証使うのであれば問題はないんですが、BOTのブルードフォースアタックがなんとなく気に入らないので私は変えときました(笑)

f:id:hayato-ota-rf:20170920232209j:plain

4.外部からRaspberry PiSSH出来るか確認

今回はAWSLinuxサーバからRaspberry Piにアクセスしてみます

f:id:hayato-ota-rf:20170920233544p:plain

SSHのセキュリティ設定

1.SSH鍵認証設定

webkaru.net

2.SSHのパスワード認証禁止設定

sudo vi /etc/ssh/sshd_config

PasswordAuthentication yes → PasswordAuthentication no に変更

SSHの設定を反映

service ssh restart

Wake on LANの設定(Windows10)

Wake on LANはOSやデバイスの相性によって、どうあがいても上手くいかないことがあります

ちなみに私はスリープからの復帰しか無理でした(笑)

まあスリープ状態を復帰させてリモートログインできるなら、まあよしとしましょう

 

1.ネットワークアダプタの設定

バイスマネージャから使用してるNICドライバーのプロパティを開いて、↓の画像のように設定されているか確認

f:id:hayato-ota-rf:20170921001526j:plain

2.電源設定

コントロールパネル→電源オプションの左ペインにある電源ボタンの動作設定を選択をクリックし、高速スタートアップのチェックを外す

私はスリープからの復帰しか無理だったので、チェック入れたままにしています

f:id:hayato-ota-rf:20170921002226p:plain

3.BIOSの設定

BIOSの設定はベンダとバージョンによって設定項目がまちまちなので、自分が使っているBIOSに合う設定を頑張って見つけて下さい(笑)

例↓

f:id:hayato-ota-rf:20170921002717j:plain

マジックパケット送信スプリクト作成

1.Raspberry Piにログイン

 

2.wakeonlanのインストール

sudo apt-get install wakeonlan

3.スクリプトの作成

vi wakeonlan.sh

#!/bin/bash

 

IP="192.168.11.X"
COUNT="0"

MAC="XX:XX:XX:XX:XX:XX"

 

wakeonlan -i ${IP} -p9 ${MAC}
wakeonlan -i ${IP} -p9 ${MAC}
wakeonlan -i ${IP} -p9 ${MAC}


while :
    do
    ping ${IP} -c 1 >> /dev/null
    if [ $? -eq 0 ] ;then
        echo "${IP} : OK"
        break
    else
        wakeonlan -i ${IP} -p9 ${MAC}
        COUNT=$*1
            if [ $COUNT -eq 3 ] ;then
            echo "${IP} : NG"
            break
            fi
    fi
done

 

成功の時のコマンド結果は↓のようになる

Sending magic packet to 192.168.11.X:9 with XX:XX:XX:XX:XX:XX
Sending magic packet to 192.168.11.X:9 with XX:XX:XX:XX:XX:XX
Sending magic packet to 192.168.11.X:9 with XX:XX:XX:XX:XX:XX
192.168.11.X : OK

一回目の3発で起動しなかった場合は、もう3発繰り返して

それでも駄目な時のコマンド結果は↓のようになる

Sending magic packet to 192.168.11.X:9 with XX:XX:XX:XX:XX:XX
Sending magic packet to 192.168.11.X:9 with XX:XX:XX:XX:XX:XX
Sending magic packet to 192.168.11.X:9 with XX:XX:XX:XX:XX:XX
Sending magic packet to 192.168.11.X:9 with XX:XX:XX:XX:XX:XX
Sending magic packet to 192.168.11.X:9 with XX:XX:XX:XX:XX:XX
Sending magic packet to 192.168.11.X:9 with XX:XX:XX:XX:XX:XX
192.168.11.X : NG

VNCの設定

1.インストール及び初期設定

centossrv.com

2.クライアント側のTeraTermにポートフォワードの設定

f:id:hayato-ota-rf:20170921040202p:plain

3.VNC接続テスト

f:id:hayato-ota-rf:20170921040227p:plain

結果

Raspberry Piを使った検証なのに、全然IoT関係ないという

しかもVNCよりChrome リモートデスクトップの方が早いやんけ!

VNCェ・・・

Windows10 Proが欲しいです(^q^)

おまけ

自宅PCをスリープ放置してると、予期せぬスリープ解除問題に遭遇することがあります

その場合の解消方法はこちら

deaimobi.com

参考サイト

eng-entrance.com

inamuu.com

qiita.com

qiita.com

qiita.com

ryoichi0102.hatenablog.com

qiita.com

raptor-falcon.hatenablog.com

*1: COUNT + 1

Route53をなんちゃってダイナミックDNSに仕立てみた

  f:id:hayato-ota-rf:20170909203539p:plain

最近、SSL-VPNで使用しているEC2(Linux)にSSHにする際に、毎回変動したIP打ち込むのが怠いと感じてきた
けどON/OFF繰り返すからElastic IPは使えない
なんか良い方法ないかGoogle先生に聞いてみたところ
Route53をなんちゃってダイナミックDNSに仕立てあげる方法があったのでやってみた

構成

EC2が起動するタイミングで、Route53のレコードを更新するAPIを叩くcliスクリプトで実行させることによって、Route53をなんちゃってダイナミックDNSに仕立てあげる

※構築が終わった後で気が付いたんだけど、わざわざ自分でスプリクト作らなくても、route53ddnsといったスクリプトリポジトリにあったという

手順

ドメインの取得とゾーンの作成を既に完了している前提で進めます

①Route53のAPIを叩く用のユーザを作成

raptor-falcon.hatenablog.com

手順①を参考して下さい

今回設定したユーザは以下となります

ユーザ名:Route53

ポリシー:AmazonRoute53FullAccess

ポリシーは権限が必要最低限になるようにするのがスマートなんでしょうが・・・

 

f:id:hayato-ota-rf:20170907034814j:plain

AWS CLIで使うユーザの認証設定する

1.EC2上のLinuxサーバにログイン

 

2.認証情報の設定

aws configure --profile Route53

AWS Access Key ID [None]: XXXXXXXXXXXXXXXXXXXX 

AWS Secret Access Key [None]: XXXXXXXXXXXXXXXXXXXXXXX 

Default region name [None]: us-east-1

Default output format [None]:

3.設定の確認

aws configure list --profile Route53

シェルスクリプトおよび設定ファイルの作成と設定

1.作業ディレクトリを作成

mkdir /home/hayato/Route53

2.jsonファイルを作成

vi /home/hayato/Route53/dyndns.tmpl

{

     "Changes":

     [

          {

          "Action": "UPSERT",

          "ResourceRecordSet":

               {

               "Name": "{%HOST%}.raptor-aws.net.",

               "Type": "A",

               "TTL": 300,

               "ResourceRecords":

                    [

                         {

                         "Value": "{%IP%}"

                         }

                    ]

                }

           }

     ]

}

※パラメータ補足

・"Action": "UPSERT"

レコードに対して行うアクションを指定

UPSERT=更新  

CREATE=作成

DELETE=削除

・"Name": "{%HOST%}.raptor-aws.net."

FQDNを指定

・"Value": "{%IP%}"

IPを指定

 

3.シェルスクリプトを作成

vi /home/hayato/Route53/dyndns.sh

#!/bin/bash

 

#VariableDefine

PROFILE=Route53

ROUTE53_PATH=/home/hayato/Route53/

ZONEID=XXXXXXXXXXX

IP=$(curl -s http://169.254.169.254/latest/meta-data/public-ipv4)

HOSTNAME=$(hostname)

 

#filecreate

sed -e "s/{%IP%}/${IP}/g;s/{%HOST%}/${HOSTNAME}/g" ${ROUTE53_PATH}dyndns.tmpl > ${ROUTE53_PATH}${HOSTNAME}.json

 

#CLI

aws route53 change-resource-record-sets --profile ${PROFILE} --hosted-zone-id ${ZONEID} --change-batch file://${ROUTE53_PATH}${HOSTNAME}.json

※変数補足

・PROFILE

CLIで使用するプロファイルを指定

・ROUTE53_PATH

③の2で作成したjsonファイルがあるディレクトリを指定

・ZONEID

対象のゾーンIDを指定

f:id:hayato-ota-rf:20170907034825p:plain

・IP

EC2に割り当てられているパブリックIPを指定

・HOSTNAME

サーバ名を指定

④シェルスプリクトの動作確認と自動実行設定

1.シェルスプリクトの動作確認

sh /home/hayato/Route53/dyndns.sh

設定ファイル等に誤りがなければ、次のような結果が返ってきます

{

    "ChangeInfo": {

        "Status": "PENDING",

        "SubmittedAt": "2017-09-06T17:34:26.414Z",

        "Id": "/change/C21B4F9LM6BATC"

     }

}

しばらくするとRoute53のレコードが更新されます

 

2.シェルスプリクトの権限設定

sudo chmod 755 /home/hayato/Route53/dyndns.sh

3.cronの設定

cronの時間指定する部分に@rebootと指定してやると

サーバ起動時にスプリクトが実行されます

ただ今回何故かcrontab -eだと上手く設定されなかったので、cronファイルを直接編集しました

ルートに移行し、cronファイルを直接編集

su

 vi /var/spool/cron/hayato

cronファイルに下記の一文を追加

@reboot /home/hayato/Route53/dyndns.sh

結果

EC2のON/OFFを行っても、毎回同じFQDNsshが出来るようになりました

ちなみにオンプレのサーバとかでも可能なので、他のダイナミックDNSサービスの代用になるかもしれませんね

Route53はそんなに高くないし

参考サイト

blog.rocaz.net

www.mtcms.jp

qiita.com

インターネットVPN

f:id:hayato-ota-rf:20170909204209j:plain

いまや企業間通信になくてはならないVPN(Virtual Private Nework)ですが、その中でも安価で、個人でも使うことがあるインターネットVPNについてまとめました

VPNの種類

大きくわけて次の二つに分類されます

インターネットVPN

インターネットなどの公衆網を利用したVPNのことで、コストが低い反面、信頼性に乏しい面があります

便利な言葉、必殺ベストエフォート!!

またインターネットVPNにも使用するセキュリティプロトコルで次の二つに分類されます

IPsec-VPN

セキュリティプロトコルIPsecを使用

詳細は後程記載

SSL-VPN

セキュリティプロトコルSSLを使用

詳細は後程記載しない!!

機会があれば、また日記で書こうと思います

IP-VPN

キャリアが提供する閉鎖網を利用したVPNのことで、コストがク○高い分、信頼性が高いといった特徴があります

キャリアの網内で障害が起きた時は、猛烈電凸賠償請求GO!!

またIP-VPNにも、キャリアの閉鎖網L3orL2どちらを使用するかで次の二つに分類されます

IP-VPN(MPLS-VPN

キャリアのL3閉鎖網を使用するタイプ

拠点間ルーティングをキャリアにお任せするので手軽な反面、拠点間ルーティングで使用できるプロトコルに制限があり、カスタマイズ性に乏しい面があります

ちなみにIP-VPNを実現する為に使用されるプロトコルはMPLS( Multi-Protocol Label Switching )です

ネスペの午前試験でラベルって文言出てきたら、MPLSが含まれる選択肢を選らんどけば、大体正解します(笑)

仕組みの詳細は機会があれば、また日記で書こうと思います

広域イーサネット

キャリアのL2閉鎖網を使用するタイプ

拠点間ルーティングも自分たちでする必要があるので面倒な反面、拠点間ルーティングで多様なプロトコルを使用でき、カスタマイズ性が高いといった特徴があります

なんか広域イーサネットって響きがカッコイイと思えるのは俺だけなのだろうか(笑)

ちなみに広域イーサネットを実現する為に使用されるプロトコルIEEE802.1Qトンネリングです

仕組みの詳細は機会があれば、また日記で書こうと思います

インターネットVPNのタイプ

 大きくわけて次の二つに分類されます

サイト間VPN

VPNを実装したルータ同士を接続する構成

企業の拠点間を接続する時に使用します

リモートアクセスVPN

VPNを実装したルータとVPNクライアントソフトをインストールしたPCとを接続する構成

外出先のノートPCからイントラネットにアクセスする時などは、このタイプを使用します

 

f:id:hayato-ota-rf:20170905061443g:plain

VPNにおけるトンネリングと暗号化

VPNはトンネリングと暗号化によって実現されています

トンネリングを行えるプロトコルにはPPTP、L2F、L2TPIPsecGRE などがあります

一方、これらのうち暗号化を行えるプロトコルIPsecだけとなります

じゃあもうIPsecだけでよくね?って思っちゃうんですが、例えば拠点間でOSPFを使用したい時とかに、IPsecではそれが不可能です

何故かというと、OPSFはリンクステート情報の交換にマルチキャストを使用するのは皆さんご存知だと思います

しかし、IPsecマルチキャスト伝送が行えません

なので、IPsecを使いたいけどルーティングプロトコルにOSPFを使いたい場合は、トンネリングはGRE、暗号化はIPsecで行うGRE over IPsec等を使用する必要があります

f:id:hayato-ota-rf:20170905061458j:plain

 

f:id:hayato-ota-rf:20170905061505g:plain

IPsecを構成する2つのプロトコルと鍵交換のプロトコル

IPsecはAH、ESP、IKEなどの複数のプロトコルから構成されています

・AH(Authentication Heade)は改ざん防止

・ESP(Encapsulated Security Payload)はペイロード部に対して暗号化

・IKE(Internet Key Exchage)鍵交換

実はESPは改ざん防止機能も持っていて、ESP+IKEだけでもIPsecは成り立ちます

なのにAHを実装させることがある理由は以下になります

・ESPはIPヘッダの部分までは完全性を保証できない

・AHはESPより負荷がかからない

・AHに輸出規制がない

・AHはIPv6では必須

現在の日本におけるIPsec-VPNといえば、AHを使用しない「ESPとIKE」だけによるIPsec-VPNが一般的な実装方式らしいです

IPsecの通信モード

IPsecにおける通信モードには、トランスポートモードとトンネルモードの2つのモードがあります

f:id:hayato-ota-rf:20170905061513j:plain

 

f:id:hayato-ota-rf:20170905061520g:plain

トランスポートモードとトンネルモードの使い分け

トンネリングと暗号化両方をIPsecで行う場合はトンネルモードを使用

トンネリングはGREやLT2Pで暗号化はIPsecで行う場合はトランスポートモードを使用

何故かというと、既にGREやLT2Pでトンネリング行われているのに、IPsecでトンネリングを行うのは無駄だからです

トランスポートモードとトンネルモードのESPパケット

ちなみにESPの暗号化範囲はネスペ午前と午後両方でよく出題されます

f:id:hayato-ota-rf:20170905061529g:plain

SA ( Security Association )

VPNゲートウェイ間で確立されたコネクションのことを、IPsecではSAと呼びます

IPsecの全ての通信はこのSAを使用します

SAは一方通行のトンネルであるため、パケットを送受信するためには送信用のSA、受信用のSAの合計2つが必要になります

また、SAはIPsecカプセル化プロトコルに対して独自のものになることから、例えば

AHのパケットとESPのパケットの両方を利用して相互にIPsec通信する場合、計4つのSAが必要となります

f:id:hayato-ota-rf:20170905061539g:plain

 

このようにIPsec機器の間には数多くのSAが発生することになりるので、VPNゲートウェイIPsecのパケットがどのSAのものなのかを判断する必要があります

その判断はAHやESPパケットフィールドの SPI の値を元に行っています

f:id:hayato-ota-rf:20170905061545g:plain

 

f:id:hayato-ota-rf:20170905061551g:plain

 

ネスペの午後Ⅱで、SPIのビット長を答える問題があったんですが、おもわず「そんなん分かるか!」ってツッコミいれてしまいました(笑)

ちなみにSPIは32ビット長です

IKE( Internet Key Exchange )

IPsecの通信を始めるにあたり、SAを確立する必要があるのは分かったと思います

そのSAを自動的に生成、管理、更新するのがIKEです

IKEによるSAの生成はフェーズ1とフェーズ2のステップがあります

フェーズ1

各種パラメータを交換しISAKMP SAを生成します

f:id:hayato-ota-rf:20170905061603g:plain

フェーズ1には二つのモードがあります

メインモード

IPsecルータの両端が固定IPの場合使用

アグレッシブモード

IPsecルータの両端が動的IPの場合使用

フェーズ2

ISAKMP SA上で各種パラメータを交換してIPsec SAを生成します

f:id:hayato-ota-rf:20170905061610g:plain

パラメータ補足

ライフタイム

これが0になるとSAが消滅するので、SAの再作成が必要になります

SAの再作成処理のことをリキー(ReKey)と呼びます

このリキーが解答の問がネスペの午後Ⅱで出てきました

「そんなの分かるry」

IPパケットの断片化(フラグメンテーション)

IPパケットのMTUが1500バイトであることは皆さんご存知だと思います

IPsec環境ではIPパケットのサイズが1500を超えてしまい、IPパケットの断片化が発生することがあります

何故かというと、IPsecではカプセル化の際に様々なヘッダーを元のIPパケットに付与する必要があり、それによりIPパケットのサイズが増えてしまうからです

断片化が起きると、通信効率が悪化したり、VPNが正常に行われない可能性があります

IPsecによるIPパケットの断片化を防ぐ為には、PCやサーバのインターフェースのMTUをカプセル化によるオーバヘッドを見越して設定する必要があります(あんま現実的では無い気がするけど)

VPNが正常に行われない可能性がある理由

ルータによっては、IPフラグメントパケットを遮断する設定がONになっていることがあるフラグメント化されたパケットを利用した攻撃を防ぐ為のものらしいですが、IPsec使用環境ではOFFにするのが一般的らしいです

参考サイト

www.infraexpert.com

www.infraexpert.com

www.infraexpert.com

www.ntt.com

 

ステルスSSID&MACアドレスフィルタ意味なくね?

f:id:hayato-ota-rf:20170909201412j:plain

最近ネスペの勉強のお陰で、色々発見がががが

もうネスペ落ちてもいいry( ‘д‘⊂彡☆))Д´) パーン

SSIDのステルス機能&MACアドレスフィルターはあまり意味がないとかなんとかって聞いたことあるし、ネスペ本にも書いてたから具体的になんで?って気になったから

鮫さんにまたお世話になってみた

前準備

無線APのビーコンをキャプチャする為には、無線LANインターフェースをモニターモードにする必要があります

itbouzy.site

検証

まずはステルスSSID機能を無効にして、パケットキャプチャ

※キャプチャ画面にスタンド的な透明ウインドウが見えるけど、気にしないでね

SSID:hayatoWi-Fi5GHz

っていうビーコンが垂れ流しになっているのが分かると思います

f:id:hayato-ota-rf:20170904064939p:plain

f:id:hayato-ota-rf:20170904064950p:plain

次にステルスSSID機能を有効にして、パケットキャプチャ

ステルスSSID機能を有効にすると、APがビーコンを出さなくなるのかなって思ってたら、私のBUFFALOちゃんはSSID機能を有効にしても垂れ流してました

機器によりけりなんですかね?

しかし先程と違い、SSIDのところが暗号化的ことになってます

f:id:hayato-ota-rf:20170904065040p:plain

Ω ←BUFFALOちゃん<漏らしたの僕じゃないからあああああ

↑いやMACアドレスでバレとるけどな

SSID見えないんなら安全じゃね?って思ったそこのあなた!

SSIDを知っているユーザがある端末で、手打ちでAPに接続したとします

今回は私のiphoneで手打ちでSSIDを入力しました

そうするとなんということでしょう!

SSID丸見えでしたm9(^Д^)プギャー!!www

SSIDがさっきと若干違うのは、ステルスSSID機能有効にしたらSSIDがクリアされたから、ついでにちょっとスペル変えたからなんで、気にしないでね

f:id:hayato-ota-rf:20170904065056p:plain

通信している正規のユーザ端末のMACアドレスも丸見えだから、そのMACアドレスを偽造先として使われると、MACアドレスフィルターも意味ないんじゃあああm9(^Д^)プギャー!!www

f:id:hayato-ota-rf:20170904065106p:plain

何故このような現象が起きるのか?

それはSSIDMACアドレスを暗号化してしまうと、APとクライアント共に、は?(´△`)ってなるからです

今回だとAPからのビーコンは暗号化的なことをしてるので、クライアントはそのビーコンを受信してもSSID が理解できないので、Wi-Fiの設定画面に何も表示されません

ステルス化されたAPに接続する時には、クライアントがSSID を入れたブロードキャストを行い、APは自分のSSIDと一致するブロードキャストフレームだった場合それを受信し、通信開始します

その時、SSIDMACアドレスを暗号化して上記のことを行なってしまうと、APはお前誰よ?てか誰に向かって話してんの?ってな感じで、通信が成立しません

こればかりは、仕様上仕方がないようなので、他の面でセキュリティを向上させる必要がありそうです

結果

PSK(事前共通キー)は、漏らさないようにね!定期的に変えたほうがいいかもね!

無線の暗号方式をAESにする為にも、認証方式はWPA2を使おうね!

いよいよ心配なら、WPA2エンタープライズを使うのもありかもだけど、面倒だよね!

ステルスSSIDMACアドレスフィルター・・・

m9(^Д^)プギャー!!