はじめに

**CCNA（Cisco Certified Network Associate）**は、Cisco社が認定するネットワーク技術の登竜門的な資格です。OSI参照モデル・IPアドレッシング・ルーティング・スイッチングなど、ネットワークエンジニアとして働く上での基礎知識を幅広く問われるため、インフラエンジニアやネットワークエンジニアを目指す人の定番資格になっています。

出題範囲が広く、実機やシミュレータでの操作イメージも必要なため、テキストだけの独学だと挫折しやすいのも事実です。多くの合格者がUdemyの動画講座を併用しており、当ブログでも実際に受講者数・評価を確認した上で講座を比較します。

この記事で分かること

• 「1本で体系的に学ぶ」か「模擬試験で仕上げる」かの選び方
• 各講座の評価・受講者数・ボリュームから見た信頼度
• 書籍（白本・黒本）との組み合わせ方

講座比較表

※価格はUdemyの頻繁なセール（月2〜3回、大幅割引になることが多い）により変動します。リンク先で最新価格をご確認ください。

1本で体系的に学びたい人向け

【ウズカレ式】『CCNA最短合格講義』の著者直伝！1週間でネットワークの基本知識が全て学べる講座＜CCNA試験完全対応＞

👉 講座の詳細を見る（Udemyで確認）

41時間7分・254講義という圧倒的なボリュームで、OSI参照モデル・TCP/IP・サブネット計算・ルーティングプロトコル・VLAN・ACL・NAT・無線LAN・ネットワーク自動化まで、CCNA試験範囲を体系的にカバーする講座です。受講者数31,279人・レビュー4,850件は、この分野では特に実績の多い講座です。

メリット

• 受講者数・レビュー数が圧倒的に多く、「多くの合格者に選ばれている」実績が数字で裏付けられている
• 出版されている書籍「CCNA最短合格講義」の著者本人による解説のため、書籍と組み合わせて使うと理解が深まりやすい
• ネットワーク自動化など最新の出題範囲まで含めて網羅している

正直なデメリット

• 41時間超という学習時間は長く、仕事をしながらの学習だと消化に1〜2ヶ月かかることも珍しくない
• ボリュームが多い分、「今すぐ試験だけ突破したい」という人には冗長に感じる部分もある

こんな人におすすめ：ネットワークの前提知識がなく、体系的に理解した上で合格したい人。初めての1本として何を選ぶか迷ったら、実績の多さで安心感のあるこの講座から始めるのが無難です。

📊 講座比較表に戻る ↑

仕上げの問題演習をしたい人向け

【2026年更新】v1.1対応！200-301 Cisco CCNA 模擬問題集

👉 講座の詳細を見る（Udemyで確認）

322問・3回分の模擬試験に特化した講座です。単一選択・複数選択・ドラッグ＆ドロップ・シミュレーション問題など、本番の出題形式に近い演習ができるのが特徴です。2026年更新でv1.1の最新シラバスに対応しています。

メリット

• 単一選択だけでなく、ドラッグ＆ドロップ・シミュレーション問題など本番に近い形式で演習できる
• 2026年更新で最新シラバス（v1.1）に対応している
• 座学講座を一通り終えた後の「知識はあるが解けない」問題を洗い出せる

正直なデメリット

• 評価3.7・レビュー126件・受講者1,403人と、実績はウズカレ式ほど多くない
• 座学要素はほぼゼロなので、これ単体で試験範囲を学習することはできない。上記の講座か書籍とセットで使うのが前提

こんな人におすすめ：座学は他の講座や書籍で済ませていて、本番前の仕上げとして実力を確認したい人。逆に、まだ座学講座を一周していない人が最初に手を出す講座ではありません。

📊 講座比較表に戻る ↑

講座の選び方

• ネットワーク未経験・じっくり派：「CCNA最短合格講義」1本で完結できます。41時間は長く感じますが、体系的な理解には遠回りに見えて一番の近道です。
• 書籍と組み合わせたい：白本（教科書）を1周読んでから黒本（問題集）に進み、動画講座はつまずいた箇所の補強に使う、という進め方も定番です。
• セールを待つのも手：Udemyは月2〜3回、大幅割引のセールを実施します。今すぐ受講を始めないなら、次のセールタイミングまで待って購入するのも合理的な選択です。

まとめ

CCNAの学習は、出題範囲の広さゆえに「まず体系的に全体像を掴む」ことが最大のポイントです。迷ったら、実績の多さで安心感のある「CCNA最短合格講義」から始めて、直前期に模擬問題集で仕上げる、という組み合わせが最も失敗の少ない選び方だと思います。

