AWSにGNS3サーバを立ててみた
CCNPの勉強の為にNWの検証ツールとしてGNS3を使いたいから、その設定方法をメモがてらアゲ
GNS3の環境
①クライアントOSでローカルサーバとして動かす
②サーバOSでリモートサーバとして動かす
③クライアントOSのVM上でローカルサーバorリモートサーバとして動かす
④GNS3専用クラウド?でリモートサーバとして動かす(名前忘れた)
多分この中で一般的なのは③ですが、今回は②でいこうと思います。
※自宅PCをリモート起動できるようになったら、自宅PCのVM上でリモートサーバとして動かしてみようかな?スペック的に自宅PC強いし
けど借りてたラズパイを返却しちゃったから、自宅PCをリモート起動できんのや\(^o^)/
設定手順
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先生に聞いて下さい
※ヒント
クライアント側GNS3の設定
↑のサイト参考にして貰えば、大体上手く行きます
GNS3のバージョンや形態によって若干設定方法に違いがあるので、その点を補足
今回使用しているGNS3のバージョンは2.0.3です
・サーバの指定
1.Edit→Preferences→Server→Main server
2.Enable local serverのチェックを外す
3.HostにGNS3サーバのIPを指定
※ローカルサーバとリモートサーバを兼用したい場合はこの限りではありません
・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を選択
・Cisco IOU / IOL – ライセンスキーのアップロード
1.メモ帳を起動
2.以下の形式で入力し、ファイル名:iourc.txtで保存
AAA
→GNS3サーバのホスト名
BBBBBBBBBBBB
→発行したライセンスキー
[license]
AAA = BBBBBBBBBBBB;
3.Edit→Preferences→IOS on UNIX
4.Browse...から2.で作成したテキストファイルを指定
結果
これでCCNP勝つるお(^ω^≡^ω^)
補足
バグメモ
・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に通知してみた
AWS上のEC2を一定時間操作しなかったら、EC2を自動停止するような運用をしているんですが、CloudWatchのアラーム状態がアラートのままだと正常に自動停止してくれません
頻発する事象ではなかったので放置かましてましたが、今日AWSにログインしたらEC2が三日間稼働しっぱなしでした・・・ont
CloudWatchのアラーム状態がアラート⇒OKになる条件が、EC2を起動したあとのログインなので(ActiveSessionsを監視している為)
EC2を起動するだけしてログインせず放置すると、今回のような事象が発生します
なんで、正常に自動停止してくれなかった時に気が付けるように、EC2の連続稼働時間が12時間and24時間を超えた時にLINEに通知させるようにします
参考手順
手順
カスタムメトリクスの設定(Windows)
※参考手順と被っている個所は省きます
①Systems Manager Run Commandに設定してある、JSONファイルの編集
1.EC2 コンソールのステートマネージャー→既存の設定をチェック→アクション→関連付けの編集
2.パラメータのPropertiesをJSON形式で編集し→関連付けの編集
※JSON
{
"IsEnabled":true,
"EngineConfiguration": {
"PollInterval": "00:00:15",
"Components": [
{
"Id": "ApplicationEventLog",
"FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,
"Parameters": {
"LogName": "Application",
"Levels": "1"
}
},
{
"Id": "SystemEventLog",
"FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,
"Parameters": {
"LogName": "System",
"Levels": "7"
}
},
{
"Id": "SecurityEventLog",
"FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,
"Parameters": {
"LogName": "Security",
"Levels": "7"
}
},
{
"Id": "ETW",
"FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,
"Parameters": {
"LogName": "Microsoft-Windows-WinINet/Analytic",
"Levels": "7"
}
},
{
"Id": "IISLogs",
"FullName": "AWS.EC2.Windows.CloudWatch.CustomLog.CustomLogInputComponent,
"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,
"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,
"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,
"Parameters": {
"AccessKey": "",
"SecretKey": "",
"Region": "us-east-1",
"LogGroup": "Default-Log-Group",
"LogStream": "{instance_id}"
}
},
{
"Id": "CloudWatch",
"FullName": "AWS.EC2.Windows.CloudWatch.CloudWatch.CloudWatchOutputComponent,
"Parameters": {
"AccessKey": "",
"SecretKey": "",
"Region": "us-east-1",
"NameSpace": "Windows"
}
}
],
"Flows": {
"Flows":
[
"(ApplicationEventLog,SystemEventLog),CloudWatchLogs",
"(PerformanceCounterActiveSessions),CloudWatch",
===================今回追記した部分===================
"(PerformanceCounterSystemUpTime),CloudWatch"
================================================
]
}
}
}
②カスタムメトリクスが取得できているか確認
カスタムメトリクスの設定(Linux)
※参考手順と被っている個所は省きます
①カスタムメトリクス送信用スクリプトを編集
#!/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コマンドに渡して、一番目のフィールドだけが出力されるようにしている
②カスタムメトリクスが取得できているか確認
LINEへの通知設定
※参考手順と被っている個所は省きます
①CloudWatchの設定
カスタムメトリクスで起動してからの時間を秒数でカウントしているので、秒数が一定数を超えたらアラームが警告になるよう設定
※12時間=43200秒
24時間=86400秒
②Lambdaの設定
1.Lambdaコンソールのダッシュボード→関数の作成
2.一から作成
3.各パラメータを設定→関数の作成
4.各パラメータを設定→モジュールとコードを含んだZIPファイルをアップロード
※コード
#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.トリガータブ→トリガーを追加
6.各パラメータを指定→送信
7.テストイベントの設定
8.各パラメータを指定→作成
9.テスト
10.実行結果が成功で、LINEに通知が届けばOK
LINE通知例
まとめ
EC2の連続稼働時間程度なら、標準メトリクスとしてAWSが用意してくれてもいいような・・・
AWS VPCと自宅LANをVPN接続してみた
構成図
AWS側の設定
①仮想プライベートゲートウェイの設定
1.VPCコンソールで、仮想プライベートゲートウェイの作成をクリック
2.、各パラメータを設定し、仮想プライベートゲートウェイの作成をクリック
②カスタマーゲートウェイの設定
1.VPCコンソールで、カスタマーゲートウェイの作成をクリック
2.各パラメータを設定し、カスタマーゲートウェイの作成をクリック
③VPN接続の設定
2.各パラメータを設定し、VPN接続の作成をクリック
④VPCルートテーブルの設定
1.宛先が自宅LANのIP(172.16.1.0/24)は、①で作成した仮想プライベートゲートウェイに向くように設定
自宅側の設定
私はYAMAHAやCiscoルータを持っていないので、ホスト型VMwereを利用し仮想NW上にVyOSを構築します
今回は検証なので良いのですが、実際に運用するとなると物理マシンにVyOSを導入したものを使用するか、YAMAHAやCiscoルータを使用する必要がありそうですね
仮想NW構成図
①仮想マシンの設定
1.ISOのダウンロード
↓のサイトからISOをダウンロード
2.仮想マシンの作成
詳細はVMwereでググって下さい
3.VyOSの仮想NIC設定
②NATルータの設定
1.VyOSのeth0のIPを固定
DHCP側で固定させます
※先にVyOS側のDHCP有効にしてないと、一覧に表示されないかもです
2.ポートフォワードの設定
VyOSのeth0に4500と500のUDPが転送されるように設定
何故4500と500のUDPなのかはNATトラバーサルを参照
③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”
6.タイムゾーンの設定
正常な時刻か確認
$ 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のダウンロード
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
④CentOSの設定
eth0のIPは172.16.1.2に設定
デフォルトゲートウェイは172.16.1.1に設定
DNSは192.168.11.1に設定
正常性の確認
①VPNステータスがアップになっているか確認
正しく設定できていれば、ステータスがアップになる
②AWSのEC2からVMnet上のCentOSにプライベートIPでPing疎通確認
EC2側の様子
CentOS側の様子
結果
自宅であっても割りと簡単にAWS VPCとVPN張れるようですね
ただAWS VPNは接続時間毎の課金&自宅ルータの固定IPが必要になってくるので、家庭レベルで実用的かどうかといわれると・・・
おまけ
NATトラバーサル
詳しくは↓のリンクを見て下さい
簡単に説明すると、IPsecは通常だとNAPTを超えることができません
それを可能にするのがNATトラバーサルです
なんでIPsecは通常だとNAPTを超えることができないかというと
まず前提としてNAPTって何と何を変換してるでしたっけ?
送信元IPと送信元ポート番号でしたね
でわ↓のIPsecのパケット構造を見て下さい
NW詳しい方ならもうお分かりですよね
そうIPsecはTCP/UDPヘッダを暗号化範囲に含んでいるので、パケットを受け取ったNAPTは( ゚Д゚)ハァ?ってなってしまうんですね
そうならないようにNATトラバーサルでは、暗号化した後のIPsecパケットにUDPヘッダを新たに付与します
その付与するUDP番号が、4500(IPsec NAT-T)と500(IKE)なんで②の2では、4500と500のUDPをポートフォワーディングさせたんです
参考サイト
Raspberry Piを使って自宅PCをリモート起動してみた
外出先で何か検証を行う時、簡単ものであればクラウドとかVPSで事足りるんだけど、それなりのスペックが必要な検証はちょっとしんどい・・・
その点、自宅PCのスペックはというと
私の用途では結構なオーバスペックなPCちゃんなので、こいつを使わないのは勿体無いよね!
けど、電源ユミットが750Wもあるので常時つけっぱだと電気代がががが
あんまりパーツに負荷も掛けたくないし・・・
色々ググったりした結果、Wake on LANといったリモート起動を可能にする技術があるみたいなので、レッツトライ!
要件
・外出先から自宅PCをリモート起動
・外出先から自宅PCをリモート操作
・出来る範囲でセキュリティは高めに
設計
リモート起動方法
・アクセスルータに外部からWebログインし、そこからマジックパケットを送信
セキュリティ的に却下
セキュリティ的に却下
・Raspberry PiにSSHし、そこからマジックパケットを送信
ラズパイなら電気代しれてるし、一回SSHを挟むからセキュリティもなんぼか高いと思うので、この方法を採用
アクセスルータのグローバルIPの特定方法
・固定IP取得
月額1000円もするから却下
・アクセスルータ指定のダイナミックDNSを使用
いずれも有料なので、却下
DynDNSは昔は無料だったらしいです・・・
・Route53を使用
ホストゾーンと独自ドメインを持っているので、使わないともったいない!
なのでこの方法を採用
Raspberry PiにSSHする方法
これが一番手っ取り早い
リモート操作方法
・Raspberry PiにSSHポートフォワードさせてSSL-VPN確立後、RDP
クライアント側に特定のソフトを入れる必要もないし、レスポンスも一番良いと思うので、この方法を採用したかったんですが
Windows10 HomeはRDPサーバになることができないだと・・・
初めて知ったわ
Gitに海賊版RDPサーバソフトみたいなのもあったけど、WindowsUpdateのせいで今は使えないみたい
まあ使えたとしてもバックドアとか仕込まれてても文句言えないから、セキュリティ的にあれだけど
Proへのアップグレードには13824円もかかるし・・・
・Chrome リモートデスクトップやTeam Viewer等の、一旦別NW経由してリモートアクセスするソフトを使用
せっかくRaspberry PiにSSHまでしてるのに、この方法を使用するのはなんだかな・・・
・Raspberry PiにSSHポートフォワードさせてSSL-VPN確立後、VNC
大学のサーバ構築の授業で使ってたから、その名残でこの方法を採用
構成図
構築手順
①Raspberry Piの初期設定
今使ってるRaspberry Pi借り物だから、初期設定済んでるんだよね~
ここの手順は自分の買った時に、追記します
↓はメモ
SSH用ユーザを作成
sudo adduser hayato
※useraddではホームディレクトリが作成されない
sudo グループに追加
sudo gpasswd -a hayato sudo
②Raspberry PiとRoute53の連携
1.Raspberry Piにログイン
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
・ZONEID
対象のゾーンIDを指定
・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
動作確認の為、1分毎実行にしてからログ確認しといたほうがいいかも
*/1 * * * * /home/hayato/Route53/dyndns.sh
正常に動作している場合は下記のようなログが出力されます
正常動作を確認できたら、動作確認用のcronは削除しときましょう
③アクセスルータのポートフォワード設定
アクセスルータのベンダや型番によって設定画面が違うと思うので、下記の手順は参考程度と捉えて下さい
1.Raspberry Piと自宅PCのIPを固定
ホストに直接設定してもいいけど、DHCPで固定したほうが楽な気がする
2.IPv6が有効になっていないか確認
IPv6接続サービスが有効になってると、どうあがいてもアクセスルータのWAN側に到達できません
私はここで○そハマリました
3.ポートフォワードの設定
BUFFALOのアクセスルータだと、ポート変換といった名前みたいです
念の為、WAN側のポートは22番以外にしといた方が良いと思います
まあ鍵認証使うのであれば問題はないんですが、BOTのブルードフォースアタックがなんとなく気に入らないので私は変えときました(笑)
4.外部からRaspberry PiにSSH出来るか確認
今回はAWSのLinuxサーバからRaspberry Piにアクセスしてみます
④SSHのセキュリティ設定
1.SSH鍵認証設定
2.SSHのパスワード認証禁止設定
PasswordAuthentication yes → PasswordAuthentication no に変更
SSHの設定を反映
service ssh restart
⑤Wake on LANの設定(Windows10)
Wake on LANはOSやデバイスの相性によって、どうあがいても上手くいかないことがあります
ちなみに私はスリープからの復帰しか無理でした(笑)
まあスリープ状態を復帰させてリモートログインできるなら、まあよしとしましょう
1.ネットワークアダプタの設定
デバイスマネージャから使用してるNICドライバーのプロパティを開いて、↓の画像のように設定されているか確認
2.電源設定
コントロールパネル→電源オプションの左ペインにある電源ボタンの動作設定を選択をクリックし、高速スタートアップのチェックを外す
私はスリープからの復帰しか無理だったので、チェック入れたままにしています
3.BIOSの設定
BIOSの設定はベンダとバージョンによって設定項目がまちまちなので、自分が使っているBIOSに合う設定を頑張って見つけて下さい(笑)
例↓
⑥マジックパケット送信スプリクト作成
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.インストール及び初期設定
2.クライアント側のTeraTermにポートフォワードの設定
3.VNC接続テスト
結果
Raspberry Piを使った検証なのに、全然IoT関係ないという
しかもVNCよりChrome リモートデスクトップの方が早いやんけ!
VNCェ・・・
Windows10 Proが欲しいです(^q^)
おまけ
自宅PCをスリープ放置してると、予期せぬスリープ解除問題に遭遇することがあります
その場合の解消方法はこちら
参考サイト
*1: COUNT + 1
Route53をなんちゃってダイナミックDNSに仕立てみた
最近、SSL-VPNで使用しているEC2(Linux)にSSHにする際に、毎回変動したIP打ち込むのが怠いと感じてきた
けどON/OFF繰り返すからElastic IPは使えない
なんか良い方法ないかGoogle先生に聞いてみたところ
Route53をなんちゃってダイナミックDNSに仕立てあげる方法があったのでやってみた
構成
EC2が起動するタイミングで、Route53のレコードを更新するAPIを叩くcliをスクリプトで実行させることによって、Route53をなんちゃってダイナミックDNSに仕立てあげる
※構築が終わった後で気が付いたんだけど、わざわざ自分でスプリクト作らなくても、route53ddnsといったスクリプトがリポジトリにあったという
手順
ドメインの取得とゾーンの作成を既に完了している前提で進めます
①Route53のAPIを叩く用のユーザを作成
手順①を参考して下さい
今回設定したユーザは以下となります
ユーザ名:Route53
ポリシー:AmazonRoute53FullAccess
ポリシーは権限が必要最低限になるようにするのがスマートなんでしょうが・・・
②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
・ZONEID
対象のゾーンIDを指定
・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ファイルに下記の一文を追加
結果
EC2のON/OFFを行っても、毎回同じFQDNでsshが出来るようになりました
ちなみにオンプレのサーバとかでも可能なので、他のダイナミックDNSサービスの代用になるかもしれませんね
Route53はそんなに高くないし
参考サイト
インターネットVPN
いまや企業間通信になくてはならないVPN(Virtual Private Nework)ですが、その中でも安価で、個人でも使うことがあるインターネットVPNについてまとめました
- VPNの種類
- インターネットVPNのタイプ
- VPNにおけるトンネリングと暗号化
- IPsecを構成する2つのプロトコルと鍵交換のプロトコル
- IPsecの通信モード
- SA ( Security Association )
- IKE( Internet Key Exchange )
- IPパケットの断片化(フラグメンテーション)
- 参考サイト
VPNの種類
大きくわけて次の二つに分類されます
インターネットVPN
インターネットなどの公衆網を利用したVPNのことで、コストが低い反面、信頼性に乏しい面があります
便利な言葉、必殺ベストエフォート!!
またインターネットVPNにも使用するセキュリティプロトコルで次の二つに分類されます
詳細は後程記載
詳細は後程記載しない!!
機会があれば、また日記で書こうと思います
IP-VPN
キャリアが提供する閉鎖網を利用したVPNのことで、コストがク○高い分、信頼性が高いといった特徴があります
キャリアの網内で障害が起きた時は、猛烈電凸賠償請求GO!!
またIP-VPNにも、キャリアの閉鎖網L3orL2どちらを使用するかで次の二つに分類されます
キャリアのL3閉鎖網を使用するタイプ
拠点間ルーティングをキャリアにお任せするので手軽な反面、拠点間ルーティングで使用できるプロトコルに制限があり、カスタマイズ性に乏しい面があります
ちなみにIP-VPNを実現する為に使用されるプロトコルはMPLS( Multi-Protocol Label Switching )です
ネスペの午前試験でラベルって文言出てきたら、MPLSが含まれる選択肢を選らんどけば、大体正解します(笑)
仕組みの詳細は機会があれば、また日記で書こうと思います
広域イーサネット
キャリアのL2閉鎖網を使用するタイプ
拠点間ルーティングも自分たちでする必要があるので面倒な反面、拠点間ルーティングで多様なプロトコルを使用でき、カスタマイズ性が高いといった特徴があります
なんか広域イーサネットって響きがカッコイイと思えるのは俺だけなのだろうか(笑)
ちなみに広域イーサネットを実現する為に使用されるプロトコルはIEEE802.1Qトンネリングです
仕組みの詳細は機会があれば、また日記で書こうと思います
インターネットVPNのタイプ
大きくわけて次の二つに分類されます
サイト間VPN
VPNを実装したルータ同士を接続する構成
企業の拠点間を接続する時に使用します
リモートアクセスVPN
VPNを実装したルータとVPNクライアントソフトをインストールしたPCとを接続する構成
外出先のノートPCからイントラネットにアクセスする時などは、このタイプを使用します
VPNにおけるトンネリングと暗号化
VPNはトンネリングと暗号化によって実現されています
トンネリングを行えるプロトコルにはPPTP、L2F、L2TP、IPsec、GRE などがあります
一方、これらのうち暗号化を行えるプロトコルはIPsecだけとなります
じゃあもうIPsecだけでよくね?って思っちゃうんですが、例えば拠点間でOSPFを使用したい時とかに、IPsecではそれが不可能です
何故かというと、OPSFはリンクステート情報の交換にマルチキャストを使用するのは皆さんご存知だと思います
なので、IPsecを使いたいけどルーティングプロトコルにOSPFを使いたい場合は、トンネリングはGRE、暗号化はIPsecで行うGRE over IPsec等を使用する必要があります
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つのモードがあります
トランスポートモードとトンネルモードの使い分け
トンネリングと暗号化両方をIPsecで行う場合はトンネルモードを使用
トンネリングはGREやLT2Pで暗号化はIPsecで行う場合はトランスポートモードを使用
何故かというと、既にGREやLT2Pでトンネリング行われているのに、IPsecでトンネリングを行うのは無駄だからです
トランスポートモードとトンネルモードのESPパケット
ちなみにESPの暗号化範囲はネスペ午前と午後両方でよく出題されます
SA ( Security Association )
VPNゲートウェイ間で確立されたコネクションのことを、IPsecではSAと呼びます
IPsecの全ての通信はこのSAを使用します
SAは一方通行のトンネルであるため、パケットを送受信するためには送信用のSA、受信用のSAの合計2つが必要になります
また、SAはIPsecのカプセル化プロトコルに対して独自のものになることから、例えば
AHのパケットとESPのパケットの両方を利用して相互にIPsec通信する場合、計4つのSAが必要となります
このようにIPsec機器の間には数多くのSAが発生することになりるので、VPNゲートウェイはIPsecのパケットがどのSAのものなのかを判断する必要があります
その判断はAHやESPパケットフィールドの SPI の値を元に行っています
ネスペの午後Ⅱで、SPIのビット長を答える問題があったんですが、おもわず「そんなん分かるか!」ってツッコミいれてしまいました(笑)
ちなみにSPIは32ビット長です
IKE( Internet Key Exchange )
IPsecの通信を始めるにあたり、SAを確立する必要があるのは分かったと思います
そのSAを自動的に生成、管理、更新するのがIKEです
IKEによるSAの生成はフェーズ1とフェーズ2のステップがあります
フェーズ1
各種パラメータを交換しISAKMP SAを生成します
フェーズ1には二つのモードがあります
メインモード
IPsecルータの両端が固定IPの場合使用
アグレッシブモード
IPsecルータの両端が動的IPの場合使用
フェーズ2
ISAKMP SA上で各種パラメータを交換してIPsec SAを生成します
パラメータ補足
ライフタイム
これが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にするのが一般的らしいです
参考サイト
ステルスSSID&MACアドレスフィルタ意味なくね?
最近ネスペの勉強のお陰で、色々発見がががが
もうネスペ落ちてもいいry( ‘д‘⊂彡☆))Д´) パーン
SSIDのステルス機能&MACアドレスフィルターはあまり意味がないとかなんとかって聞いたことあるし、ネスペ本にも書いてたから具体的になんで?って気になったから
鮫さんにまたお世話になってみた
前準備
無線APのビーコンをキャプチャする為には、無線LANインターフェースをモニターモードにする必要があります
検証
まずはステルスSSID機能を無効にして、パケットキャプチャ
※キャプチャ画面にスタンド的な透明ウインドウが見えるけど、気にしないでね
SSID:hayatoWi-Fi5GHz
っていうビーコンが垂れ流しになっているのが分かると思います
次にステルスSSID機能を有効にして、パケットキャプチャ
ステルスSSID機能を有効にすると、APがビーコンを出さなくなるのかなって思ってたら、私のBUFFALOちゃんはSSID機能を有効にしても垂れ流してました
機器によりけりなんですかね?
しかし先程と違い、SSIDのところが暗号化的ことになってます
Ω ←BUFFALOちゃん<漏らしたの僕じゃないからあああああ
↑いやMACアドレスでバレとるけどな
SSID見えないんなら安全じゃね?って思ったそこのあなた!
SSIDを知っているユーザがある端末で、手打ちでAPに接続したとします
そうするとなんということでしょう!
SSID丸見えでしたm9(^Д^)プギャー!!www
※SSIDがさっきと若干違うのは、ステルスSSID機能有効にしたらSSIDがクリアされたから、ついでにちょっとスペル変えたからなんで、気にしないでね
通信している正規のユーザ端末のMACアドレスも丸見えだから、そのMACアドレスを偽造先として使われると、MACアドレスフィルターも意味ないんじゃあああm9(^Д^)プギャー!!www
何故このような現象が起きるのか?
それはSSIDとMACアドレスを暗号化してしまうと、APとクライアント共に、は?(´△`)ってなるからです
今回だとAPからのビーコンは暗号化的なことをしてるので、クライアントはそのビーコンを受信してもSSID が理解できないので、Wi-Fiの設定画面に何も表示されません
ステルス化されたAPに接続する時には、クライアントがSSID を入れたブロードキャストを行い、APは自分のSSIDと一致するブロードキャストフレームだった場合それを受信し、通信開始します
その時、SSIDとMACアドレスを暗号化して上記のことを行なってしまうと、APはお前誰よ?てか誰に向かって話してんの?ってな感じで、通信が成立しません
こればかりは、仕様上仕方がないようなので、他の面でセキュリティを向上させる必要がありそうです
結果
PSK(事前共通キー)は、漏らさないようにね!定期的に変えたほうがいいかもね!
無線の暗号方式をAESにする為にも、認証方式はWPA2を使おうね!
いよいよ心配なら、WPA2エンタープライズを使うのもありかもだけど、面倒だよね!
m9(^Д^)プギャー!!