顯示文章

這裡允許您檢視這個會員的所有文章。請注意, 您只能看見您有權限閱讀的文章。


文章 - netman

頁: [1] 2 3 ... 500
2
雜七雜八 / Re: 2021 了……
« 於: 2021-11-15 09:00 »
歡迎啊!

3
 畫面的訊息是說沒有指定 NIS server ?

4
活動/聚會區 / 11/16(二)晚上聚餐?
« 於: 2021-11-14 00:19 »
禮拜二晚上剛好出差臺北,大家有空聚餐嗎?

5
有重新跑make嗎?

6
感謝分享!又學到一招...

7
DRBD 如何?

8
Netman大,這是公司的案子,我可以外包出去也很想,但就是要我做~ = =
還是我私自找人幫忙設計,看看有沒有便宜方案,順便學習?
我也覺得會很慢,但MIS沒有專注的領域,就是什麼都要會,什麼都不會。
樂觀看,這也是一個學習機會。如果有興趣不妨投入看看...
MIS也有分AP跟Infra,除非人手不足,不然正規的編制不會都包才對。

9
網頁設計我也不會,我覺得那是另一個專業,美工也是。
如果是接到案子,看是不是要外包出去?
自己學太慢了,也未必學得來... 專注在自己的領域做出成績或許更好!

10
不同版本有不同的預設值。 如果不確定系統行為,每次 useradd 用  -m 就會建立家目錄。

11
Linux 討論版 / Re: linux的shell脚本
« 於: 2020-04-16 11:39 »
你本來不是說沒報錯嗎?我指出了可能會報錯的地方,不是你要的嗎?
沒有原始碼的情況下容易看問題...

12
Linux 討論版 / Re: linux的shell脚本
« 於: 2020-04-14 10:00 »
echo $(($a*0)) 呢?

13
Linux 討論版 / Re: linux的shell脚本
« 於: 2020-04-05 15:16 »
你怎運行的? 結果是怎樣?

14
DevOps 討論版 / K8S 之 Cert-Manager 建置
« 於: 2020-03-16 22:05 »
K8S 之 Cert-Manager 建置
netman <netman@study-area.org>
2020.03

一,前言
當 K8S 玩到一個階段的時候,自然會遇到 cert-manager 的需求。別問我爲什麼,反正有很多機會遇到就是了。然而,很多朋友都跟我一樣發現 cert-manager 似乎沒那麼好上手。因爲還需要扯上一些基本的 PKI 概念,但這裏先不展開 certificate 相關的基礎了,有興趣的朋友可以另外學習。

此外,這裏也不對 cert-manager 的基本概念多做闡述,請大家到官網瞭解吧:
   https://cert-manager.io/docs/

本篇的要旨主要是以實作的方式來示範 k8s 上的 cert-manager 建置過程。因爲 cert-manager 也有不同的方式搭建,這裏也只就本人偏好的其中一種來示範而已。

二,先讓我們 Let's Encrypt 吧!
基本上,k8s 的 cert-manager 可以使用不同的憑證來源發佈憑證,例如 Let’s Encrypt、HashiCorp Vault、Venafi,甚至是簡單的金鑰組或自簽憑證。爲求實用性,這裏就以當今最熱門且又是免費的 Let's Encrypt 來做示範。

Let's Encrypt 本身就是一個憑證發行機構(CA),主要透過 ACME 協定來確認 domain 擁有者身份並進行憑證的後續處理任務。其配置方式也有很多種,例如使用 Certbot 或是透過網站空間服務商內建支援等等。不過,這篇的目的是用 k8s 的 cert-manager 來處理憑證問題,所以一開始我們只需要一種簡單的方式來驗證 Let's Encrypt 是否成功即可。這裏,我選擇了acme.sh 這隻純 shell 的腳本來幫忙驗證。

Let's Encrypt 一般是透過連線您的 web server 來驗證身份,但這方式必須要提供一個可供外部連線的網站服務。有時對於純內部的使用環境來說卻是一件麻煩的事情。但 Let's Encrypt 也同時提供另外一種驗證方式,就是透過 DNS 查詢來確定您的合法性。

目前有不少主流 DNS 服務商都有提供 Let's Encrypt 的支援,例如 CloudFlare,允許我們透過 API 的方式修改 DNS Record 從而通過 Let's Encrypt 的驗證。這裏,我將使用 CloudFlare 作爲 Let's Encrypt 的 DNS 驗證。