クラウドとネットワークを組み合わせて学びたい方は、こちらの記事もあわせてご覧ください。

👉 AWS認定クラウドプラクティショナー おすすめUdemy講座比較【2026年版】

The post CCNA おすすめUdemy講座比較【2026年版】 first appeared on CayTech Lab.

はじめに

「Tailscale（テイルスケール）」という名前を、ここ最近急に目にするようになった人も多いのではないでしょうか。

2026年7月、Google Trendsで「Tailscale」の検索数が前週比32,800%という急上昇を記録しています。背景には、従来型VPN機器のセキュリティリスク（Ivanti Connect Secure VPNなど、常時インターネットに公開されたVPN機器の脆弱性が相次いで報告されている問題）と、複数デバイス・複数環境で動くAIエージェントを安全につなぐネットワーク基盤への需要急増という2つの流れがあります。Claude Code・Codex CLIのようなAIエージェントを自宅サーバーやクラウド上で動かし、外出先からも安全にアクセスしたいというニーズが、Tailscaleの再注目につながっています。

本記事では、Tailscaleとは何か、なぜ従来のVPNと違うのか、そして実際の導入方法までを解説します。

この記事で分かること

• Tailscaleとは何か、従来のVPNとの違い
• WireGuard・メッシュネットワーク・ゼロトラストという技術的背景
• 料金プラン（個人利用なら無料枠で十分）
• Windows・Macへの導入手順
• 基本的な使い方（Exit Node機能など）
• セキュリティ面で押さえておくべきポイント

こんな人におすすめ

• 自宅サーバー・NASに外出先から安全にアクセスしたい人
• 複数のPC・クラウドインスタンス間でファイル共有やSSH接続をしたい人
• Claude Code・Codex CLIなどのAIエージェントを複数環境で動かし、一元的にネットワーク管理したい人
• 従来のVPNの設定の煩雑さ・ポート開放の不安から解放されたい人

Tailscaleとは？

Tailscaleは、WireGuardという高速な暗号化プロトコルをベースにした次世代型のメッシュVPNサービスです。従来型VPNのように専用サーバーを立てたりポートを開放したりする必要がなく、「ゼロコンフィグ」でデバイス同士を直接つなぐネットワークを構築できるのが最大の特徴です。

従来のVPNとの違い

Tailscaleはメッシュネットワークという方式を採用しており、通信が中央サーバーを介さず、デバイス同士が直接暗号化通信を行います。そのため、VPNサーバーの処理能力に律速されることなく、高いスループットと低遅延を実現できます。

ゼロトラストという設計思想

Tailscaleは「境界防御（社内ネットワークの内と外を分ける発想）」ではなく、**「ゼロトラスト」**という設計思想に基づいています。デバイス・ユーザーごとに個別に認証・認可を行い、「社内ネットワークの中にいるから安全」という前提を置きません。この考え方をより体系的に理解したい場合は、ゼロトラストの基本概念を1冊で押さえられる書籍が参考になります。

なぜ今Tailscaleが話題なのか

① 従来型VPN機器のセキュリティリスク

Ivanti Connect Secure VPNなど、常時インターネットに公開する必要がある従来型VPN機器では、ゼロデイ脆弱性が相次いで報告されており、実際に数千台規模のシステムが攻撃にさらされる事例も発生しています。Tailscaleは「常時インターネットに公開されたVPN機器」という前提そのものを不要にする設計のため、この種のリスクを構造的に避けられます。

② AIエージェントの複数環境運用ニーズの急増

Claude Code・Codex CLIのようなAIエージェントを、自宅PC・クラウドインスタンス・複数のリモート環境で並行して動かす人が増えています。これらの環境を安全に接続し、一元的にネットワーク管理したいというニーズが、Tailscaleの需要を押し上げている要因の一つです。

③ 導入・運用のシンプルさ

2026年9月時点でも、有料ビジネスクライアント数・月間アクティブユーザー数はともに増加傾向が続いています。個人開発者からエンタープライズまで、「複雑なVPN設定をしたくないが、安全に複数デバイスをつなぎたい」というニーズに応えている点が評価されています。

料金プラン

Tailscaleには複数のプランがありますが、個人利用であれば無料プランで十分です。

無料プランはクレジットカード登録も不要で、期限なく使い続けられます。ユーザー数は6人までですが接続できるデバイス数自体には上限がなく、個人の自宅サーバー・複数PC間の接続用途であれば、まずは無料プランから試すのがおすすめです。

