Antony 筆記：技術原理與實務經驗 – 網路基礎

Networking Introduction

Fri, 03 Jan 2025 14:48:08 +0800

「在證明無罪之前有罪」。這是網路和監督網路的工程師的口頭禪。在本開篇章節中，我們會涉獵網路技術與標準的發展、簡介網路的主流理論，並介紹我們的 Golang 網路伺服器，它將是整本書中 Kubernetes 與雲端中網路範例的基礎。

1.1. Networking History

我們今天所認識的網際網路非常廣大，電纜橫跨海洋和高山，以前所未有的低延遲連接城市。Barrett Lyon 的「Mapping the Internet」（如圖 1-1 所示）展示了互聯網的真正廣闊程度。該圖片說明了組成網際網路的網路之間的所有連接。網路的目的是將資訊從一個系統交換到另一個系統。這是一個分散式全球系統的巨大要求，但網際網路並非一直都是全球性的；它一開始只是一個概念模型，隨著時間的推移慢慢地建立起來，成為 Lyon 這幅視覺震撼的藝術作品中的龐然大物。在學習網路時有許多因素需要考慮，例如最後一英里（last mile）、客戶家與網路服務供應商網路之間的連線，一直到擴大到網際網路的地緣政治版圖。網際網路已融入我們的社會結構。在本書中，我們將討論網路如何運作，以及 Kubernetes 如何為我們抽象網路。

1.2. OSI Model

OSI 模型是描述兩個系統如何透過網路進行通訊的概念架構。OSI 模型將跨網路傳送資料的責任細分為不同層級。這對於描述每層責任之間的關係以及資料如何透過網路傳送的教育目的非常有效。有趣的是，它本來是用來為網路提供電力的通訊協定套件，但卻因為 TCP/IP 而失敗。

以下是概述 OSI 模型和通訊協定的 ISO 標準：

ISO/IEC 7498-1，「The Basic Model (基本模式)」
ISO/IEC 7498-2，「Security Architecture (安全架構)」
ISO/IEC 7498-3，「Naming and Addressing (命名和定址)」
ISO/IEC 7498-4，「Management Framework (管理架構)」。

ISO/IEC 7498-1 描述了 OSI 模型嘗試傳達的內容：

OSI 模型的描述是一種複雜而精確的方式，說明網路有如蛋糕或洋蔥般分層。如下圖所示，OSI 模型將網路的責任分成七個不同的層級，每個層級都有不同的功能，以協助資訊從一個系統傳輸到另一個系統。各層封裝來自其下一層的資訊；這些層分別是 Application (應用程式層)、Presentation (呈現層)、Session (會話層)、Transport (傳輸層)、Network (網路層)、Data Link (資料連結層)和 Physical (實體層)。在接下來的幾頁中，我們將介紹每一層的功能，以及它如何在兩個系統之間傳送資料。

