黑皮考町

  為什麼 Azure Subnet 總是少五個 IP？ 你是否曾經在 Azure 設定 Virtual Network (VNet) 時，發現即使精心規劃了 IP 範圍，實際可用的 IP 卻比你計算的少 五個 ？這五個 IP 到底去哪了？是 Azure 偷走了嗎？ 這個問題困擾了許多雲端工程師，尤其當你的 Subnet 設計較小時，這些消失的 IP 可能會影響服務部署。 Azure 官方說法：為什麼要保留五個 IP？ 根據 Microsoft 官方文件 ，Azure 會保留 每個 Subnet 的前四個 IP 和最後一個 IP 。這些 IP 的用途如下： 第一個 IP - 網路位址 (Network Address) 這是整個 Subnet 的識別位址，不能指派給任何設備。 第二個 IP - Azure 預設閘道 (Default Gateway) 這是 Azure 內部的路由閘道，提供 Subnet 內的通訊能力。 第三個 IP - 內部 DNS 解析 Azure 會使用這個 IP 來提供內部 DNS 服務。 第四個 IP - Azure 預留位址 官方並未詳細說明用途，但可能為未來功能做準備。 最後一個 IP - Azure 內部服務專用 這個 IP 被 Azure 內部系統使用，無法指派給 VM 或其他資源。 這對 Subnet 設計有什麼影響？ 因為 Azure 會自動保留這五個 IP，所以在規劃 Subnet 時，你需要計算「實際可用的 IP」，而不是理論上的 IP 數量。例如： /29 子網路 （8 個 IP）→ 可用 IP 3 個 （8 - 5 = 3） /28 子網路 （16 個 IP）→ 可用 IP 11 個 （16 - 5 = 11） /27 子網路 （32 個 IP）→ 可用 IP 27 個 （32 - 5 = 27） 如果你的 Subnet 太小，可能會導致資源無法順利分配。例如，Kubernetes Service (AKS) 需要較多的 IP 空間，若沒有提前考量這些保留 IP，可能會導致 Pod 無法分配到可用 IP。 如何避免 IP 不足的問題？ 如果你發現 Subnet 的可用 IP 不足，可以考慮以下解決方案： 使用較大的 Subnet （如...

Azure vs. AWS: 為什麼 Azure 無法指定 Subnet 的可用區 (AZ)？ 如果你是 AWS 的使用者，可能已經習慣了在建立 Subnet 時指定可用區 (Availability Zone, AZ)。但當你轉戰 Azure，可能會發現 「咦？Azure 竟然無法讓 Subnet 綁定到特定的 AZ？」 😲 這到底是為什麼？Azure 設計上有什麼不同？它的優勢又在哪裡？今天我們就來解開這個迷思！🔍 在 AWS 中，每個 Subnet 都是 「專屬於某個 AZ」 Subnet 綁定 AZ ：你建立的 Subnet 只能存在於特定的 AZ。 AZ 掛掉，影響有限 ：如果某個 AZ 出現故障，只有該 AZ 內的 Subnet 和資源會受影響，其他 AZ 依然健在！ 手動控制架構 ：你可以 手動 在不同 AZ 中建立 Subnet，來達到更細緻的可用性管理。 AWS CLI 建立 Subnet（範例） aws ec2 create-subnet \ --vpc-id vpc-12345678 \ --cidr-block 10.0.1.0/24 \ --availability-zone eu-central-1a 這樣一來，這個 Subnet 只會存在於 eu-central-1a ，所有部署在該 Subnet 的 EC2 也都會落在這個 AZ 內。 Azure：Subnets 是「Regional」而非「Zonable」 VNet（虛擬網路）是區域級的 ：Azure 的虛擬網路 (VNet) 覆蓋整個區域 ，而不是被分割成不同的 AZ。 Subnet 也是區域級的 ：Subnet 不會被限制在特定的 AZ，因此所有 AZ 都可以存取它。 可用區 (AZ) 是資源層級的設定 ：例如，你可以讓 VM 指定在哪個 AZ 內，但它仍然可以使用同一個 Subnet。 Azure CLI 建立 VMs 到不同 AZ az vm create --name VM1 --resource-group RG-WestEurope \ --image UbuntuLTS --vnet-name AppVNet \ --subnet AppSubnet \ --zone 1 az vm create --nam...