導入手順

Windowsへの導入

1. Tailscale公式サイトにアクセスし、「Get started」ボタンをクリック
2. Google・GitHub・Microsoftアカウントなどでサインアップ
3. 「Windows」を選択し、インストーラーをダウンロード
4. ダウンロードしたインストーラーを実行し、ライセンス条項に同意してインストール
5. インストール後、タスクトレイのTailscaleアイコンからログイン

macOSへの導入

1. Tailscale公式サイトで「Get started」ボタンをクリック
2. 「macOS」を選択し、インストーラーをダウンロード
3. インストーラーを実行してインストール
4. Launchpadから「Tailscale」を起動し、ログイン

複数デバイスの接続

接続したい他のデバイス（別のPC・スマートフォン・クラウドインスタンスなど）でも、同じアカウントでTailscaleをインストール・ログインするだけで、自動的に同じネットワーク（tailnet）に参加し、お互いに直接通信できるようになります。サーバー構築やポート開放は一切不要です。

基本的な使い方

デバイス間の直接接続

Tailscaleを導入したデバイス同士は、まるで同じLAN内にあるかのように、IPアドレスやホスト名で直接アクセスできます。ファイル共有・SSH接続なども、通常のローカルネットワークと同じ感覚で行えます。

Exit Node機能

「Exit Node」に設定したデバイスを経由して、他のデバイスからインターネットに接続する機能です。例えば、自宅のPCをExit Nodeに設定すれば、外出先の端末から自宅回線経由でインターネットに接続できます。

セキュリティ面で押さえておきたいポイント

• 認証情報の管理: Tailscaleへのログインに使うGoogle・GitHub・Microsoftアカウント自体のセキュリティ（2段階認証など）を強化しておくことが前提になります
• ACL（アクセス制御リスト）の設定: 個人利用では意識しなくても動きますが、複数人・複数用途で使う場合はどのデバイスがどのデバイスにアクセスできるかを明示的に制御するACL設定を確認しておくと安心です
• 不要になったデバイスの除外: 使わなくなった端末はTailscaleの管理画面からネットワークの登録を解除しておきましょう

より体系的にゼロトラストの考え方や境界防御との違いを学びたい場合は、冒頭で紹介した書籍を参考にしてみてください。

よくある質問・トラブルシューティング

Q. デバイス同士がつながらない・「Connecting」から進まない

まず両方の端末で以下を確認してください。

1. Tailscaleアプリが起動し、ログイン済みの状態か：タスクトレイ（Windows）・メニューバー（macOS）のアイコンで接続状態を確認
2. 管理画面（Tailscale admin console）にデバイスが表示されているか：表示されていない場合はログインからやり直す
3. 社内ネットワーク・公衆Wi-Fiのファイアウォールで UDP通信がブロックされていないか：Tailscaleは通常UDP経由でピアツーピア接続を試み、それが失敗すると自動的にTailscale運営の中継サーバー（DERP）経由の通信に切り替わります。DERP経由でも速度は出ますが、直接接続より遅くなることがあります
4. それでも改善しない場合は、両端末で一度Tailscaleからログアウト→再ログインすると解消するケースが多いです

Q. 他のVPN（会社支給のVPNなど）と併用できる？

技術的には同時起動できる場合もありますが、ルーティングが競合して片方あるいは両方の通信が不安定になることがあるため、基本的には併用を避け、必要なタイミングで切り替えて使うことを推奨します。特に社用PCでは、会社のVPNクライアントとの併用について事前に情報システム部門に確認しておくと安心です。

Q. 無料プランだけでどこまでできる？

個人利用であれば、無料（Personal）プランで機能面の不足を感じる場面はほとんどありません。制限として押さえておきたいのは以下の点です。

• ユーザー数は最大6人まで（デバイス台数自体には上限がありません）
• タグ付きリソースは50個まで無料（それ以上は追加課金が必要）
• SCIM連携・MDM統合など、組織管理向けの機能は有料プラン（Standard以上）が対象

一人〜数人での自宅サーバー・複数PC接続用途であれば、無料プランの範囲で十分に完結します。

Q. スマートフォンのモバイル回線（キャリア回線）でも使える？

使えます。多くのキャリア回線はCGNAT（複数ユーザーでグローバルIPを共有する仕組み）環境下にありポート開放ができませんが、Tailscaleはこうした環境でもDERPリレーを介して接続を確立できるよう設計されています。外出先のスマートフォンから自宅のExit Node経由でインターネットに接続する、といった使い方も問題なく行えます。