![image](https://hackmd.io/_uploads/SJYbLOB8Je.png =25%x)

每層從上一層取得資料，並將其封裝成其 Protocol Data Unit (通訊協定資料單元 PDU)。PDU 用於描述各層的資料。PDU 也是 TCP/IP 的一部分。會話層的應用程式被視為 PDU 的「資料」，為通訊準備應用程式資訊。傳輸層使用連接埠（ports）來區分本機系統上哪個進程負責資料。網路層的 PDU 是封包。封包是在網路之間路由的獨特資料片段。資料連線層是訊框或段。每個封包被分割成訊框，檢查是否有錯誤，然後在本端網路上傳送出去。物理層在媒體上以位元傳輸訊框。接下來我們將詳細介紹每一層：

How does Ingress Nginx Controller work?

Sun, 27 Oct 2024 09:21:30 +0800

本文介紹 Ingress 基本概念、Ingress Controller 工作原理和 Nginx Ingress Controller 的使用說明。

1. Ingress 基本概念

在 Kubernetes 叢集中，Ingress 作為叢集內服務對外暴露的存取存取點，幾乎承載著叢集內服務存取的所有流量。 Ingress 是 Kubernetes 中的一個 resource object，用來管理叢集外部存取叢集內部服務的方式。可以透過 Ingress 資源來設定不同的轉送規則，從而實現根據不同的規則設定存取叢集內不同的 Service 所對應的後端 Pod。

2. What is Ingress?

Ingress 將叢集外部的 HTTP 和 HTTPS 請求路由到叢集內的服務。流量路由是根據 Ingress 資源上定義的規則來控制的。

以下是一個簡單的例子，Ingress 將所有的流量導向一個服務：

Ingress 可以設定為給服務一個外部可訪問的網址、負載均衡的流量、terminate SSL / TLS，以及提供 name-based ( 基於名稱 ) 的 virtual hosting 功能。Ingress Controller 負責實現 Ingress，一般會搭配 load balancer 一起使用，也可能設定 edge router 或額外的前端來幫助處理流量。

Ingress 不會暴露任意的 ports (埠) 或 protocols (通訊協定)。如果需要將 HTTP 和 HTTPS 以外的服務暴露到互聯網，通常會使用 Service.Type=NodePort 或 Service.Type=LoadBalancer 類型的服務來實現。

3. Ingress Controllers 使用須知

要讓 Ingress 在你的 K8s 叢集中運作，必須有一個 Ingress controller 在運行。你需要選擇至少一個 Ingress controller 並確保它已經在叢集中設定好。

和其他在 kube-controller-manager 二進位程式中運行的 controller 不同，Ingress controller 並不會隨著叢集自動啟動。

4. Ingress Controller 工作原理

Ingress Controller 用於解析 Ingress 的轉送規則。 Ingress Controller 收到請求，匹配 Ingress 轉發規則轉發到後端 Service 所對應的 Pod，由 Pod 處理請求。 Kubernetes 中 Service、Ingress 與 Ingress Controller 有著以下關係：

Service 是後端真實服務的抽象，一個 Service 可以代表多個相同的後端服務。
Ingress 是反向代理規則，用來規定 HTTP、HTTPS 請求應該被轉送到哪個 Service 所對應的 Pod。例如根據請求中不同的 Host 和 URL 路徑，讓請求落在不同 Service 所對應的 Pod上。
Ingress Controller 是一個反向代理程序，負責解析 Ingress 的反向代理規則。如果Ingress 有增刪改的變動，Ingress Controller 會及時更新自己對應的轉送規則，當 Ingress Controller 收到請求後就會根據這些規則將請求轉送到對應 Service 的 Pod 上。

Ingress Controller 透過 API Server 取得 Ingress 資源的變化，動態地產生 Load Balancer 所需的設定文件，然後依序產生新的路由轉送規則。

5. Deploying the Ingress Nginx Controller as a Deployment Workload

# curl -sL https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.11.2/deploy/static/provider/cloud/deploy.yaml | kubectl apply -f -

執行結果 :

namespace/ingress-nginx created
serviceaccount/ingress-nginx created
serviceaccount/ingress-nginx-admission created

確認 pod 的狀態是 up 和 running

# kubectl wait -n ingress-nginx pod -l app.kubernetes.io/component=controller --for=condition=Ready --timeout=120s

執行結果 :

pod/ingress-nginx-controller-7d8d8c7b4c-pctt4 condition met

6. 了解 Ingress Nginx Controller Kubernetes Resources

$ kubectl get all -n ingress-nginx -o name

執行結果 :

pod/ingress-nginx-admission-create-lgfnk
pod/ingress-nginx-admission-patch-55p8j
pod/ingress-nginx-controller-7d8d8c7b4c-pctt4
service/ingress-nginx-controller
service/ingress-nginx-controller-admission
deployment.apps/ingress-nginx-controller
replicaset.apps/ingress-nginx-controller-7d8d8c7b4c
job.batch/ingress-nginx-admission-create
job.batch/ingress-nginx-admission-patch

這是一個典型的 Deployment，前面有兩個 Service 在支援，以下是為什麼需要這樣做的原因：

第一個 service 叫做 ingress-nginx-controller，它是一個 load balancer 類型的 service，用來將 Ingress controller 的功能暴露給外部。它透過穩定的 IP 地址和 DNS 名稱，讓外部客戶端可以連接到 Ingress controller。load balancer service 也幫助 Ingress controller 將進來的流量分散到多個 Pod 分身上，提升可用性和擴展性。
第二個 service 叫做 ingress-nginx-controller-admission，它是一個 cluster IP service，用來控制 Ingress controller 的准入。這個 service 在 Ingress 資源被 Ingress controller 處理之前，用於驗證和修改這些資源。它在叢集內部運行，不對外部客戶端暴露，使用 Kubernetes 的 admission control mechanism (准入控制機制) 攔截並修改 Ingress 資源。
簡而言之，第一個 service 提供 Ingress controller 的外部進入點，負責 traffic routing 和 load balancing；而第二個 service 負責在 Ingress 資源被 Ingress controller 處理前進行驗證和修改。

如果我們查看 Endpoints，就會發現兩個服務都指向相同的 Pod

$ kubectl -n ingress-nginx get endpoints

執行結果 :

NAME ENDPOINTS AGE
ingress-nginx-controller 10.244.2.30:443,10.244.2.30:80 24m
ingress-nginx-controller-admission 10.244.2.30:8443 24m

而這個 pod 就是 ingress-nginx-controller

$ kubectl -n ingress-nginx get pods -l "app.kubernetes.io/component=controller" -o wide

執行結果 :

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
ingress-nginx-controller-7d8d8c7b4c-pctt4 1/1 Running 0 27m 10.244.2.30 worker2 <none> <none>

7. 設定 ingress nginx controller 使用 host network

在某些環境中，如果沒有 load balancer 可用，而且不能使用 NodePorts，可以設定 ingress-nginx 的 Pod 使用它們所在主機的網路，而不是使用獨立的 network namespace。這樣做的好處是 Ingress-Nginx Controller 可以直接將 80 和 443 埠綁定到 Kubernetes 節點的網卡上，而不需要透過 NodePort 服務進行額外的網路轉換。

!!! 注意：這種做法不會利用任何 Service 物件來暴露 Ingress-Nginx Controller。如果目標叢集中存在 ingress-nginx 的 Service，建議將其刪除。

$ kubectl edit -n ingress-nginx deployment ingress-nginx-controller

執行結果 :

…
spec:
## 1. 新增以下這行
hostNetwork: true
containers:
- args:
- /nginx-ingress-controller
## 2. 註解掉以下這行的設定
#- --publish-service=$(POD_NAMESPACE)/ingress-nginx-controller
...
## 3. 新增以下這行
- --report-node-internal-ip-address

!!! 危險 “安全考量” 啟用這個選項會讓每個系統的 daemon 都會在任何網路介面（包括主機的 loopback）上暴露給 Ingress-Nginx Controller。請仔細評估這樣做對系統安全性的影響。

!!! 例子考慮這個由 2 個副本組成的 ingress-nginx-controller 部署，NGINX Pod 繼承了它們所在主機的 IP 地址，而不是使用內部的 Pod IP。

$ kubectl -n ingress-nginx get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
ingress-nginx-admission-create-lgfnk 0/1 Completed 0 49m 10.244.2.28 worker2 <none> <none>
ingress-nginx-admission-patch-55p8j 0/1 Completed 0 49m 10.244.2.29 worker2 <none> <none>
ingress-nginx-controller-67f877d9d8-9sr6q 1/1 Running 0 3m24s 172.22.8.203 worker2 <none> <none>

這種部署方式的一個主要限制是，每個叢集節點上只能調度一個 Ingress-Nginx 控制器 Pod，因為在同一個網路介面上綁定相同的埠多次在技術上是不可能的。因為這個原因而無法調度的 Pod 會出現以下的事件錯誤：

$ kubectl -n ingress-nginx get events \
--sort-by='.lastTimestamp' \
--field-selector involvedObject.kind=Pod

執行結果

LAST SEEN TYPE REASON OBJECT MESSAGE
5m13s Warning FailedScheduling pod/ingress-nginx-controller-67f877d9d8-8z2ws 0/3 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 2 node(s) didn't have free ports for the requested pod ports. preemption: 0/3 nodes are available: 1 Preemption is not helpful for scheduling, 2 No preemption victims found for incoming pod.
...

確保只建立可排程 Pod 的方法之一，是將 Ingress-Nginx Controller 部署為 DaemonSet，而非傳統的 Deployment。

除非某個節點被設定為拒絕這些 Pod，否則 DaemonSet 只會為每個叢集節點（包括主節點）調度一種 Pod。

像使用 NodePorts 一樣，這種方法也有一些需要注意的小問題。

DNS 解析設定了 hostNetwork: true 的 Pod 不會使用內部的 DNS resolver（例如 kube-dns 或 CoreDNS），除非它們的 dnsPolicy 設定為 ClusterFirstWithHostNet。如果 NGINX 需要解析內部名稱，建議使用這個設定。
Ingress 狀態由於使用主機網路的設定中沒有任何 Service 來暴露 Ingress-Nginx Controller，因此在標準雲端環境中常用的 --publish-service flag 不適用，所有 Ingress 物件的狀態會保持為空白。

$ kubectl get ingress
NAME HOSTS ADDRESS PORTS
test-ingress myapp.example.com 80

相反，由於 bare-metal 節點通常沒有 ExternalIP，因此必須啟用 --report-node-internal-ip-address flag，將所有 Ingress 物件的狀態設定為執行 Ingress-Nginx Controller 的所有節點的內部 IP 位址。

!!! 範例給定一個由 2 個 replicas 組成的 ingress-nginx-controller DaemonSet

$ kubectl -n ingress-nginx get pod -o wide
NAME READY STATUS IP NODE
default-http-backend-7c5bc89cc9-p86md 1/1 Running 172.17.1.1 host-2
ingress-nginx-controller-5b4cf5fc6-7lg6c 1/1 Running 203.0.113.3 host-3
ingress-nginx-controller-5b4cf5fc6-lzrls 1/1 Running 203.0.113.2 host-2

controller 會將其管理的所有 Ingress 物件的狀態設定為下列值：

$ kubectl get ingress -o wide
NAME HOSTS ADDRESS PORTS
test-ingress myapp.example.com 203.0.113.2,203.0.113.3 80

!!! 注意另外，也可以使用 --publish-status-address 標誌來覆寫寫入 Ingress 物件的位址。請參閱命令列參數。

8. Deploying an Application (Comprising of Deployment, Service, and Ingress)

$ kubectl create ns ing-internal
namespace/ing-internal created
$ echo 'kind: Pod
apiVersion: v1
metadata:
name: hi-app
namespace: ing-internal
labels:
app: hi-app
spec:
containers:
- name: hi-app
image: quay.io/flysangel/hashicorp/http-echo
args:
- "-text=hi"
---
kind: Service
apiVersion: v1
metadata:
name: hi-service
namespace: ing-internal
spec:
selector:
app: hi-app
ports:
- port: 5678' | kubectl apply -f -
$ echo 'apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ping
namespace: ing-internal
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx
rules:
- http:
paths:
- path: /hi
pathType: Prefix
backend:
service:
name: hi-service
port:
number: 5678' | kubectl apply -f -

9. Observing the Ingress Nginx Controller Pod

如果我們現在查看 Ingress Nginx Controller pod log，我們會發現上一步建立的 Ingress 有一些 log 資訊：

$ kubectl -n ingress-nginx logs deployments/ingress-nginx-controller

執行結果 :

...
"successfully validated configuration, accepting" ingress="ing-internal/ping"
"Found valid IngressClass" ingress="ing-internal/ping" ingressclass="nginx"
"Configuration changes detected, backend reload required"
Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ing-internal", Name:"ping", UID:"b77f8877-1a41-4530-95ce-6aaa4032cbb8", APIVersion:"networking.k8s.io/v1", ResourceVersion:"78690", FieldPath:""}): type: 'Normal' reason: 'Sync' Scheduled for sync
"Backend successfully reloaded"
Event(v1.ObjectReference{Kind:"Pod", Namespace:"ingress-nginx", Name:"ingress-nginx-controller-67f877d9d8-9sr6q", UID:"a371a524-53c5-4e3a-8ea3-6b3858275c52", APIVersion:"v1", ResourceVersion:"71406", FieldPath:""}): type: 'Normal' reason: 'RELOAD' NGINX reload triggered due to a change in configuration
"updating Ingress status" namespace="ing-internal" ingress="ping" currentValue=null newValue=[{"ip":"172.22.8.203"}]
Event(v1.ObjectReference{Kind:"Ingress", Namespace:"ing-internal", Name:"ping", UID:"b77f8877-1a41-4530-95ce-6aaa4032cbb8", APIVersion:"networking.k8s.io/v1", ResourceVersion:"78765", FieldPath:""}): type: 'Normal' reason: 'Sync' Scheduled for sync

基本上，Ingress Nginx Controller pod 會一直觀察 Kubernetes API Server。一旦接收到 Ingress 資源已建立的事件，它就會檢查其語法，以及是否已定義了 IngressClass=nginx。

如果新的 Ingress manifest 符合規定，Nginx Controller 就會更新用於 routing 的設定檔，並在不關閉 Pod 的情況下啟動重新載入。

10. 查看 Ingress Nginx Controller Pod Configuration File

routing 設定是存儲在 Ingress Nginx Controller Pod 的設定文件中。這裡我提取了一些高層次的相關部分：

# 將 Ingress Nginx Controller Pod 名稱設為變數
$ PN=$(kubectl -n ingress-nginx get pods -l "app.kubernetes.io/component=controller" -o name | head -n 1)
$ kubectl -n ingress-nginx exec ${PN#*/} -- cat nginx.conf

執行結果 :

(...)
http {
(...)
server {
(...)
location ~* "^/hi" {
set $namespace "ing-internal";
set $ingress_name "ping";
set $service_name "hi-service";
set $service_port "5678";
set $location_path "/hi";
set $global_rate_limit_exceeding n;
rewrite_by_lua_block {
lua_ingress.rewrite({
force_ssl_redirect = false,
ssl_redirect = true,
force_no_ssl_redirect = false,
preserve_trailing_slash = false,
use_port_in_redirects = false,
global_throttle = { namespace = "", limit = 0, window_size = 0, key = { }, ignored_cidrs = { } },
})
balancer.rewrite()
plugins.run()
...
# Custom Response Headers
rewrite "(?i)/hi" / break;
proxy_pass http://upstream_balancer;
proxy_redirect off;
}
(...)
}
}
}

基本上，如果這個 Nginx 伺服器收到針對根路徑（也就是請求中沒有指定路徑）的請求，它會使用 OpenResty 的 ngx_http_lua_module 模組來重寫請求，並將其傳遞給應用服務。

讓我們來看看目前為止的設定：

通過 hi-service Service 將流量以 load balanced 或 random 的方式傳給網站應用的 Pod。
- load balanced 或 random 將取決於 kube-proxy 的 mode
創建了一個帶有 class=nginx 屬性的 Ingress ，來將流量 routes 到這個 Service。這會在 Kubernetes 中觸發一個事件。
Ingress Nginx Controller Pod 看到這個事件並做出反應：它會驗證 Ingress 設定是否語法正確，以及是否設置了必要的屬性。
如果所有檢查都通過，Ingress Nginx Controller 會將 routing 細節加入到其內部設定文件中，並進行 hot reloads。
Ingress Nginx Controller Pod 作為反向代理，將它收到的流量 routing 到叢集中的相應服務。
- 使用 Ingress 資源來創建這些路由規則。

檢視 Ingress 狀態

$ kubectl -n ing-internal get ing
NAME CLASS HOSTS ADDRESS PORTS AGE
ping nginx * 172.22.8.203 80 28m

可以看到 Ingress 的 Address 和 Ports 對應的就是 Ingress Nginx Controller Pod 的 IP 跟 Port。

11. Ref

How to Block Ping ICMP Requests with firewalld

Fri, 18 Oct 2024 07:38:18 +0800

Understanding predefined zones

block – All incoming network connections rejected. Only network connections initiated from within the system are possible.
dmz – Classic demilitarized zone (DMZ) zone that provided limited access to your LAN and only allows selected incoming ports.
docker – All network connections are accepted for Docker service using docker0 interface.
drop – All incoming network connections dropped, and only outgoing network connections allowed.
external – Useful for router type of connections. You need LAN and WAN interfaces too for masquerading (NAT) to work correctly.
home – Useful for home computers such as laptops and desktops within your LAN where you trust other computers. Allows only selected TCP/IP ports.
internal – For use on internal networks when you mostly trust the other servers or computers on the LAN.
public – You do not trust any other computers and servers on the network. You only allow the required ports and services. For cloud servers or server hosted at your place always use public zone.
trusted – All network connections are accepted. I do not recommend this zone for dedicated servers or VMs connected to WAN.
work – For use at your workplace where you trust your coworkers and other servers.

# 1. start and enable the firewalld service
$ systemctl enable --now firewalld.service
# 2. Check firewalld service is active
$ systemctl is-active firewalld.service
active
# 3. Print currently active zones altogether with interfaces and sources used in these zones.
$ firewall-cmd --get-active-zones
docker
interfaces: docker0
public
interfaces: eth0
# 4. (optional) Bind interface interface to zone zone. If zone is omitted, default zone will be used.
## 如果在上一步驟發現 public 的 zone 沒有套用在 eth0 這張網卡的話，執行已下命令
$ firewall-cmd --permanent --zone=public --add-interface=eth0
# 5. Add the ICMP block inversion to block all ICMP requests at once
### and Make the new settings persistent
$ firewall-cmd --permanent --add-icmp-block-inversion --zone=public
success
# 6. Reload firewall rules and keep state information.
### Current permanent configuration will become new runtime configuration
$ firewall-cmd --reload
success
# 7. Return whether ICMP block inversion is enabled. Returns 0 if true, 1 otherwise.
$ firewall-cmd --query-icmp-block-inversion
yes
# 8. List everything added or enabled in public zone.
$ firewall-cmd --list-all --zone=public
public (active)
target: default
icmp-block-inversion: yes
interfaces: eth0
sources:
services: ssh suse-manager-server
ports:
protocols:
forward: no
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:

Check Veth peer

Sun, 13 Oct 2024 06:10:38 +0800

PreRequest

$ sudo apk info iproute2
iproute2-6.9.0-r0 description:
IP Routing Utilities
iproute2-6.9.0-r0 webpage:
https://wiki.linuxfoundation.org/networking/iproute2
iproute2-6.9.0-r0 installed size:
428 KiB

不能用 busybox 的 ip 命令

Start Cehck Veth peer

1. 先看 veth 的另一端插在哪個 Namespace

$ ip a s veth0
4: veth0@if2:  mtu 1500 qdisc noqueue master podman1 state UP group default qlen 1000
link/ether 9e:a5:82:a2:56:d1 brd ff:ff:ff:ff:ff:ff link-netns netns-49384fd6-7fc9-cf3d-d77f-1e6ae9fe960f
inet6 fe80::9ca5:82ff:fea2:56d1/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever

由以上結果得知 veth0 與 netns-49384fd6-7fc9-cf3d-d77f-1e6ae9fe960f Linux Network Namespace 連接

2. 列出 Network Namespace 的網卡資訊

$ netns=$(ip a s veth0 | grep link-netns)
$ echo ${netns##* }
netns-49384fd6-7fc9-cf3d-d77f-1e6ae9fe960f
$ sudo ip netns exec ${netns##* } ip a s eth0
2: eth0@if4:  mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 9e:53:27:c4:74:47 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.89.0.2/24 brd 10.89.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fc00:f853:ccd:e793::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::9c53:27ff:fec4:7447/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever

Configure MTU to maximize network performance

Sun, 29 Sep 2024 04:04:02 +0800

1. Configure the MTU value in Podman Network

1.1. 修改已經存在的 Podman Network

$ sudo nano /etc/containers/networks/kind.json

新增以下內容 :

 "options": {
"mtu": "6000"
},

完整內容如下 :

{
"name": "kind",
"id": "df72cb97d019a6025357f12b68870a26897b2c288a24b11c5ec0c2f9b3e5b878",
"driver": "bridge",
"network_interface": "podman1",
"created": "2024-09-27T16:14:32.979631978+08:00",
"subnets": [
{
"subnet": "fc00:f853:ccd:e793::/64",
"gateway": "fc00:f853:ccd:e793::1"
},
{
"subnet": "10.89.0.0/24",
"gateway": "10.89.0.1"
}
],
"ipv6_enabled": true,
"internal": false,
"dns_enabled": true,
"options": {
"mtu": "6000"
},
"ipam_options": {
"driver": "host-local"
}
}

1.2. 檢查 Podman1 網卡 MTU 已設為 6000

$ ip a s podman1

執行結果如下 :

9: podman1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 6000 qdisc noqueue state UP group default qlen 1000
link/ether 5e:25:b2:4b:c0:cd brd ff:ff:ff:ff:ff:ff
inet 10.89.0.1/24 brd 10.89.0.255 scope global podman1
valid_lft forever preferred_lft forever
inet6 fc00:f853:ccd:e793::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::5c25:b2ff:fe4b:c0cd/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever

1.3. 關閉 Kind Cluster

$ kco c31

1.4. 啟動 Kind Cluster

$ kci c31

1.5. 檢查 Kind node 網卡 MTU 已設為 6000

$ ip a s

執行結果如下 :

10: veth0@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 6000 qdisc noqueue master podman1 state UP group default qlen 1000
link/ether 4a:c4:0e:46:e5:7e brd ff:ff:ff:ff:ff:ff link-netns netns-9ff96fea-b7ef-8593-61a2-467b31e2d98e
inet6 fe80::48c4:eff:fe46:e57e/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
11: veth1@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 6000 qdisc noqueue master podman1 state UP group default qlen 1000
link/ether f2:34:71:74:cf:bd brd ff:ff:ff:ff:ff:ff link-netns netns-86850d7d-bc9e-3509-524b-f40e2cd61514
inet6 fe80::f034:71ff:fe74:cfbd/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
12: veth2@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 6000 qdisc noqueue master podman1 state UP group default qlen 1000
link/ether de:6c:ef:f7:e6:f5 brd ff:ff:ff:ff:ff:ff link-netns netns-b5b7d1a1-af28-b060-eec2-3c3f87150110
inet6 fe80::dc6c:efff:fef7:e6f5/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever

2. Configure Calico MTU

2.1. 將 MTU 設為 5950

$ kubectl patch configmap/calico-config -n kube-system --type merge \
-p '{"data":{"veth_mtu": "5950"}}'

2.2. Rolling restart of all calico/node pods.

$ kubectl rollout restart daemonset calico-node -n kube-system

2.3. Check Calico pod Status

$ kubectl -n kube-system get pods -l "k8s-app=calico-node"

正確執行結果 :

NAME READY STATUS RESTARTS AGE
calico-node-2fxx7 1/1 Running 0 64s
calico-node-cw58f 1/1 Running 0 53s
calico-node-x872p 1/1 Running 0 74s

3. Testing Connectivity Between Kubernetes Pods with Iperf3

3.1. Deploy Iperf3 as a DaemonSet

$ echo 'apiVersion: apps/v1
kind: DaemonSet
metadata:
name: iperf3-ds
spec:
selector:
matchLabels:
app: iperf3
template:
metadata:
labels:
app: iperf3
spec:
containers:
- name: iperf3
image: leodotcloud/swiss-army-knife
ports:
- containerPort: 5201' > ~/iperf3-ds.yaml

3.2. Create the DaemonSet

$ kubectl apply -f iperf3-ds.yaml

3.3. Check that iperf3 pods are running on all nodes in the cluster

$ kubectl get pods -l "app=iperf3" -o wide

執行結果如下 :

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
iperf3-ds-49bwz 1/1 Running 0 32m 10.244.166.25 c31-worker2 <none> <none>
iperf3-ds-9bhn5 1/1 Running 0 32m 10.244.146.203 c31-control-plane <none> <none>
iperf3-ds-tdfw9 1/1 Running 0 32m 10.244.152.26 c31-worker <none> <none>

3.4. Choose a pod to run in server mode

$ kubectl exec -it iperf3-ds-tdfw9 -- iperf3 -s -p 12345

執行結果如下 :

-----------------------------------------------------------
Server listening on 12345
-----------------------------------------------------------

3.5. Choose a pod to run in client mode

$ kubectl exec -it iperf3-ds-49bwz -- iperf3 -c 10.244.152.26 -p 12345

執行結果如下 :

Connecting to host 10.244.152.26, port 12345
[ 4] local 10.244.166.25 port 36468 connected to 10.244.152.26 port 12345
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 1.89 GBytes 16.2 Gbits/sec 112 933 KBytes
[ 4] 1.00-2.00 sec 1.85 GBytes 15.9 Gbits/sec 83 979 KBytes
[ 4] 2.00-3.00 sec 1.90 GBytes 16.3 Gbits/sec 121 1.20 MBytes
[ 4] 3.00-4.00 sec 1.92 GBytes 16.5 Gbits/sec 0 1.20 MBytes
[ 4] 4.00-5.00 sec 1.91 GBytes 16.4 Gbits/sec 154 1.20 MBytes
[ 4] 5.00-6.00 sec 1.89 GBytes 16.3 Gbits/sec 0 1.20 MBytes
[ 4] 6.00-7.00 sec 1.88 GBytes 16.2 Gbits/sec 188 1.21 MBytes
[ 4] 7.00-8.00 sec 1.88 GBytes 16.1 Gbits/sec 0 1.21 MBytes
[ 4] 8.00-9.00 sec 1.91 GBytes 16.4 Gbits/sec 238 1.48 MBytes
[ 4] 9.00-10.00 sec 1.85 GBytes 15.9 Gbits/sec 0 1.48 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 18.9 GBytes 16.2 Gbits/sec 896 sender
[ 4] 0.00-10.00 sec 18.9 GBytes 16.2 Gbits/sec receiver
iperf Done.

4. 測試 K8s Pod 網路效能

4.1. 原始 podman network MTU 改 1500, Calico 改 1480

$ kubectl exec -it iperf3-ds-676l2 -- iperf3 -c 10.244.152.26 -p 12345

執行結果如下 :

Connecting to host 10.244.152.26, port 12345
[ 4] local 10.244.166.23 port 44364 connected to 10.244.152.26 port 12345
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 1.50 GBytes 12.9 Gbits/sec 135 1.50 MBytes
[ 4] 1.00-2.00 sec 1.49 GBytes 12.8 Gbits/sec 0 1.52 MBytes
[ 4] 2.00-3.00 sec 1.50 GBytes 12.9 Gbits/sec 0 1.52 MBytes
[ 4] 3.00-4.00 sec 1.50 GBytes 12.8 Gbits/sec 646 1.55 MBytes
[ 4] 4.00-5.00 sec 1.51 GBytes 12.9 Gbits/sec 1659 1.09 MBytes
[ 4] 5.00-6.00 sec 1.37 GBytes 11.8 Gbits/sec 0 1.09 MBytes
[ 4] 6.00-7.00 sec 1.49 GBytes 12.8 Gbits/sec 656 1.10 MBytes
[ 4] 7.00-8.00 sec 1.50 GBytes 12.9 Gbits/sec 630 1.12 MBytes
[ 4] 8.00-9.00 sec 1.44 GBytes 12.4 Gbits/sec 438 1.13 MBytes
[ 4] 9.00-10.00 sec 1.50 GBytes 12.9 Gbits/sec 703 1.15 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 14.8 GBytes 12.7 Gbits/sec 4867 sender
[ 4] 0.00-10.00 sec 14.8 GBytes 12.7 Gbits/sec receiver
iperf Done.

4.2. podman network MTU 改 9000, Calico 改 8950

$ kubectl exec -it iperf3-ds-rlsnj -- iperf3 -c 10.244.152.36 -p 12345

執行結果如下 :

Connecting to host 10.244.152.36, port 12345
[ 4] local 10.244.166.33 port 54388 connected to 10.244.152.36 port 12345
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 1.81 GBytes 15.5 Gbits/sec 7 3.57 MBytes
[ 4] 1.00-2.00 sec 1.85 GBytes 15.9 Gbits/sec 0 3.60 MBytes
[ 4] 2.00-3.00 sec 1.83 GBytes 15.8 Gbits/sec 0 3.60 MBytes
[ 4] 3.00-4.00 sec 1.84 GBytes 15.8 Gbits/sec 0 3.66 MBytes
[ 4] 4.00-5.00 sec 1.81 GBytes 15.5 Gbits/sec 0 3.66 MBytes
[ 4] 5.00-6.00 sec 1.80 GBytes 15.5 Gbits/sec 0 3.66 MBytes
[ 4] 6.00-7.00 sec 1.78 GBytes 15.3 Gbits/sec 0 4.18 MBytes
[ 4] 7.00-8.00 sec 1.82 GBytes 15.7 Gbits/sec 0 4.18 MBytes
[ 4] 8.00-9.00 sec 1.83 GBytes 15.7 Gbits/sec 0 4.18 MBytes
[ 4] 9.00-10.00 sec 1.79 GBytes 15.4 Gbits/sec 0 4.18 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 18.2 GBytes 15.6 Gbits/sec 7 sender
[ 4] 0.00-10.00 sec 18.2 GBytes 15.6 Gbits/sec receiver
iperf Done.

Ref

使用 Certbot 命令列工具建立免費的 TLS/SSL 網域憑證

Mon, 22 Apr 2024 06:45:10 +0800

環境 : SLES 15 SP5 事前準備 : 一個 Public 的 Domain，跟一個對外 IP

# 安裝 Certbot
$ sudo zypper -n in certbot
$ certbot --version
certbot 1.22.0
# 產生 SSL/TLS 憑證
$ sudo certbot certonly --manual -m sreantony@gmail.com -d antony520.com -d *.antony520.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf. You must agree in
order to register with the ACME server. Do you agree?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
## 輸入 y 同意服務使用條款
(Y)es/(N)o:y
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing, once your first certificate is successfully issued, to
share your email address with the Electronic Frontier Foundation, a founding
partner of the Let's Encrypt project and the non-profit organization that
develops Certbot? We'd like to send you email about our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
## 輸入 y ，E-mail 自動註冊為 ACME 帳戶
(Y)es/(N)o:y
Account registered.
Requesting a certificate for antony520.com and *.antony520.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name:
_acme-challenge.antony520.com.
with the following value:
XHp6PGqSI6mY727g8XnlLyYVzbgOBVYsgT_cOtg_1AI
Before continuing, verify the TXT record has been deployed. Depending on the DNS
provider, this may take some time, from a few seconds to multiple minutes. You can
check if it has finished deploying with aid of online tools, such as the Google
Admin Toolbox: https://toolbox.googleapps.com/apps/dig/#TXT/_acme-challenge.antony520.com.
Look for one or more bolded line(s) below the line ';ANSWER'. It should show the
value(s) you've just added.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Create a file containing just this data:
4oAGvPw9KSDg4RArSZoz7bKIAiGASyweV9F09u92f4E.o3vn2SL8r66xEEAkIAQ9cLJqpbdwUl21aDsOrJ1RkOY
And make it available on your web server at this URL:
http://antony520.com/.well-known/acme-challenge/4oAGvPw9KSDg4RArSZoz7bKIAiGASyweV9F09u92f4E
(This must be set up in addition to the previous challenges; do not remove,
replace, or undo the previous challenge tasks yet.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue

Cloudflare Tunnel

$ sudo zypper -n in podman
$ sudo podman run -d --name cloudflare-tunnel --network=host cloudflare/cloudflared:latest tunnel --no-autoupdate run --token eyJhIjoiN2IzYTVlMTUxZjQ3Mjc3NjNkZTA5OGE3Mjk3ZDQ2OTEiLCJ0IjoiNWE0MWY1YTQtZmJkZC00MDkxLThhYWQtNGMyMWNiNjJmYzMwIiwicyI6Ik5USXdaVEEyWWpVdE5UY3lZeTAwWWpSaExUbGlOelV0TjJJd1ltRTVZbVE0WVRneCJ9

Cert-manager with SelfSigned Issuers

Mon, 15 Apr 2024 06:23:06 +0800

實作目標

透過 Cert-manager 產生自簽 CA 憑證，再透過這個自簽的 CA 憑證簽發給 Ingress 用的 TLS 憑證，最後建一個 Nginx 來測試 TLS Ingress 是否符合預期，且憑證到期時間會自動更新。

先備知識

Issuer

Issuers 和 ClusterIssuers 是 Kubernetes 中的資源，代表著憑證授權機構（certificate authorities [CAs]），它們可以通過證書簽名請求 ( certificate signing requests )來生成簽名的證書 ( signed certificates )。

# 建立工作目錄
$ mkdir -p ~/wulin/cert-manager && cd ~/wulin/cert-manager
# 建立 selfsigned Issuer
$ cat <<EOF > default-selfsigned-issuer
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: selfsigned-issuer
namespace: default
spec:
selfSigned: {}
EOF
$ kubectl apply -f default-selfsigned-issuer
# 檢查 Issuer 的狀態
$ kubectl get issuers selfsigned-issuer -o wide
NAME READY STATUS AGE
selfsigned-issuer True 15d
# Bootstrapping CA Issuers
$ cat <<EOF > default-ca.certificate.yaml
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: my-selfsigned-ca
namespace: default
spec:
isCA: true
commonName: my-selfsigned-ca
secretName: root-secret
subject:
organizations:
- Lab
organizationalUnits:
- Test
duration: 2h
renewBefore: 1h
privateKey:
algorithm: ECDSA
size: 256
issuerRef:
name: selfsigned-issuer
kind: Issuer
group: cert-manager.io
EOF
$ kubectl apply -f default-ca.certificate.yaml
# 可以看到 root-secret ( CA 憑證 ) 已經被自動生成，並存在 Secret 中
$ kubectl get certificate my-selfsigned-ca -o wide
NAME READY SECRET ISSUER STATUS AGE
my-selfsigned-ca True root-secret selfsigned-issuer Certificate is up to date and has not expired 22s
# 檢視 root-secret
$ kubectl get secret root-secret -o yaml
apiVersion: v1
data:
ca.crt:
...
tls.crt:
...
tls.key:
...
#
$ cat <<EOF > default-my-ca-issuer.yaml
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: my-ca-issuer
namespace: default
spec:
ca:
secretName: root-secret
EOF
$ kubectl apply -f default-my-ca-issuer.yaml
$ kubectl get issuers my-ca-issuer -o wide
NAME READY STATUS AGE
my-ca-issuer True Signing CA verified 8m12s

Run Nginx with TLS Ingress

$ kubectl run nginx --image=harbor.example.com/rancher/library-nginx:1.19.2-alpine -l run=nginx
$ kubectl get pods -l run=nginx -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 18s 10.42.44.57 k2w1 <none> <none>
$ NGINX_PodIP=$(kubectl get pods -l run=nginx -o custom-columns=POD_IP:.status.podIP --no-headers)
$ curl http://$NGINX_PodIP
...
<title>Welcome to nginx!</title>
...
# Create TLS Ingress
$ cat <<EOF > default-tls-nginx-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: tls-nginx-ingress
namespace: default
annotations:
# add an annotation indicating the issuer to use.
cert-manager.io/issuer: my-ca-issuer
spec:
ingressClassName: nginx
tls:
- hosts:
- 192.168.11.174.nip.io
secretName: tls-nginx-ingress
rules:
- host: 192.168.11.174.nip.io
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx
port:
number: 80
EOF
# 檢視 Ingress 部屬狀態
$ kubectl get ing
NAME CLASS HOSTS ADDRESS PORTS AGE
tls-nginx-ingress nginx 192.168.11.174.nip.io 192.168.11.173,192.168.11.174 80, 443 45s
# 測試透過 Ingress 連接網站
$ curl -k https://192.168.11.174.nip.io
...
<title>Welcome to nginx!</title>
...
# 匯出 CA 憑證
$ kubectl get secret root-secret -o jsonpath='{.data.ca\.crt}' | base64 -d >
ing-ca.crt
$ sudo cp ing-ca.crt /etc/pki/ca-trust/source/anchors/ && sudo sudo update-ca-trust
# 這次 curl 就不用加 -k 跳過憑證確認了
$ curl https://192.168.11.174.nip.io
...
<title>Welcome to nginx!</title>
...
# 檢視憑證過期日期
$ echo | openssl s_client -connect 192.168.11.174.nip.io:443 2>/dev/null | openssl x509 -noout -dates
notBefore=Apr 15 03:08:33 2024 GMT
notAfter=Jul 14 03:08:33 2024 GMT
# 下載 Cert-manager 管理工具
$ curl -fsSL -o cmctl.tar.gz https://github.com/cert-manager/cert-manager/releases/latest/download/cmctl-linux-amd64.tar.gz && tar xzf cmctl.tar.gz && sudo mv cmctl /usr/local/bin
# 手動 renew 憑證到期日期
$ cmctl renew tls-nginx-ingress
Manually triggered issuance of Certificate default/tls-nginx-ingress
$ echo | openssl s_client -connect 192.168.11.174.nip.io:443 2>/dev/null | openssl x509 -noout -dates
notBefore=Apr 15 03:32:44 2024 GMT
notAfter=Jul 14 03:32:44 2024 GMT
# 清除環境
$ kubectl delete -f ./ && kubectl delete pod nginx
certificate.cert-manager.io "my-selfsigned-ca" deleted
issuer.cert-manager.io "my-ca-issuer" deleted
issuer.cert-manager.io "selfsigned-issuer" deleted
ingress.networking.k8s.io "tls-nginx-ingress" deleted
pod "nginx" deleted

流程圖解

https://cert-manager.io/docs/usage/ingress/#inner-workings-diagram-for-developers

Set Static IP Address on RHEL 9 with nmcli

Wed, 20 Mar 2024 05:18:14 +0800

Get the Interface Name

$ sudo nmcli dev

nmcli - command-line tool for controlling NetworkManager

d[evice]，devices managed by NetworkManager

螢幕輸出 :

DEVICE TYPE STATE CONNECTION
ens18 ethernet connected ens18
lo loopback unmanaged --

View Current Connection

$ sudo nmcli con show

螢幕輸出 :

NAME UUID TYPE DEVICE
ens18 5c5b3cd8-d3f4-46f7-b361-253541ee2d13 ethernet ens18

設定網路

$ sudo nmcli con modify 'ens18' \
ipv4.method manual \
ipv4.addresses 192.168.11.91/24 \
gw4 192.168.11.254 \
ipv4.dns 8.8.8.8

IP: 192.168.11.91 Netmask: 255.255.255.0 Gateway: 192.168.1.254 Dns Server: 8.8.8.8

新增 DNS Server

$ sudo nmcli connection modify 'Wired connection 1' +ipv4.dns 8.8.8.8

重啟 NetworkManager 服務

$ sudo systemctl restart NetworkManager

啟動網路連線

$ sudo nmcli con up 'ens18'

設定系統重啟後自動連線

$ sudo nmcli con modify 'ens18' connection.autoconnect yes

設定 Hostname

$ sudo hostnamectl set-hostname <new-hostname>

確認已更改 Hostname

$ sudo hostnamectl

關閉 IPv6

$ sudo nmcli connection modify 'Wired connection 1' ipv6.method "disabled"

重啟 NetworkManager 服務

$ sudo systemctl restart NetworkManager

更新 Default Gateway 設定

$ sudo nmcli con modify ens18 ipv4.gateway 192.168.11.253
## Restart the network connection for changes to take effect.
$ sudo nmcli connection up ens18

參考資料

How to Set Static IP Address on RHEL 9

Linux Network Block Devices

Wed, 20 Dec 2023 01:59:12 +0800

Preface

本篇文章會主要會介紹 Linux Network Block Devices 的架構和運作

可以透過點擊以下目錄，選擇想看的內容，跳轉至特定章節

What is Network block devices (NBD)?

Network block devices (NBD) 是 client/server 架構，server 提供遠端儲存裝置或檔案，給 client 對應為本地裝置檔，可開機等。也可以格式化、modify or copy 整個分割。

在 Client 主機將 NBD 編譯到核心（或作為模組）後，Linux 可以將遠端伺服器作為其區塊裝置之一。這樣，每當客戶端電腦要讀取 /dev/nb0 等資料時，它就會透過 TCP 向伺服器發送請求，伺服器會回覆讀取的資料。這可用於磁碟空間較小的站點（甚至無磁碟）從另一台電腦借用磁碟空間。與 NFS 不同的是，它可以放置任何檔案系統等。

Remove secondary IP with nmcli

Mon, 30 Oct 2023 08:33:54 +0800

# nmcli con modify "eth0" ipv4.addresses "" ipv4.gateway ""
# nmcli con down eth0
Connection 'eth0' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/5)
# nmcli con up eth0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/6)
# ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:07:32:6f:6e:fe brd ff:ff:ff:ff:ff:ff
altname enp3s0
inet 192.168.50.203/24 brd 192.168.50.255 scope global dynamic noprefixroute eth0
valid_lft 86397sec preferred_lft 86397sec
inet6 fe80::207:32ff:fe6f:6efe/64 scope link noprefixroute
valid_lft forever preferred_lft forever
# sudo nmcli connection modify 'eth0' ipv4.method manual ipv4.addresses 192.168.50.151/24 gw4 192.168.50.254 ipv4.dns 168.95.1.1 +ipv4.dns 192.168.50.254
# nmcli con down eth0
Connection 'eth0' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/6)
# nmcli con up eth0
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7)
# ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:07:32:6f:6e:fe brd ff:ff:ff:ff:ff:ff
altname enp3s0
inet 192.168.50.151/24 brd 192.168.50.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet6 fe80::207:32ff:fe6f:6efe/64 scope link noprefixroute
valid_lft forever preferred_lft forever

eth1

$ sudo nmcli connection modify 'eth1' ipv4.method manual ipv4.addresses 192.168.1.172/24 gw4 192.168.1.1 ipv4.dns 8.8.8.8 +ipv4.dns 168.95.1.1

Self-Signed SSL Certificates

Fri, 14 Apr 2023 05:26:22 +0800

什麼是自簽憑證（self-signed certificate）？

HTTPS 在網站安全性上有兩層作用，

訪客與網站之間的資料傳輸有經過加密，若中途攔截下來是無法被解讀的。
網頁瀏覽器在建立加密連線前，會先檢查網站的 SSL 憑證是否為受信任的第三方機構所簽發。若有，瀏覽器會判定網站來源無虞，反之則會出現警示。

自簽署（self-signed）的 SSL 憑證，為未經過公共信任的憑證授權中心（CA）的核可，自行利用工具(如 : OpenSSL)產生的憑證。它一樣具有加密連線的效果，但訪客將需要忽略瀏覽器警示，才能夠開啟網站。

簡單來說，這些自簽憑證是基於 X.509 憑證中使用的加密私鑰和公鑰對架構。此外，自簽 SSL 憑證使用與其他付費 SSL/TLS 憑證相同的加密方法來加密相關的傳入和傳出數據。

在發行過程中缺乏獨立驗證會產生額外的風險，這就是自簽憑證的問題。它們被認為對於公開面向的網站和應用程序來說是不安全的。

用途

雖然自簽憑證可能會有風險，但它們也有其用途。主要是因為它們不需要花費，而且任何開發人員都可以輕鬆地申請使用。它們可以按照自己的時間表實現，通常用於內部測試環境或對外部用戶受限的 Web 伺服器。

風險

自簽憑證不需要在一定時間後過期或需要更新，這與 CA 憑證的要求不同。雖然這似乎很方便，但這也是這種選擇的主要問題之一，因為它們無法遵從針對發現的漏洞的安全更新，也無法滿足保障現代企業所需的憑證靈活性。因此，這種身份驗證方法很少被建議使用。

此外，自簽憑證無法撤銷，如果憑證被遺忘或留在容易受到惡意攻擊的系統上，將暴露出所使用的加密方式。即使如此，一些 IT 部門仍然認為由授權中心發行的憑證的成本超過了額外驗證和支持減少的風險。

使用自簽名 SSL 憑證會出現安全警告，讓網站訪客感到擔心和不安。這些警告會讓網站看起來可能被入侵，而且無法保障訪客的數據安全。訪客會傾向於避免這些網站，轉而去看沒有安全警告的競爭對手網站。

可以理解的是，如果訪客的信任網頁瀏覽器告訴他們該網站可能缺乏適當的安全措施，他們將不太可能在該網站上共享任何個人或機密信息。使用自簽名憑證可能會被利用，其中一種流行的方法是中間人攻擊，讓透過 TLS/SSL 協議共享的數據被監視，讓訪客面臨身份盜用和系統入侵的風險。

如果選擇使用這種類型的 SSL 憑證，您將處於孤立無援的狀態，因為您沒有受信任的憑證授權機構支持，也無法應用最新的加密方法，以確保數據、設備和應用程序的適當身份驗證和加密。

What is Certificate Authority

在網路世界裏，當我們打開瀏覽器要訪問一個網站時，為了確保對方的身分，通常都會讓一個中間機構扮演認證的角色，這個角色就是所謂的數位憑證認證機構（Certificate Authority，CA），也可以被稱為「電子商務認證中心」、「電子商務認證授權機構」

CA 最主要的工作，就是負責發放和管理數位憑證的權威機構，檢核公鑰合法性。

Self-Signed SSL Certificates: Basic Requirements

The basic requirements for local SSL hosting, and setting up self-signed SSL in general, are:

A private key (.pem)
A CSR (Certificate Signing Request)
A public certificate (usually .crt, sometimes .pemtoo)

The CSR is kind of intermediate step between the key and the cert (the CSR is signed by the key to become the cert, so in many cases it is temporarily created via a prompt). You can think of the cert as being derived from the key, via the CSR.

💡 SSL cert pairs are often referred to with the X.509identifier; this is essentially the standard that is used for TLS/SSL, but it is used for other purposes as well.

參考網站

網路基礎

Fri, 01 Jul 2022 09:10:00 +0800

Ethernet(乙太網路)

由網路卡，網路設備和網路線所組成我們現在的電腦有線網路設備，例：電腦主機上的埠、switch上的埠或是實體網路線，都是Ethernet的規格。

port:中文為埠

Switch 網路交換器

以學校教室的Switch為例，如下圖這台switch是由ZYXEL公司賣的，它有48個孔，一台電腦有一個網路，用一條網路線連到它的孔，第二台電腦也有一條網路線連到它的第二個孔，所以可以有48台電腦可以連到48個孔，此時這48台電腦可以透過這台switch互相傳資料給對方

switch有什麼功用？可以讓多台電腦互相交換資料

在Ethernet這種網路下，電腦之間要溝通時候需要知道對方的MAC位址才能傳資料過去

什麼是MAC位置？每一張網路卡都有一個MAC位址，全世界絕對不會有相同的MAC位址的網路卡或設備，MAC位址一律使用16進位。

16進位：0 ~ 9，A ~ F。
如何確定MAC(Media Access Control)位址? 在windows系統下，執行ipconfig /all

C:\Users\ybean>ipconfig /all
...以上省略
乙太網路卡 乙太網路:
連線特定 DNS 尾碼 . . . . . . . . : mcu.edu.tw
描述 . . . . . . . . . . . . . . .: Intel(R) Ethernet Connection (7) I219-LM
實體位址 . . . . . . . . . . . . .: C8-D9-D2-04-57-3D
...以下省略

可以看到第三行的“實體位址”，就是MAC位址，以這台電腦為例：C8-D9-D2-04-57-3D就是他的MAC位址。

VMware 公司出廠的mac address 前3碼一定是 00-50-56

Protocol:電腦之間溝通的語言

ARP(Adress Resolution Protocol)通訊協定

電腦跟電腦之間有很多的通訊協定/語言，就像人跟人之間有很多語言，下面介紹一下Adress Resolution Protocol，簡稱ARP

基本上，在 Ethernet 網路上傳送訊息，都必須以 Ethernet 封包格式封裝，來源位址與目的位址也都必須是 Ethernet Address 格式(48 bits)。但在 TCP/IP 網路上傳送訊息又都以 IP Address格式(32 bits)，那 Ethernet 與 IP 位址之間的轉換機制，則須仰賴 ARP 協定來達成。

ARP運作方式圖如下：以上圖為例，假設今天Ａ電腦要透過 Ethernet 網路傳送訊息給 IP = 120.96.143.153的C電腦，首先第一步

會到Switch上面廣播：誰是120.96.143.153? 所有連在Switch上面的主機都會接收到廣播，並分解是否詢問自己，如果不是就不予理會而拋棄。
如果是，則電腦 C（120.96.143.153）收到廣播，發現詢問自己則回應自己的ＩＰ位址（120.96.143.153）以及ＭＡＣ位址（C8-D9-D2-04-54-39）給發問者(120.96.143.151)，也就是Ａ電腦，此時Ａ電腦會儲存ARP廣播後收到的ＩＰ位址和ＭＡＣ位址，這樣下次就不用再問一次。

2022/02/28陳松林老師上課的白板圖

ARP通訊協定主要功能使用對方的ＩＰ位址取得對方的ＭＡＣ位址
什麼時候會啟用ＡＲＰ通訊協定？ ping、http

有關ARP的參考資料來自ARP 協定與分析

重點整理：

簡單來說Ethernet這種網路下，硬體層面電腦要互相做資料的溝通一定要透過MAC，沒得商量！

可是由於MAC的長度太長沒人背得起來，所以在電腦裡面還有一個給人看的IP位址，也就是TCP/IP網路他在運作的位址，這時候就需要一種通訊語言(protocol)，把我們看得懂的IP轉換成真正通訊的MAC，而這個通訊協定就是ARP。

IP address就是一台電腦在網路上的位址，而MAC address則是製造商指定給網路硬體（像是無線網卡、有線網卡）的獨特編碼。

就好像終端機上面有貝殼程式;電腦上有cpu、memory、HardDisk和網路，上面可以跑os；Ethernet網路的硬體，網路卡、網路線和Switch，這個硬體要傳資料一定要透過MAC，硬體有了之後，上面跑的軟體是TCP/IP，這個system有一個protocol叫做ARP，他可以把對方的IP位址轉換成MAC位址。

4/16更新ARP通訊協定

當Host A要傳給Host B資料時，第一步Host A主機會先檢查自己的ARP cache有沒有Host B的MAC位址，如果沒有紀錄，

第一步

它就會進到第二部，在Switch上面廣播"ARP requset"，ARP requset裡面會有：

Host A自己的IP address 和 MAC address
Host B的IP address和MAC address，但因為這時候不知道，所以顯示都是00:00:00:00:00:00（ 00:00:00:00:00:00 ）

第二步

第三部 Host B主機收到ARP request後，會在自己這邊的ARP cache紀錄Host A主機的MAC Address

第四部 Host B主機會將自己的IP位址和MAC address位址傳給Host A

第五部 Host A主機把收到的Host B 主機的IP位址和MAC address紀錄起來

鎖定網路卡
我們現在用線鯊，到這個網路卡上面，
選這張網路卡的原因是因為，他負責連接我們那兩台機器，
所以我們就可以用線鯊到這張網路卡上面，收取底層的封包
等下我們應該就會看到 ARP 的封包
封包會分成很多層
Ethernet 網路硬體上，送出去的資料區塊，我們稱它為封包
裡面的 mac address ，只要是一片 f ，就會造成那個硬體在
那個網路上面，把所有的封包送給所有電腦，這就是廣播的意思。
你看到這個 Ethernet 2 裡面的資訊，就是要來操控我們的硬體
軟體的部分在下面。

tags: `網路基礎`

`Ping` 命令的運作

Wed, 22 Jun 2022 08:57:24 +0800

2022/06/04 學習目標

`Ping` 命令的運作

Mac 電腦 ip ：120.96.143.120/24
Win10 電腦 ip ：120.96.143.250/25

Ping 的icmp封包一定是有去有回。 Ethernet 有線網路，機器之間要連線一定會會透過 Mac Address 來溝通。

運作流程當 Mac 電腦要 ping 120.96.143.250 (Win10 電腦)時，在 Mac 電腦上會先做兩次 and 運算，

先用自己的 ip 和自己的 subnet mask 做 and 運算

再用對方的 ip 位址和自己的 subnet mask 做 and 運算

第一次 | 第二次
120.96.143.120 | 120.96.143.250
255.255.255.0 & | 255.255.255.0 &
---------------- | ------------------
120.96.143.0 = 120.96.143.0 ---> 兩個 Network ID 一樣

如果 Network ID 一樣，封包就會從 Mac 電腦透過 ARP 通訊協定傳到 win10 電腦。
如果 Network ID 不同，封包就會送到 Default Gateway 。

當 win10 電腦收到封包以後會回傳，此時在 win10 電腦也會做兩次 and 運算

先用自己的 ip 和自己的 subnet mask 做 and 運算

再用對方的 ip 位址和自己的 subnet mask 做 and 運算

第一次 | 第二次
120.96.143.250 | 120.96.143.120
255.255.255.128 & | 255.255.255.128 &
---------------- | ------------------
120.96.143.128 != 120.96.143.0 ---> 兩個 Network ID 不一樣

Network ID 相同就會透過 ARP 傳送封包給 Mac 電腦。
如果 Network ID 不同，封包就會送到 Default Gateway 。

小結論

相同 Network ID 就會啟動 ARP 通訊協定將封包送達。
不同 Network ID 一定會將封包送達 Default Gateway。

額外補充

mac address 的前三碼，同一品牌都會一樣，可用 mac address 直接辨認網卡。
- 00:23:05，J409電腦的 MAC address

實體 Ethernet 有線網路建構

定義 : 由1個或多個 Switch 負責連接一個區域內，所有的有線網路。

提問 : 如果一間教室有 31 台電腦，要用幾台 Switch ( 一台 5 port ) 來建構教室網路?

答 :

如果用這種串聯的方式建構教室網路，最左上角的 Switch 連到的電腦要傳資料給右下角連接 Switch 的電腦，會經過 10 台 Switch 才能將資料傳送到，太過耗時和耗資源，此方法不合適。

應該選擇 2 台主要的 Switch 互相連接 8 台 Switch ，再由 8 台 Switch 去連接教室所有的電腦，這樣電腦與電腦之間要傳資料，只需經過 4 台 Switch 。
企業沒錢請人來做高架地板，將網路線埋到地下，然後買一台 48 port 的 Switch 就只能照上面的方法做。

銘傳大學比較有錢，兩間教室都做高架地板，將網路線埋到地下，然後用一個 48 port 的 Switch 將所有電腦的有線網路，通通連接在一起。

Routing Table

ip_forward 永久開啟

$ echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf

免重啟立即生效指令

$ sudo sysctl -p

開啟封包轉送後，再

新增 Routing Table

$ sudo route add -net $destination netmask $SubnetMask gw $GWIP
# -net -> 目的地 network ID
# netmask -> 目的地子網路遮罩
# gw -> gateway

以上指令只要重新開機就會重置

永久修改 Routing Table

$ sudo nano /etc/local.d/route_set.start
#!/bin/sh
route add -net $destination netmask $SubnetMask gw $GWIP
## 賦予執行權限
$ sudo chmod +x /etc/local.d/route_set.start
## 啟用開機執行檔功能
$ sudo rc-update add local
##　重新開機
$ sudo reboot

要記得安裝 bash !!!

練習

當 IP 位址尾數 11 的電腦要 ping 192.168.55.21 可以通時，要做以下設定

## 在他的 Alpine Linux 上先開啟封包轉送
$ echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
## 免重啟立即生效 ip_forward
$ sudo sysctl -p
## 新增 Routing Table
$ sudo route add -net 192.168.55.0 netmask 255.255.255.0 gw 192.168.55.254

而 IP 位址尾數 21 的電腦也要做以下設定

## 在他的 Alpine Linux 上先開啟封包轉送
$ echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
## 免重啟立即生效 ip_forward
$ sudo sysctl -p
## 新增 Routing Table
$ sudo route add -net 192.168.66.0 netmask 255.255.255.0 gw 192.168.66.254/25

兩者都做完設定後，就可以在 IP 位址尾數 11 的電腦 ping 192.168.55.21 囉 ~

tags: `網路基礎`

VMWare Player 的網路模式

Sat, 04 Jun 2022 11:45:16 +0800

Bridge 網路模式

在Bridge網路模式下，我們的VM會透過bridge虛擬橋接器，連到實體機器的網卡上網代表虛擬機器所連接的網路和windows的實體電腦在同一個網路

Host-Only

在Host only 網路模式下，我們的VM無法上網，只能跟相同Network ID的VM互連，如果想連到不同Network ID的網路，就必須在VM設定 routing 或 NAT 的服務

NAT

封包偽裝（IP masquerade）：可以將VM的私有 IP（內部IP）改變成真實 IP（外部 IP）再傳送到網際網路，使網路上的人無法得知私有網路的 IP 分配情形而增加網路安全性。

tags: `網路基礎`

TCP/IP 通訊協定

Sat, 04 Jun 2022 11:45:04 +0800

準備環境

下載WiresharkPortable64_3.6.3.paf.exe

下載連結，請點我

Wire 電線 shark 鯊魚 Wireshark 中文簡稱：線鯊

學習筆記本

TCP/IP學習筆記本

鳥哥基礎網路概念

Ethernet 乙太網路

電腦的網路系統分兩大類

有線網路
- 硬體規格：Ethernet
  - 組成：乙太網路卡、網路連接設備和網路線
    - 網路卡：重點在速度
    - 網路連接設備：讓很多電腦能夠互通傳遞資訊
    - 網路線：傳遞資訊
- IP Address
  - 格式：由 Network ID ＋ Host ID 組成
    
    Network ID Host ID
  - Network ID 由IP 位址和子網路遮罩做and運算得出因為Router負責幫我們在網路上傳遞訊息，為了不為難Router，於是我們把IP位址頭一組數字相同的IP放在一起，這樣Router就只要記同一堆電腦的第一組數字位置，而不需要記錄到每一台電腦的IP Address。
- ==電腦之間要溝通除了軟體層的IP Address還要有硬體層的Mac Address==
- Mac Address
  - 定義：實體網路卡的出廠代號（16進位）
    C:\Users\ybean>ipconfig /all 乙太網路卡乙太網路: ... 實體位址 . . . . . . . . . . . . .: C8-D9-D2-04-57-3D ... 乙太網路卡 VMware Network Adapter VMnet1: ... 實體位址 . . . . . . . . . . . . .: 00-50-56-C0-00-01 ...
    VMware的Mac Address開頭一定是00-50-56
  - 電腦跟電腦之間溝通要透過Mac address，但是很難記怎麼辦？答：靠ARP 通訊協定
  - 功能：根據IP Address，幫我們把資料傳給對方
- ARP 通訊協定（Address Resolution Protocal）
  - 他負責把IP位址轉換成Mac Address
無線網路
- 辦公室、學校和手機會使用

一個網段要怎麼配置IP位址

口訣：去頭去尾中間切一半，前十給IP Server，後面5個給網路設備（Switch不會有），剩下的前面手動設定IP位址，後面的給DHCP Server配發

以下用J409教室的網段當範例：

120.96.143.128 Network ID
120.96.143.129 ~ 120.96.143.138 IP Server
120.96.143.139 ~ 120.96.143.190 (手動設定IP)
120.96.143.191 ~ 120.96.143.249 (DHCP Server)
120.96.143.250 ~ 120.96.143.254 Network Device (Router)
120.96.143.255 Broadcast

設定固定 IP 位址(Alpine linux)

$ sudo nano /etc/network/interfaces
auto lo
iface lo inet loopback
#auto eth0
#iface eth0 inet dhcp
auto eth0 (auto 的意思是作業系統一起來，就啟動這張網卡)
iface eth0 inet static （iface 全名就是interface ，static 代表固定ＩＰ）
address 120.96.143.180/25
gateway 120.96.143.254 （Router的ＩＰ位址就是120.96.143.254）

重啟網路服務

$ sudo /etc/init.d/networking restart

在區域網路下，電腦的IP位址在相同的Network ID，就可以透過網路設備Switch互相溝通，Network ID的算法為IP位址跟遮罩作AND運算 TCP/IP屬於軟體層的標準，真正硬體層(Ethernet)在溝通靠的是Mac address

當我們電腦要上網到不同的Network id，電腦就要透過Router的IP位址，才能出去上網，而Router的IP位址就是Deafault Gateway，Router出去以後會透過海底電纜，到其他台Router傳送封包，再到另一個Router，到達我們的8.8.8.8這台主機，

Router(路由器)是走海底電纜傳輸至國外，會有多種路徑規劃選擇而經過周轉的Router越少傳送速度越快，最少的就是最佳路徑

網路等級

公有 IP

IP等級	最低位址	~	最高位址
A	0.0.0.0	~	127.255.255.255
B	128.0.0.0	~	191.255.255.255
C	192.0.0.0	~	223.255.255.2555

私有 IP

Address Resolution Protocol (ARP 通訊協定)

當Host A要傳給Host B資料時， Host A主機會先檢查自己的ARP cache（存放在記憶體裡）有沒有Host B的MAC位址，如果沒有紀錄，

它就會進到第二部，在Switch上面廣播"ARP requset"的封包

ARP requset 內容：
- Host A自己的IP address 和 MAC address
- Host B的IP Address和MAC Address，但因為這時候不知道Mac Address，所以顯示都是00:00:00:00:00:00（ 00:00:00:00:00:00 ）

廣播的意思：連接在Switch上面的所有電腦都會收到 (同一個Network ID 上面)

第三部 Host B主機收到ARP request後，會在自己這邊的ARP cache紀錄Host A主機的IP Address 和MAC Address

Host B主機會將自己的IP位址和MAC address位址傳給Host A

第五部 Host A主機把收到的Host B 主機的IP位址和MAC address紀錄起來

ARP實戰

登入m1虛擬機

C:\Users\ybean>ssh bigred@192.168.61.4

arp 命令在任何linux作業系統都是內建的

bigred@m1:~$ arp --help
BusyBox v1.34.1 (2022-04-04 10:19:27 UTC) multi-call binary.
Usage: arp
[-vn] [-H HWTYPE] [-i IF] -a [HOSTNAME]
[-v] [-i IF] -d HOSTNAME [pub]
[-v] [-H HWTYPE] [-i IF] -s HOSTNAME HWADDR [temp]
[-v] [-H HWTYPE] [-i IF] -s HOSTNAME HWADDR [netmask MASK] pub
[-v] [-H HWTYPE] [-i IF] -Ds HOSTNAME IFACE [netmask MASK] pub
Manipulate ARP cache
-a Display (all) hosts
-d Delete ARP entry
-s Set new entry
-v Verbose
-n Don't resolve names
-i IF Network interface
-D Read HWADDR from IFACE
-A,-p AF Protocol family
-H HWTYPE Hardware address type

先檢查本機的ARP Cache紀錄

bigred@m1:~$ arp -a
x2 (192.168.61.1) at 00:50:56:c0:00:08 [ether] on eth0
x3 (192.168.61.2) at 00:50:56:e0:f3:4a [ether] on eth0

ping 另一台主機

bigred@m1:~$ ping 192.168.61.6
PING 192.168.61.6 (192.168.61.6) 56(84) bytes of data.
64 bytes from 192.168.61.6: icmp_seq=1 ttl=64 time=0.479 ms
64 bytes from 192.168.61.6: icmp_seq=2 ttl=64 time=0.382 ms
64 bytes from 192.168.61.6: icmp_seq=3 ttl=64 time=0.438 ms
64 bytes from 192.168.61.6: icmp_seq=4 ttl=64 time=0.833 ms
--- 192.168.61.6 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3108ms
rtt min/avg/max/mdev = 0.382/0.533/0.833/0.176 ms

再檢查本機的ARP紀錄

bigred@m1:~$ arp -a
x2 (192.168.61.1) at 00:50:56:c0:00:08 [ether] on eth0
w1 (192.168.61.6) at 00:50:56:ab:00:06 [ether] on eth0
x3 (192.168.61.2) at 00:50:56:e0:f3:4a [ether] on eth0

我們再ping 另一台沒記錄過Mac Address的主機

bigred@m1:~$ ping 192.168.61.7
PING 192.168.61.7 (192.168.61.7) 56(84) bytes of data.
64 bytes from 192.168.61.7: icmp_seq=1 ttl=64 time=0.562 ms
64 bytes from 192.168.61.7: icmp_seq=2 ttl=64 time=0.786 ms
64 bytes from 192.168.61.7: icmp_seq=3 ttl=64 time=0.465 ms
64 bytes from 192.168.61.7: icmp_seq=4 ttl=64 time=0.949 ms
--- 192.168.61.7 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3092ms
rtt min/avg/max/mdev = 0.465/0.690/0.949/0.189 ms

快點兩下，啟動WiresharkPortable64_3.6.3.paf.exe，找到VMnet8那張網卡，因為他負責連接我們的那3台電腦

可以看第二步的廣播封包

硬體層： broadcast 它的Mac Address都是f

軟體層：

第四部的reply

ARP 攻擊

ARP Cache 的儲存時間（10年前的規格） Dynamic ARP cache entries update persist for 2-20 minutes depending on the system.
Windows 2003 Server = 10 minutes
Windows 2000 professional/Server = 10 minutes
Windows XP = 2 minutes
Solaris = 5 minutes

提問：ARP Cache的時間要設長還設短答：在內網的話，要設長，原因是因為在內網不可能一直換網路卡，這樣可以讓ARP的封包降到最低，甚至不會產生。

bigred@m1:~$ arp -a
w2 (192.168.61.7) at 00:50:56:ab:00:07 [ether] on eth0
x2 (192.168.61.1) at 00:50:56:c0:00:08 [ether] on eth0
w1 (192.168.61.6) at 00:50:56:ab:00:06 [ether] on eth0
x3 (192.168.61.2) at 00:50:56:e0:f3:4a [ether] on eth0
bigred@m1:~$ sudo arp -d w2
bigred@m1:~$ sudo arp -d w1
bigred@m1:~$ sudo arp -d x2
bigred@m1:~$ sudo arp -d x3
bigred@m1:~$ arp -a
x2 (192.168.61.1) at 00:50:56:c0:00:08 [ether] on eth0 ## 不理他

Add static entry to ARP table

添加靜態的Mac address，不會因為時間到就消失。

arp -s <ip address> <mac address>

範例：將192.168.61.6對應的Mac Address設成00:22:33:44:55:66

bigred@m1:~$ sudo arp -s 192.168.61.6 00:22:33:44:55:66
bigred@m1:~$ arp -a
x2 (192.168.61.1) at 00:50:56:c0:00:08 [ether] on eth0
w1 (192.168.61.6) at 00:22:33:44:55:66 [ether] PERM on eth0
x3 (192.168.61.2) at 00:50:56:e0:f3:4a [ether] on eth0

發現ping 不到192.168.61.6這台電腦

bigred@m1:~$ ping 192.168.61.6
PING 192.168.61.6 (192.168.61.6) 56(84) bytes of data.
^C
--- 192.168.61.6 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3161ms

ping 外網

ping 8.8.8.8

bigred@m1:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=128 time=3.13 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=128 time=4.01 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=128 time=2.99 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=128 time=3.05 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 2.985/3.293/4.009/0.416 ms

發現ping 不通啦！！！

bigred@m1:~$ ping 192.168.61.6
PING 192.168.61.6 (192.168.61.6) 56(84) bytes of data.
^C
--- 192.168.61.6 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3161m

提問：為何ping 8.8.8.8，我的主機裡面沒有它的Mac Address？

bigred@m1:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=128 time=3.13 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=128 time=4.01 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=128 time=2.99 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=128 time=3.05 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 2.985/3.293/4.009/0.416 ms

檢查真的沒有8.8.8.8的Mac Address，為什麼！？

bigred@m1:~$ arp -a
x2 (192.168.61.1) at 00:50:56:c0:00:08 [ether] on eth0
w1 (192.168.61.6) at 00:22:33:44:55:66 [ether] PERM on eth0
x3 (192.168.61.2) at 00:50:56:e0:f3:4a [ether] on eth0

答：因為8.8.8.8的Network ID和我們的主機不同，所以不會觸發ARP通訊協定，但是IP要出去外網之前，一定會經過Default Gateway這個大門，所以我們這台主機的ARP Cache裡面會紀錄Default Gateway的Mac Address

bigred@m1:~$ arp -a
x2 (192.168.61.1) at 00:50:56:c0:00:08 [ether] on eth0
w1 (192.168.61.6) at 00:22:33:44:55:66 [ether] PERM on eth0
## 下面這行就是Default Gateway的IP位址和它的Mac Address
x3 (192.168.61.2) at 00:50:56:e0:f3:4a [ether] on eth0

以後設定機器時，在開機程序裡面埋一個bash script，設定靜態的Mac address，不但可以降低ARP 封包的產生，還可以避免被攻擊。

IP Header 重要欄位

Source IP address
Destination IP address
Time-to-Live
- Time to live
- IP 的封包，只要經過一個Router，他的數字（TTL）就會減一，數字為0時，封包就不會再傳送

提問：ping 這個命令有沒有設定TTL 答：

bigred@m1:~$ ping --help
...
-t <ttl> define time to live
...

自行設定TTL = 3，代表只能跳躍3個Router

bigred@m1:~$ ping -t 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 120.96.98.121 icmp_seq=1 Time to live exceeded
From 120.96.98.121 icmp_seq=2 Time to live exceeded
From 120.96.98.121 icmp_seq=3 Time to live exceeded
From 120.96.98.121 icmp_seq=4 Time to live exceeded
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3074ms

由以下可知，到8.8.8.8這台電腦，要經過12台Router

bigred@m1:~$ ping -t 12 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=128 time=3.16 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=128 time=4.07 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=128 time=4.14 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=128 time=3.76 ms
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 3.160/3.783/4.142/0.387 ms

ICMP

ICMP這個封包，所有Router都會送，但通常這個功能會關閉，因為會造成網路癱瘓，但是企業內網的ICMP回應的功能可能還有打開。

UDP

提問：TCP與UDP的差別？答：UDP 通訊協定的特性，丟了就跑，代表不會跟對方建立connection，也就是說對方如果沒有回應他就會再丟一次封包，Domain NameServer在使用，也就是名稱在查詢時，透過UDP，把名稱在查詢的封包丟給DNS Server，如果DNS Server沒有回應，我們的機器就會再送一次封包出去，總共會丟3次，如果都失敗，就判定連不到對方的DNS Server。

RIP 通訊協定和 SNMP 網路設備在監控用的通訊協定都是通過UDP通訊協定，送出去有回應就繼續作業，如果沒有回應就繼續送，累積3次沒有回應就爆錯。

TCP通訊協定有一個必要條件一定要發生：叫做Handshake握手，意思就是說我要跟對方做連接一定會跟對方握手，也就代表等等資料再傳送時，一定保證可以送到對方手上。

SMTP 電子郵件的通訊協定一定會透過TCP/IP再傳 TCP/IP 在傳遞時一定很耗資源，因為他要handshake（握手）後，才會傳資料。 UDP就是我丟給你就等你，有回應我就做，沒有回應就丟3次。

SSH通訊協定一定要走TCP RDP(Remote Desktop Protocol)通訊協定一定要走TCP VNC也是走TCP

NTP時間同步的通訊協定走UDP

Socket

TCP上面有6萬多個插座，以SMTP這個網路服務，他會把他的整個資料溝通會插在第25port，也就是第25個插座，FTP插在21 port，

定義：一個應用的通訊協定，一定會找TCP或UDP上面的插座，插進去，代表服務會透過TCP/IP做操作，講TCP一定會經過IP這層，有IP這層一定會透過實體層，以上就叫做Socket。 Socket要讓他通一定要提供IP Adress和port Number

分類：

TCP Socket，只要服務插在上面，代表資料一定會送達
UDP Socket，DNS 插在第53個插孔

以數學公式表示： TCP/UDP Socket = Port + IP

Unix domain socket

Unix domain Socket

IPC Socket
- 運作方式一定在同一台機器

Antony 筆記：技術原理與實務經驗 – 網路基礎

Networking Introduction

1.1. Networking History

1.2. OSI Model

How does Ingress Nginx Controller work?

1. Ingress 基本概念

2. What is Ingress?

3. Ingress Controllers 使用須知

4. Ingress Controller 工作原理

5. Deploying the Ingress Nginx Controller as a Deployment Workload

6. 了解 Ingress Nginx Controller Kubernetes Resources

7. 設定 ingress nginx controller 使用 host network

8. Deploying an Application (Comprising of Deployment, Service, and Ingress)

9. Observing the Ingress Nginx Controller Pod

10. 查看 Ingress Nginx Controller Pod Configuration File

11. Ref

How to Block Ping ICMP Requests with firewalld

Understanding predefined zones

Check Veth peer

PreRequest

Start Cehck Veth peer

1. 先看 veth 的另一端插在哪個 Namespace

2. 列出 Network Namespace 的網卡資訊

Configure MTU to maximize network performance

1. Configure the MTU value in Podman Network

1.1. 修改已經存在的 Podman Network

1.2. 檢查 Podman1 網卡 MTU 已設為 6000

1.3. 關閉 Kind Cluster

1.4. 啟動 Kind Cluster

1.5. 檢查 Kind node 網卡 MTU 已設為 6000

2. Configure Calico MTU

2.1. 將 MTU 設為 5950

2.2. Rolling restart of all calico/node pods.

2.3. Check Calico pod Status

3. Testing Connectivity Between Kubernetes Pods with Iperf3

3.1. Deploy Iperf3 as a DaemonSet

3.2. Create the DaemonSet

3.3. Check that iperf3 pods are running on all nodes in the cluster

3.4. Choose a pod to run in server mode

3.5. Choose a pod to run in client mode

4. 測試 K8s Pod 網路效能

4.1. 原始 podman network MTU 改 1500, Calico 改 1480

4.2. podman network MTU 改 9000, Calico 改 8950

Ref

使用 Certbot 命令列工具建立免費的 TLS/SSL 網域憑證

Cloudflare Tunnel

Cert-manager with SelfSigned Issuers

實作目標

先備知識

Issuer

Run Nginx with TLS Ingress

流程圖解

Set Static IP Address on RHEL 9 with nmcli

Get the Interface Name

View Current Connection

設定網路

新增 DNS Server

啟動網路連線

設定系統重啟後自動連線

設定 Hostname

關閉 IPv6

更新 Default Gateway 設定

參考資料

Linux Network Block Devices

Preface

What is Network block devices (NBD)?

Remove secondary IP with nmcli

Self-Signed SSL Certificates

什麼是自簽憑證 （self-signed certificate）？

用途

風險

What is Certificate Authority

Self-Signed SSL Certificates: Basic Requirements

參考網站

網路基礎

Ethernet(乙太網路)

Switch 網路交換器

Protocol:電腦之間溝通的語言

ARP(Adress Resolution Protocol)通訊協定

重點整理：

什麼是自簽憑證（self-signed certificate）？

tags: `網路基礎`

`Ping` 命令的運作

tags: `網路基礎`

tags: `網路基礎`

tags: `網路基礎`