使用 Azure Private Link 或 VNet Service Endpoints 來建立私有 ACR 在現代雲端環境中， 安全性 是企業最關心的議題之一，尤其是當你的 Azure Container Registry (ACR) 儲存了關鍵映像檔時，你絕對不希望它暴露在公網上，成為駭客攻擊的目標。 兩種方式讓 ACR 更安全 Azure Private Link（推薦 ） - ACR 完全私有，封鎖所有公網流量，只允許內部 VNet 存取。 VNet Service Endpoints - ACR 仍有公網 IP，但僅允許來自指定 VNet 的請求。 為什麼選擇 Private ACR？ 確保 ACR 不暴露在公網上 - 預設 ACR 會有公網 IP，這是一個潛在的安全風險！ 增強安全性，阻擋外部攻擊 - 只有內部網路能存取 ACR，提高保護級別。 與 AKS 無縫整合 - 確保 Kubernetes 叢集能安全拉取映像檔。 DNS 解析更順暢 - 透過 privatelink.azurecr.io 解析內部 ACR。 🔹 選項 1：使用 Private Link（推薦 ） Private Link 讓 ACR 完全私有 ，不允許任何來自公網的存取。 步驟 1：建立 Private ACR resource "azurerm_container_registry" "acr" { name = "myprivateacr" resource_group_name = <resource_group_name> location = <resource_group_location> sku = "Premium" ad...

  如何設定 WireGuard VPN Server How to Set Up a WireGuard VPN Server on Ubuntu 想要架設自己的 VPN？WireGuard 是現在最輕量、高速又安全的 VPN 協議，比 OpenVPN 和 IPSec 更簡單易用！這篇教學會手把手帶你在 Ubuntu 上安裝與設定 WireGuard 伺服器，讓你的連線更安全、且快速！🚀 💡 Step 1：更新系統 在開始之前，先確保你的系統是最新的： sudo apt update && sudo apt upgrade -y 小提醒 ：記得備份重要資料，確保系統更新不會影響到其他服務哦！📦 🛠 Step 2：安裝 WireGuard Ubuntu 20.04 以上的版本已經內建 WireGuard，直接執行安裝指令： sudo apt install wireguard -y 安裝完後，可以用這個指令確認版本： wg --version 🔑 Step 3：生成 WireGuard 金鑰 每台裝置都需要一組 私鑰 (private key) 和 公鑰 (public key) 。先來生成伺服器端的密鑰： umask 077 wg genkey | tee privatekey | wg pubkey > publickey 接著把這些密鑰放到安全的位置： sudo mv privatekey /etc/wireguard/server_private.key sudo mv publickey /etc/wireguard/server_public.key sudo chmod 600 /etc/wireguard/server_private.key 📄 Step 4：設定 WireGuard 伺服器 現在來建立 WireGuard 設定檔 ： sudo nano /etc/wireguard/wg0.conf 輸入以下內容： [Interface] Address = 10.0.0.1/24 SaveConfig = true PrivateKey = <server_private_key> ListenPort = 51820 # 啟用 IP 轉發...

深入理解 Docker 網路設置：Bridge 模式原理與實現 在使用 Docker 建立容器並指定網路為 Bridge 模式時，Docker 使用了多項技術來實現容器與Host的網路通信。以下將深入探討這些技術的原理以及如何實現，幫助大家更好地理解 Docker 網路設置。 使用 Veth Pair 實現容器與Host的通信 Docker 在建立容器時使用了 veth pair 技術。這是一種在容器的 Network Namespace 和Host之間建立虛擬網路介面的方法。其中一端連接到容器的 Network Namespace 中，另一端連接到Host的 docker0 介面（虛擬交換機），從而實現容器與 Host 的網路通信。 bash # Docker 在安裝過程中會建立一個 docker0 的網路介面 ip link add docker0 type bridge # 設定作為 Network Namespace 與Host通訊的 Gateway IP ip addr add 172.17.0.1/16 dev docker0 做完以上的動作後，會生成 172.17.0.0/16 的網路環境，接下來 Docker 會執行以下的動作，將容器的網路與 Host 間的網路通道給建立起來： 1. 創建 Veth Pair： bash # Docker 在安裝過程中會建立一個 docker0 的網路介面 ip link add eth0@if? type veth peer name veth????@if? 其中，eth0@if? 是容器內的網路介面名稱，veth????@if? 則是連接到 Host 的虛擬交換機（docker0）的介面名稱。（? 是一串隨機字元） 2. 將網路介面（eth0@if?）加入容器的 Network Namespace 中： bash ip link set eth0@if? netns ${CONTAINER-NAMESPACE} 3. 將另一端的介面（veth????@if?） 加入到 Host 的虛擬交換機（docker0）中： bash ip link set veth????@if? master docker0 4. 在容器的 Network Namespace 中，為 eth0@if? 介面設置 ...

  快速建立私有 GCE Instance 並整合 Cloud NAT 前言 私有 GCE Instance 能夠減少被駭客攻擊的機會,  因為在做網路配置的時候, 不會特別分派外部 IP 給這類型的 VM, 所有存取 VM 的行為都必須走內網, 但也因為沒有對外的 IP, 所以 VM 裡也沒辦法透過網際網路去下載並且使用第三方的套件 解法： 整合 Cloud NAT 透過 Cloud NAT 位址轉譯的功能, 將 VM 的內部 IP 對應到一組共用的對外 IP 使用 Terraform 建立 VPC, Subnet, GCE VM variable "project" {   default = "test"    } variable "network_name" {   default = "net-123"    } variable "subnet_name" {   default = "subnet-123"    } resource "google_compute_network" "vpc_network" {   project                 = var.project   name                    = var.network_name   auto_create_subnetworks = false } resource "google_compute_subnetwork" "vpc_subnet" {   project                 = var.project   name          = var.subnet_name   ip_cidr_range = "10.51.0.0/23...

  如何跨專案存取私有 GKE 叢集  在 GKE 的 Control Plane 沒有提供外部 IP  的情況下,  維運人員若想要操作 GKE  則必需走 VPN 的方式才能訪問到 Control Plane  的 API Server 以下示範, 如何在不同的專案底下建立跳板機跟 GKE 叢集,  並透過 VPN 的方式在跳板機上去操作另一個專案下的 GKE 叢集 在 Project A 建立 VPC #1 variable "gke_project" {   default = "prj-1" } variable "gke_network_name" {   default = "net-1" } variable "gke_subnet_name" {   default = "subnet-1" } resource "google_compute_network" "gke_vpc_network" {   project                 = var.gke_project   name                    = var.gke_network_name   auto_create_subnetworks = false } resource "google_compute_subnetwork" "gke_vpc_subnet" {   project                 = var.gke_project   name          = var.gke_subnet_name   ip_cidr_range = "10.51.0.0/23"   region       ...