Q. 会社・チームで導入する際に注意すべき点は？

個人利用とは異なり、複数人・複数デバイスが同じtailnetに参加する形になるため、導入前に以下を検討しておくと安心です。

• ACL（アクセス制御リスト）の設計：誰がどのデバイス・どのサービスにアクセスできるかを最初に整理しておく
• 退職者・異動者のデバイス除外：管理画面からの登録解除を運用フローに組み込む
• SSO（シングルサインオン）連携：Standardプラン以上ではSCIM経由でのユーザー管理が可能なため、既存のID管理基盤と連携させると運用負荷を下げられます

まとめ

Tailscaleは、WireGuardベースのメッシュVPNとゼロトラストという設計思想により、従来型VPNの「サーバー構築・ポート開放・攻撃面の大きさ」という課題を構造的に解決するサービスです。

• 個人利用なら無料プランで十分（最大6ユーザーまで）
• 導入はアカウント登録＋アプリインストールのみでサーバー構築不要
• AIエージェントを複数環境で動かす人にとって特に相性が良いネットワーク基盤

自宅サーバーやクラウドインスタンスへの安全なリモートアクセスを検討している方は、まず無料プランで試してみることをおすすめします。

Claude CodeやCodex CLIといったAIエージェントの環境構築については、以下の記事もあわせてご覧ください。

• Codex CLI環境構築完全ガイド

The post Tailscaleとは？無料で使えるゼロトラストVPNの設定方法｜つながらない時の対処法まで解説【2026年10月版】 first appeared on CayTech Lab.

はじめに

EC2インスタンスを構築し、セキュリティグループで自分のIPアドレスに制限したのに、なぜかSSH接続もWebアクセスもできない。

そんな経験はありませんか？

実は、一般的なIP確認方法（curlや確認くん）で表示されるIPアドレスと、実際にSSH/HTTP通信で使われるIPアドレスが異なる場合があるんです。

この記事では、私が実際に遭遇したトラブルと、真の送信元IPを確実に特定する方法を解説します。

問題の発覚：IP制限しているのに接続できない

最初の設定

EC2インスタンスを構築し、セキュリティグループで自分のIPアドレスを確認して設定しました。

curl https://checkip.amazonaws.com
# 結果: 222.444.111.100

# セキュリティグループに設定
# ポート22（SSH）: 222.444.111.100/32
# ポート80（HTTP）: 222.444.111.100/32

完璧！...と思いきや。

接続できない

# SSH接続を試みる
ssh -i my-ec2-test-key.pem ec2-user@13.231.231.97
# ssh: connect to host 13.231.231.97 port 22: Connection timed out

ブラウザでのWebアクセスも同様にタイムアウト。

「なぜ？！IPアドレスは合ってるはずなのに...」

試行錯誤の過程：様々なIP確認方法を試した

方法1: curl https://checkip.amazonaws.com

curl https://checkip.amazonaws.com
# 結果: 222.444.111.100

結論: このIPでは接続できなかった。

方法2: 確認くんサイト

https://www.ugtop.com/spill.shtml

結論: curlと同じIPが表示されたが、やはり接続できず。

方法3: SSH接続して$SSH_CLIENTで確認

一時的にセキュリティグループを0.0.0.0/0（全開放）にして、SSH接続を試みました。

# EC2にSSH接続
ssh -i my-ec2-test-key.pem ec2-user@パブリックIP

# 接続後、真の送信元IPを確認
echo $SSH_CLIENT
# 結果: 123.456.78.901 17508 22

123.456.78.901が表示された！

curlで確認した222.444.111.100とは全く異なるIPアドレスです。

方法4: Apacheアクセスログで確認

さらに確実性を高めるため、HTTPアクセスでも確認しました。

# EC2インスタンス内で実行
# ローカルPCのブラウザで http://パブリックIP にアクセス後
sudo cat /var/log/httpd/access_log | tail -5

# 出力例:
# 123.456.78.901 - - [14/Jan/2025:12:34:56 +0000] "GET / HTTP/1.1" 200 ...

SSH接続とHTTPアクセスで同じIPが確認できた。これが真の送信元IPだ！

解決：ルータ管理画面が最も確実だった

しかし、実はもっと簡単で確実な方法がありました。

ルータの管理画面で確認

自宅のWi-Fiルーター（TP-Link AX1800）の管理画面にアクセス：

http://192.168.0.1