2.1 取得 CloudFlare API Token
首先,請登入 ClouldFlare 的 dashbord,然後從右上角的 My Profile 那邊選擇 API Tokens:


然後按下 Create Token 按鈕,根據自己喜好輸入 Token Name,將 Permissions 設定如下:
  • Zone, Zone, Read
  • Zone, DNS, Edit


然後按 Continue to summary,確認權限後再按 Create Token ,最後跳出的視窗會列出 Token 的內容,請 Copy 下來保存。(網頁也有顯示測試 token 的方法,不妨也複製下來測試驗證。)

此外還有一件事情:您必須確定 CloudFlare 帳號中所留的 Email 已經完成驗證。

2.2 使用 acme.sh
操作者不一定需要 root 的權限(有則更好),直接線上安裝就行:
curl https://get.acme.sh | sh

然後登出再重新登入即可操作 acme.sh 。

首先,將 CloudFlare 那邊的 API Token 與 Email 設定爲環境變數:
export CF_Token="1txxxxqP-xxxxxxxxxxxxxxTp5JIxxxxxnf"
export CF_Email="xxx@xxxx.xxxx.com"

我這裏打算建立 wildcard 憑證,所以直接輸入如下命令:
acme.sh --issue -d k8slab.exmaple.com  -d '*.k8slab.example.com'  --dns dns_cf
(注意:example.com 只是個舉例,請修改爲真正的 domain 名稱。)

如果沒有 error,最終會生出如下內容:
Your cert
Your cert key
The intermediate CA cert
The full chain certs

日後要 renew 憑證的話,只需執行如下命令即可:
acme.sh --renew --force -d k8slab.exmaple.com  -d '*.k8slab.example.com'  --dns dns_cf

當 acme.sh 測試成功之後,然後我們再轉移到 k8s 中設定 cert-manager 。