ネットワークマップを開くと、**「インターネットIPアドレス: 123.456.78.901」**と表示されていました。

これが最も簡単で確実な方法でした。

なぜこの方法が最適なのか

✅ ルーター側で実際に使用しているIPを直接確認できる

• ブラウザやコマンドを経由しないため、プロキシの影響を受けない

✅ 一目で分かる

• SSH接続やログ確認などの手間が不要

✅ 確実

• ルーターがISPから割り当てられているIPアドレスそのもの

なぜIPアドレスが異なるのか？

通信経路の違い（推測）

【HTTPS通信（curl、確認くん）の場合】
PC → プロキシサーバー？ → インターネット
              ↓
       222.444.111.100 として認識される

【SSH/HTTP通信の場合】
PC → ルーター → インターネット
         ↓
    123.456.78.901 として認識される

プロバイダ固有の問題？

**BIGLOBE（プロバイダ）**を使用していますが、HTTPSトラフィック（ポート443）とその他のトラフィック（ポート22, 80）で異なる経路を通している可能性があります。

他のプロバイダを使用している友人は、確認くんで表示されるIPで問題なく接続できたため、ISP固有の設定が関係していると推測しています。

真の送信元IPを確実に特定する手順

推奨：ルータ管理画面で確認（最も簡単）

1. ブラウザでルーターの管理画面を開く
   - 一般的なアドレス: 192.168.0.1 または 192.168.1.1
   - ルーターの裏面に記載されていることが多い

2. 「ネットワークマップ」や「インターネット」の項目を開く

3. 「インターネットIPアドレス」や「WAN IPアドレス」を確認

4. このIPアドレスをセキュリティグループに設定

これだけです！

代替手順：一時全開放→SSH接続で確認

ルーター管理画面にアクセスできない場合の手順です。

ステップ1: セキュリティグループを一時的に全開放

# template.yaml（CloudFormation）の設定
SecurityGroupIngress:
  - IpProtocol: tcp
    FromPort: 22
    ToPort: 22
    CidrIp: 0.0.0.0/0  # 一時的に全開放
  - IpProtocol: tcp
    FromPort: 80
    ToPort: 80
    CidrIp: 0.0.0.0/0  # 一時的に全開放

または、既存のセキュリティグループをAWS CLIで変更：

aws ec2 authorize-security-group-ingress --group-id sg-XXX --protocol tcp --port 22 --cidr 0.0.0.0/0 --region ap-northeast-1
aws ec2 authorize-security-group-ingress --group-id sg-XXX --protocol tcp --port 80 --cidr 0.0.0.0/0 --region ap-northeast-1

ステップ2: SSH接続して真のIPを確認

# ローカルPC（VSCode）のターミナルで実行
ssh -i my-ec2-test-key.pem ec2-user@パブリックIP

# EC2インスタンス内で実行
echo $SSH_CLIENT
# 出力例: 123.456.78.901 17508 22
#         ↑この部分が真の送信元IP

このIPアドレスをメモしておきます。

ステップ3: HTTPアクセスでも確認（推奨）

SSH接続したまま、Apache httpdのアクセスログを確認：

# EC2インスタンス内で実行
# ローカルPCのブラウザで http://パブリックIP にアクセス後
sudo cat /var/log/httpd/access_log | tail -5

# 出力例:
# 123.456.78.901 - - [14/Jan/2025:12:34:56 +0000] "GET / HTTP/1.1" 200 ...

SSH接続とHTTPアクセスのIPが一致していれば完璧です。

ステップ4: セキュリティグループを制限

# EC2からログアウト
exit

# ローカルPC（VSCode）のターミナルで実行
# 全開放ルールを削除
aws ec2 revoke-security-group-ingress --group-id sg-XXX --protocol tcp --port 22 --cidr 0.0.0.0/0 --region ap-northeast-1
aws ec2 revoke-security-group-ingress --group-id sg-XXX --protocol tcp --port 80 --cidr 0.0.0.0/0 --region ap-northeast-1

# 真のIPのみ許可
aws ec2 authorize-security-group-ingress --group-id sg-XXX --protocol tcp --port 22 --cidr 123.456.78.901/32 --region ap-northeast-1
aws ec2 authorize-security-group-ingress --group-id sg-XXX --protocol tcp --port 80 --cidr 123.456.78.901/32 --region ap-northeast-1

ステップ5: 動作確認

# SSH接続
ssh -i my-ec2-test-key.pem ec2-user@パブリックIP
# → 成功！

# ブラウザで http://パブリックIP にアクセス
# → 表示される！

template.yamlへの反映

次回以降のEC2構築時のために、template.yamlを更新しておきましょう。

SecurityGroupIngress:
  - IpProtocol: tcp
    FromPort: 22
    ToPort: 22
    CidrIp: 123.456.78.901/32  # ルーター管理画面で確認したIP
    Description: Allow SSH from my IP
  - IpProtocol: tcp
    FromPort: 80
    ToPort: 80
    CidrIp: 123.456.78.901/32  # ルーター管理画面で確認したIP
    Description: Allow HTTP from my IP

よくあるトラブルと対処法

トラブル1: EC2内部でセキュリティグループを変更しようとしてエラー

[ec2-user@ip-172-31-34-41 ~]$ aws ec2 revoke-security-group-ingress ...
An error occurred (UnauthorizedOperation) ...

原因: EC2インスタンスのIAMロールには、セキュリティグループ変更権限がありません。

対処: SSH接続を終了（exit）して、ローカルPC（VSCode）のターミナルから実行してください。

# 現在どこにいるか確認
aws sts get-caller-identity

# EC2内部だと「assumed-role/EC2Role」が表示される
# ローカルPCだと「arn:aws:iam::...:user/...」が表示される

トラブル2: IPアドレスが頻繁に変わる

動的IPアドレスの場合、モデム再起動などで変わる可能性があります。

対処法1: 固定IP契約

• プロバイダーに固定IPサービス（有料）を申し込む

対処法2: Session Manager利用

• SSH不要でブラウザ/CLIから接続
• IP制限が不要になる

aws ssm start-session --target i-XXX --region ap-northeast-1

対処法3: 変わったらルーター管理画面で再確認

1. ルーター管理画面で新しいIPを確認
2. セキュリティグループを更新

まとめ

重要なポイント

✅ ルーター管理画面（192.168.0.1）が最も簡単で確実

• 「インターネットIPアドレス」をそのまま使用

✅ curlや確認くんで確認したIPと実際の接続元IPは異なる場合がある

• プロキシやISP（特にBIGLOBE？）の経路の違いが原因

✅ 代替手段：echo $SSH_CLIENTで確認

• 一時的に全開放→SSH接続して確認→制限

✅ HTTPアクセスログでも確認すると完璧

• /var/log/httpd/access_logで確認

✅ セキュリティグループ変更はローカルPCから

• EC2内部では権限エラーになる

推奨ワークフロー

【最も簡単な方法】
1. ルーター管理画面（192.168.0.1）を開く
2. 「インターネットIPアドレス」を確認
3. そのIPでセキュリティグループを設定
4. template.yamlを更新して次回に備える

【ルーターにアクセスできない場合】
1. セキュリティグループを0.0.0.0/0で構築
2. SSH接続して「echo $SSH_CLIENT」で真のIPを確認
3. Webアクセス後、httpdログでも確認（推奨）
4. ローカルPCから、セキュリティグループを真のIPに制限
5. template.yamlを更新

関連記事

• AWSプロジェクトのフォルダ整理で失敗しないために - 開発環境の整理方法

AWSプロジェクトのフォルダ整理で失敗しないために - Python仮想環境の落とし穴

はじめにAWSでの開発を進めていくと、ec2-test、sam-api-project、my-serverless-appなど、プロジェクトフォルダがユーザーディレクトリ直下に散らばってしまいませんか？「そろそろ整理しないと...」と思って...

caymezon.com

2026.02.01

• CloudShellとローカル環境でのAWS開発 - 使い分けと注意点 - CloudShellでの真のIP確認方法

CloudShellとローカル環境でのAWS開発 - 使い分けと注意点

はじめにAWS開発を始めると、「ローカルPC（VSCode）」と「CloudShell」、どちらで作業するのが良いのか迷いませんか？実は、それぞれに適した使い方があり、理解しないまま使うと思わぬトラブルに遭遇します。この記事では、両環境の違...

caymezon.com

2026.02.01

終わりに

セキュリティグループのIP制限は、正しく設定すれば強力なセキュリティ対策になります。

しかし、「真の送信元IP」を正確に把握していないと、自分自身をロックアウトしてしまうことも。

ルーター管理画面で確認するのが最も簡単で確実です。まずはこの方法を試してみてください！

同じ問題で困っている方の助けになれば嬉しいです。質問があれば、コメント欄でお気軽にどうぞ！

The post EC2セキュリティグループのIP制限で接続できない？真の送信元IPを特定する確実な方法 first appeared on CayTech Lab.