三,在 K8S 配置 cert-manager
在 cert-manager 的官網文件(https://cert-manager.io/docs/)中我們可以獲得很多配置資訊。然而,關於 ACME 底下的 CloudFlare 部份卻沒有很完整的範例。建議交叉參考網路上其他文章來獲得適當的設定。下面的過程我會將建置流程中特別需要注意的地方強調出來,減少大家的試誤時間。

3.1 安裝 cert-manager
基本上按照官網的 Installation 就可以了,以下是我整理的步驟:
mkdir cert-manager
cd cert-manager
kubectl create namespace cert-manager
wget https://github.com/jetstack/cert-manager/releases/download/v0.13.1/cert-manager.yaml
kubectl apply -f cert-manager.yaml
kubectl get pods --namespace cert-manager

最後的驗證結果請確定所有的 pod 都處於 Running 狀態:


其中要留意的地方是 cert-manager-webhook 需要比較久一些時間才能從 ContainerCreating 變成 Running 狀態,請耐心等候就是了。

3.2 配置 secret
接下來,我們要將 CloudFlare 的 API Token 以 secret 的方式進行配置。請建立一份 secret.yaml:
代碼: [選擇]
apiVersion: v1
kind: Secret
metadata:
  name: cloudflare-api-token-secret
  namespace: cert-manager
type: Opaque
stringData:
  api-token: 1txxxxqP-xxxxxxxxxxxxxxTp5JIxxxxxnf

這裏要特別留意的地方在於 namespace :如果採用 Issuer 而非 ClusterIssuer 的話,就不需要設定。但我這裏要示範的 issuer 是用 ClusterIssuer,因此必需要將 namespace 設定爲 cert-namager,也就與 cert-manager pod 相同的 namespace 就是了。如果這裏設定不對的話,在產生 Challenge 的時候,會遇到找不到 secret 的錯誤。這個細節花了我相當多的時間才搞懂,希望可以節省大家寶貴的時間!

3.3 配置 ClusterIssue
在 K8S 的 cert-manager 中,可以使用的 issuer 有兩種:
Issuer: 只能讓相同 namespace 裏面的憑證使用
ClusterIssuer: 不分 namespace,整個 cluster 內的憑證都可以使用

由於 ClusterIssuer 的通用性比較高,因此我採用這一方式來發行後續的憑證。這裏請建立一份 cluster-issuer.yaml:
代碼: [選擇]
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: k8slab-issuer
  namespace: cert-manager
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: cert-k8slab
    solvers:
    - dns01:
        cloudflare:
          email: xxx@xxxx.xxxx.com
          apiTokenSecretRef:
            name: cloudflare-api-token-secret
            key: api-token

與 secret 一樣,因爲 ClusterIssuer 的關係,這裏也是要設定 namespace。另外一個要注意的地方是 email 要與 CloudFlare 驗證的郵件信箱一致。而 apiTokenSecretRef 所用的 name 必須與  secret 的名字一致才行。

3.4 配置 Certificate
這裏是最後要設定的憑證了,請建立一份 cert.yaml :
代碼: [選擇]
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: k8slab-cert
  namespace: default
spec:
  secretName: k8slab-cert-tls
  issuerRef:
    name: k8slab-issuer
    kind: ClusterIssuer
  commonName: '*.k8slab.example.com'
  dnsNames:
  - k8slab.example.com
  - "*.k8slab.example.com"

請留意 spec 底下的 secretName 並不是指前面建立的 secret 名稱,而是給憑證暫用的參考名稱而已,因此兩個名字是不一樣的。這裏只需要確定 issuerRef 的正確性就好。因爲我要配置通配型(wildcard)憑證,因此我的 dnsName有兩個:一個帶星號(*)、另一個沒有。

3.5 套用配置
當上述三個 yaml 檔案配置完成後,接下來當熱就是套用並測試了:
kubectl apply -f secret.yaml
kubectl apply -f cluster-issuer.yaml
kubectl apply -f cert.yaml

如果 yaml 沒有打錯字的話,一般來說上面的資源都會順利 created 。稍等幾分鍾(我建議等個3分鐘左右),然後就可以驗證憑證是否有配置成功:
kubectl describe Certificate

如果最後看的 Status 顯示爲 Ready/True 的話:


恭喜您!您的 Cert-Manager 已經配置成功了!

3.6 除錯
有實務經營的朋友通常都會發現事情一般來說都不會那麼順利的!

那麼,當有問題時要如何除錯呢?這才是重點中的重點啊。假如我們套用 yaml 之後發現憑證狀態一直都卡在 InProgress 的狀態:


以根據上面的 Message 可得到 Waiting 的對象是 CertificateRequest,並且 Events 中也看到 CertificateRequest 被創建出來了,那麼接下來我們就可以查詢 CertificateRequest:
kubectl describe CertificateRequest

然後,我們或許會看到如下的訊息:


從上面的訊息中,我們又發現 Order 被創建出來並且在等待中,因此我們就接下來查詢 Order 就是了:
kubectl describe Order

從結果中我們可以看到:


其中有兩個 Challenge 被創建出來,於是我們就繼續查 Challenge:
kubectl describe Challenge

仔細檢查裏面的資訊,可能會發現類似這樣的內容:


這裏很明顯看到錯誤原因是 secret "cloudflare-api-token-secret" not found 嘛!我就是根據這個資訊去 google 才發現是 namespace 的問題!

如果 Challenge 沒問題的話,一般我們會看到這樣的資訊:


而另外一個 Challenge 則顯示爲 Waiting for dns-01 challenge propagation 的狀態... 這時候只需要耐心等候幾分鍾就好。最後會從 Order 中看到 successfully 的結果:


從 CertificateRequest 的查詢結果也會看到成功才對:


四,結語
希望以上的分享能夠幫助大家順利完成 K8S 的 cert-manager 建置。遇到問題時,請多看官方的文件,按部就班設定一般都能成功的。請記住 google 大神永遠都在,有拜有包庇哦!

--- END ---




15
這個真沒研究過呢...
我都是手機分享熱點,然後手機用 wifi 去連...

16
使用k8s externel-dns自動更新BIND DNS

2020.02

一,需求背景

在 Kubernetes 的管理中,服務名稱的解釋在 cluster 內幾乎不需要操心就能直接使用。然而,很多時候,我們建置好的服務是提供給 cluster 之外的用戶端作存取的,一般來說用戶端都以 DNS 名稱來存取服務。倘若每一筆服務都要人工方式更新 DNS 紀錄的話,這顯然不能滿足當今的營運需求。

為此,我們可以從 https://github.com/kubernetes-sigs/external-dns 取得 External DNS for Kubernetes 這一工具幫我自動完成 DNS 的更新。

二,External DSN 簡介

   External DNS 可以將 K8S 中的 Service 與 Ingress 這兩種資源的名稱解釋同步到外部的 DNS 伺服器。也就是說,當資源產生的時候自動新增 hostname 與 IP 的記錄,並在資源刪除的時候一併移除 DNS 記錄。

External DNS 支援的外部 DNS 非常多,幾乎網際網路上各家提供動態 DNS 更新服務的服務商都在其支援之列,例如:
  • AWS Route 53
  • Google Cloud DNS
  • AzureDNS
  • CloudFlare
  • Dyn
  • ….

早期的 external-dns 版本並不支援 BIND,好消息是最新的版本提供了一個 RFC2136 的 provider 讓我們用 dns-key 來更新 BIND DNS 伺服器了!(Microsoft DNS也是支援的,但目前沒有提供連線加密的方式)

三,實作環境

本文章將示範如何利用 External DNS 將 K8S 的服務資源名稱同步到不在 cluster 中的 Linux BIND 伺服器:
  • Linux: CentOS Linux release 7.6.1810 (Core)
  • BIND: bind-9.9.4-74.el7_6.1.x86_64
  • IP: 192.168.100.1

K8S Cluster則是使用 kubeadm建置完成:
  • Kubernetes: v1.16.2

四,設定 BIND 的 dns update 功能

4.1 產生 dns key:
代碼: [選擇]
cd /var/named/dynamic
dnssec-keygen -a hmac-sha256 -b 128 -n HOST externaldns-key
chown named.named Kexternaldns-key.*
cat Kexternaldns-key.*.key | awk '{print $NF}'
確定輸出類似 y+gUcHxLWqzg3JcBU2bbgw== 的結果,並複製結果。

4.2 修改 named.conf,末尾處增加如下內容:
代碼: [選擇]
key "externaldns-key" {
    algorithm hmac-sha256;
    secret "y+gUcHxLWqzg3JcBU2bbgw==";
};
zone "k8s.example.org" {
    type master;
    file "/var/named/dynamic/named.k8s.example.org";
    allow-transfer {
        key "externaldns-key";
    };
    update-policy {
        grant externaldns-key zonesub ANY;
    };
};
注意:secret 內容請用複製的key貼上。

4.3 建立 zone file (/var/named/dynamic/named.k8s.example.org)內容:
代碼: [選擇]
$TTL 60 ; 1 minute
@         IN SOA  k8s.example.org. root.k8s.example.org. (
                                16         ; serial
                                60         ; refresh (1 minute)
                                60         ; retry (1 minute)
                                60         ; expire (1 minute)
                                60         ; minimum (1 minute)
                                )
                        NS      ns.k8s.example.org.
ns                      A       192.168.100.1
注意:BIND server 的 IP 請修改實際 IP。

4.4 重新啟動 named 服務:
代碼: [選擇]
systemctl restart named
systemctl status -l named
確定沒有 error,並且 k8s.example.org 的 serial 是正確的。

五,建置 metallb Load Balancer (Optional)
# 如果 K8S Cluster 已經有可用的 Load Balancer 可略過此一步驟。

5.1 下載 metallb yaml 並套用:
代碼: [選擇]
wget https://raw.githubusercontent.com/google/metallb/v0.7.3/manifests/metallb.yaml
sed -i '/^apiVersion: apps/s/beta2//' metallb.yaml
kubectl apply -f metallb.yaml
因為我們這裡的 k8s 版本已經升級到 v1.16, 因此需要調整 api 的版本。若您的環境是 v1.15 或之前的版本, 請略過 sed 那行指令不要執行。

5.2 建立 metallb configmap (metallb_configmap.yaml),其內容如下:
代碼: [選擇]
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: my-ip-space
      protocol: layer2
      addresses:
      - 192.168.100.240-192.168.100.249
請將 ip range 修改爲實際的網段,這是分配給 k8s service 資源用的 IP。完成後套用即可:
kubectl apply -f metallb_configmap.yaml
如果沒有 error 就表示就緒了。

六,佈署 external-dns

6.1 撰寫yaml (external-dns.yaml),其內容如下:
代碼: [選擇]
apiVersion: v1
kind: Namespace
metadata:
  name: external-dns
  labels:
    name: external-dns
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: external-dns
  namespace: external-dns
rules:
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - get
  - watch
  - list
- apiGroups:
  - extensions
  resources:
  - ingresses
  verbs:
  - get
  - list
  - watch
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: external-dns
  namespace: external-dns
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: external-dns-viewer
  namespace: external-dns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: external-dns
subjects:
- kind: ServiceAccount
  name: external-dns
  namespace: external-dns
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: external-dns
  namespace: external-dns
spec:
  selector:
    matchLabels:
      app: external-dns
  template:
    metadata:
      labels:
        app: external-dns
    spec:
      serviceAccountName: external-dns
      containers:
      - name: external-dns
        image: registry.opensource.zalan.do/teapot/external-dns:v0.5.17
        args:
        - --provider=rfc2136
        - --registry=txt
        - --txt-owner-id=k8s
        - --source=service
        - --source=ingress
        - --domain-filter=k8s.example.org
        - --rfc2136-host=192.168.100.1
        - --rfc2136-port=53
        - --rfc2136-zone=k8s.example.org
        - --rfc2136-tsig-secret=y+gUcHxLWqzg3JcBU2bbgw==
        - --rfc2136-tsig-secret-alg=hmac-sha256
        - --rfc2136-tsig-keyname=externaldns-key
        - --rfc2136-tsig-axfr
        #- --interval=10s
        #- --log-level=debug
最後兩行是方便 debug 時用的,需要的時候才移除掉 # 註解符號。設定中比較關鍵的是 dns server 與 key 的正確性,請特別留意。

6.2 佈署服務:
代碼: [選擇]
kubectl apply -f external-dns.yaml如果沒有 error 就表示就緒了。

七,建置測試服務 (nginx)

7.1 撰寫服務 yaml (nginx.yaml),其內容如下:
代碼: [選擇]
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  annotations:
    external-dns.alpha.kubernetes.io/hostname: nginx.k8s.example.org
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  sessionAffinity: None
  type: LoadBalancer
External-dns 最關鍵的部分就是要從 service 的 annotations 取得 hostname,然後再抓取 Load Balancer 分配的 IP 進行 dns update。

7.2 佈署服務:
代碼: [選擇]
kubectl apply -f nginx.yaml如果沒有 error 就表示就緒了。

7.3 觀察結果:
代碼: [選擇]
kubectl -n external-dns logs external-dns-5d986694c9-5n9wm請注意實際運行的 pod 名稱或許不太一樣,請調整。如果一切順利,從輸出結果中可以看到類似如下的內容:
代碼: [選擇]
time="2019-12-04T16:26:44Z" level=info msg="Created Kubernetes client https://10.96.0.1:443"
time="2019-12-04T16:26:49Z" level=info msg="Configured RFC2136 with zone 'k8s.example.org.' and nameserver '192.168.100.1:53'"
time="2019-12-04T16:26:49Z" level=info msg="Adding RR: nginx.k8s.example.org 0 A 192.168.100.245"
time="2019-12-04T16:26:49Z" level=info msg="Adding RR: nginx.k8s.example.org 0 TXT \"heritage=external-dns,external-dns/owner=k8s,external-dns/resource=service/default/nginx-svc\""

另外, 從 BIND 伺服器那邊, 也可以用 systemctl status -l named 觀察更新的動作,當然也可以用 dig 或 host 命令來實際檢查 dns 的查詢結果。假如名稱解釋一如預期,那就用瀏覽器連線服務的 hostname 來作最後的確認。

八,其他

前面我們是用 service 資源來作示範。假如 k8s 環境中已經建置好 ingress-controller 的話,那我們也可以透過建置 ingress 來同步 dns 的更新。我們只需要設定 ingress 資源並進行套用即可:
代碼: [選擇]
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
    name: nginx-ingress
spec:
    rules:
    - host: ingress.k8s.example.org
      http:
          paths:
          - path: /
            backend:
                serviceName: nginx-svc
                servicePort: 80
請留意使用 ingress 比 service 會稍有不同:
  • 不需要設定 annotations 來指定 hostname
  • IP 一律共用 ingress 服務的位址

假如我們要將服務資源停掉的話,也可以透過前述的檢查動作觀察到 dns 名稱也會自動地被刪除:
代碼: [選擇]
12月 05 00:43:49 srv1.localdomain named[6533]: client 192.168.100.56#58519/key externaldns-key: updating zone 'k8s.example.org/IN': deleting rrset at 'nginx.k8s.example.org' A
12月 05 00:43:49 srv1.localdomain named[6533]: zone k8s.example.org/IN: sending notifies (serial 21)
12月 05 00:43:49 srv1.localdomain named[6533]: client 192.168.100.56#45520/key externaldns-key: updating zone 'k8s.example.org/IN': deleting rrset at 'ingress.k8s.example.org' A
12月 05 00:43:49 srv1.localdomain named[6533]: client 192.168.100.56#49731/key externaldns-key: updating zone 'k8s.example.org/IN': deleting rrset at 'nginx.k8s.example.org' TXT
12月 05 00:43:49 srv1.localdomain named[6533]: client 192.168.100.56#56605/key externaldns-key: updating zone 'k8s.example.org/IN': deleting rrset at 'ingress.k8s.example.org' TXT

九,結語

好了,到這裡我們已經體驗到 external-dns 帶來的便利性。希望能夠對大家在 k8s 應用上有所幫助。

--- End ---

17
Linux 討論版 / Re: 关于模拟MBR损坏的修复
« 於: 2020-02-17 13:17 »
照理說 446 byte 只改掉 loader 而已,你描述的似乎連第一個 partition 也被蓋掉..
下次先將原來的 save 出來吧

18
Linux 討論版 / Re: 关于RHEL7系统启动错误
« 於: 2020-02-17 13:15 »
有跑過 grub2-mkconfig 嗎?

https://wiki.centos.org/zh-tw/HowTos/Grub2

19
用Pi做IoT,是在學Linux...+1

20
Linux 討論版 / Re: 架設DNS有問題
« 於: 2019-11-15 09:25 »
journalctl -el 先看看 named 的 log 有沒有載入這個 domain 且 serial 號碼是否一致?
再來確認  udp 53 port 是否有再所有界面上提供服務?
最後確認 client 的  resolv.conf 是否將 dns server 設定在第一順位。

21
雜七雜八 / Re: 歡迎一起來 MOPCON 2019
« 於: 2019-11-01 14:34 »
沒親身聽到 HOYO大師 演講真是可惜,光是看簡報內容就覺得十分精彩!!  ;D

有畫面...

22
disk space 超過 95% ?

23
linux 的 NAT 有分兩種:SNAT(masqurating) 與 DNAT(port mapping)
如果你要單純做 SNAT,那用外面來 ping 是徒勞的。
ping 是 ICMP 協定的 echo request ,你需要用 DNAT 將相應的 icmp type/code 給 forward 到特定得 destination。
這不一定需要兩片網路卡。

我在 n 年前寫過一篇介紹 linux firewall 的文章,不妨參考看看:
https://www.slideshare.net/kennychennetman/linux-firewall-32337622
如果對 Part-V 的問題都能理解,應該就可以解決大部分問題了。

24
那外面 ping 不到是正常的。NAT 之後,外面的 ping 不進來的。

25
等等,你這裡的host是實體主機?

26
老實說,有點看不太懂你畫的圖。

如果是 bridge mode,我會畫成這樣附件那樣。(紅色爲 vm)

27
基本上,經過 NAT 之後, 外面是無法 PING 進來的。
除非你用 routing mode(不同subnet) 或用 bridge(相同subnet)
用 routing 的話, 那需要雙方設定 gateway 互相指向。

28
你可以用附件功能將圖貼上來哦

29
可以畫個網路架構圖來看看嗎?

30
Linux 討論版 / Re: Cent 6.10搭建FTP服务器问题
« 於: 2019-08-20 22:13 »
1. 如果 chmod 777 可以的話,那幾乎可以排除是 selinux 的影響。
chown_uploads=YES
chown_username=SAS
anon_umask=077
因爲你使用了 chown,上傳後身份就改變了,所以 guest 會無法 ls / dir 那是正常的。
這其實也是匿名上傳的建議做法,沒啥不好,並非遇到問題了。

2. 在匿名上傳的 ftp 管理中,需要本機的管理員檢核過上傳的文件,再決定是否開放匿名 ftp 下載,若覺得可以,執行 chown vsftpd 修改允許之文件即可。

頁: [1] 2 3 ... 500