Điểm:3

Kubernetes Nginx Ingress và cert-manager Đang chờ truyền bá thử thách HTTP-01: sai mã trạng thái '401', dự kiến ​​là '200'

lá cờ cd

Tôi đang gặp vấn đề với việc triển khai rapberry pi kubernetes của mình

Vấn đề:

Tôi đang chờ thử thách ACME của trình quản lý chứng chỉ letencrypt do mã lỗi 401 khi cài đặt kubernetes kim loại trần.

Cài đặt

Nền tảng: Raspberry Pi 4

Hệ điều hành: Ubuntu Server 20.04.3 LTS 64 bit

Xâm nhập: Nginx

Cân bằng tải: Metallb

Mạng: Calico

Tôi đã cài đặt metallb và nginx thông qua helm bằng cách sử dụng:

điều khiển cài đặt metallb metallb/metallb --namespace kube-system\
    --set configInline.address-pools[0].name=default\
    --set configInline.address-pools[0].protocol=layer2\
    --set configInline.address-pools[0].addresses[0]=<ip-range>

helm cài đặt ingress-nginx ingress-nginx/ingress-nginx --namespace kube-system

Letsencrypt của tôi trông như thế này:

apiVersion: cert-manager.io/v1
loại:ClusterIssuer
metadata:
  tên: letencrypt-prod
  không gian tên: cert-manager
thông số kỹ thuật:
  tốt:
    email: <email đã được chỉnh sửa>
    máy chủ: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      tên: letencrypt-prod
    người giải quyết:
    -http01:
        xâm nhập:
          lớp: nginx

Thiết lập lối vào nginx của tôi trông như thế này:

---
apiVersion: mạng.k8s.io/v1
loại: Xâm nhập
metadata:
  không gian tên: "nextcloud" # Không gian tên giống như triển khai
  name: "nextcloud-ingress" # Tên của lần xâm nhập (xem kubectl get ingress -A)
  chú thích:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    cert-manager.io/cluster-issuer: "letsencrypt-prod" # Mã hóa bằng cách sử dụng ClusterIssuer được triển khai trong khi thiết lập Trình quản lý chứng chỉ
    nginx.ingress.kubernetes.io/proxy-body-size: "125m" # Tăng kích thước tối đa cho phép của phần thân yêu cầu của máy khách
thông số kỹ thuật:
  tls:
  - máy chủ:
    - "nextcloud.<domain redacted>" # Máy chủ để truy cập nextcloud
    secretName: "nextcloud-prod-tls" # Tên của chứng chỉ (xem kubectl get certificate -A)
  quy tắc:
  - máy chủ: "nextcloud.<tên miền được xác định lại>" # Máy chủ để truy cập nextcloud
    http:
      con đường:
        - đường dẫn: /# Chúng ta sẽ truy cập NextCloud thông qua đường dẫn https://nextcloud.<domain.com>/
          pathType: Tiền tố
          phụ trợ:
            dịch vụ: 
              tên: "nextcloud-server" # Ánh xạ tới dịch vụ (xem kubectl get services -n nextcloud)
              Hải cảng: 
                số: 80 # Ánh xạ tới cổng (xem kubectl get services -n nextcloud)
---

gỡ lỗi

Khi tôi xem nhật ký bộ điều khiển xâm nhập (không gian tên khác), tôi thấy:

Dịch vụ "nextcloud/cm-acme-http-solver-9tccf" không có bất kỳ Điểm cuối đang hoạt động nào.

Nhưng điểm cuối dường như tồn tại khi tôi thực hiện kubectl get điểm cuối -A

Chứng chỉ của tôi tồn tại dưới dạng:

kubectl lấy chứng chỉ -n nextcloud
TÊN SẴN SÀNG BÍ MẬT TUỔI
nextcloud-prod-tls Sai nextcloud-prod-tls 3h58 phút

Làm theo các bước gỡ lỗi được đề xuất từ ​​trình quản lý chứng chỉ, tôi đã theo dõi sự cố đến các thách thức mà tôi nhận được:

Trạng thái:
  Trình bày: đúng
  xử lý: đúng
  Lý do: Chờ tuyên truyền thách thức HTTP-01: sai mã trạng thái '401', dự kiến ​​là '200'
  Trạng thái: đang chờ xử lý
Sự kiện: <không có>

Tôi hơi bế tắc. Tôi đã tìm kiếm trên Google nhưng dường như không có nhiều thông tin về điều này. Tôi đoán là tôi đã hoàn thiện phần thiết lập nhưng tôi chủ yếu theo dõi tài liệu trên các trang có liên quan. Bât cư thông tin được cung câp nao cung được la sự suât hiện tuyệt vơi :). Nếu bạn cần bất kỳ thông tin bổ sung nào, hãy cho tôi biết thông tin này hiện tại khá dài nên tôi đã cố gắng đưa vào những điểm mà tôi cho là có vấn đề.

Dennis Nolte avatar
lá cờ us
nếu tôi đọc chính xác thiết lập của bạn, bạn sẽ nhận được 401 trên thư mục/tệp yêu cầu của trình quản lý chứng chỉ (certbot?). Điều này có vẻ là do cuộc gọi từ letsencrypt chuyển đến thứ mà bạn có thể đã bảo vệ bằng mật khẩu Nhật ký nginx của bạn sẽ hiển thị cho bạn một yêu cầu đối với một số tên thư mục .well-known hoặc tương tự. Sau đó là tên chung. Cái đó cần phải được người ngoài truy cập (certbot trong ví dụ này) Đối với tôi, tốt nhất là loại trừ thư mục cụ thể đó để nginx phục vụ trực tiếp. Một cái gì đó giống như một khối location .well-known trong cấu hình nginx.
Mikołaj Głodziak avatar
lá cờ id
Ý tưởng của @DennisNolte rất hay. Bạn có thể thử nó và biết chúng tôi nếu nó hoạt động?
Llewyn S avatar
lá cờ cd
@DennisNolte Cảm ơn câu trả lời của bạn, tôi không thể tìm thấy bất kỳ nỗ lực nào để truy cập thư mục/.well-known/ trong nhật ký bộ điều khiển Nginx nhưng tôi có thể tìm thấy một tham chiếu đến nó và miền của tôi trong nginx.conf Bạn có gợi ý rằng tôi nên thay đổi vị trí /.well-known/ sang một thư mục khác trong nginx.conf không?
Mikołaj Głodziak avatar
lá cờ id
Bạn có thấy [chủ đề này](https://github.com/jetstack/cert-manager/issues/2517) không? Nó có giống với vấn đề của bạn không?
Llewyn S avatar
lá cờ cd
@MikoÅajGÅodziak Tôi đã xem qua nhưng không tìm thấy bất cứ điều gì phù hợp. Có vẻ như hầu hết mọi người không nhận được 401...Tôi không biết cách gỡ lỗi vì không có vấn đề về quyền trong nhật ký xâm nhập. Chỉ thử thách chứng chỉ mới nhận được lỗi 401. Tôi tự hỏi liệu bằng cách nào đó tôi có thể thêm trình quản lý chứng chỉ vào nhóm RBAC hay gì đó không...
Dennis Nolte avatar
lá cờ us
bạn sẽ cần thử và tìm hiểu thử thách chứng chỉ thực sự đang truy cập vào máy chủ của bạn bằng gì, điều này phải có trong nhật ký ingres, Tệp thường được gọi là một cái gì đó như access.log, có thể có tên miền ở phía trước. Trong tệp đó, bạn sẽ thấy lệnh gọi HTTP mà nginx đang nhận. Nếu bạn không tìm thấy bất kỳ mục nhập nào, hãy thực hiện một số thao tác thủ công để xác nhận đúng tệp nhật ký của nó. Điều này cũng đúng với chương trình phụ trợ của bạn, nhưng điều này có thể phải được định cấu hình trước. Khi bạn biết cuộc gọi chính xác, bạn có thể xác minh rằng bạn cho phép truy cập vào thư mục đó và xác định ai sẽ phục vụ thư mục đó
Wytrzymały Wiktor avatar
lá cờ it
Xin chào @LlewynS. Bất cứ cập nhật?
Llewyn S avatar
lá cờ cd
Chưa, tôi không thể theo dõi bất kỳ nhật ký hữu ích nào.
Llewyn S avatar
lá cờ cd
OK, tôi đã thiết lập một ví dụ tối thiểu không có trình quản lý chứng chỉ. Tôi nhận thấy rằng nếu tôi đang cố gắng kết nối với FQDN của mình qua mạng gia đình thì nó thực sự đưa tôi đến thông tin đăng nhập bộ định tuyến... Tôi hiện có thể kết nối qua FQDN qua VPN hoặc điện thoại di động. Điều này không thực sự giải quyết được vấn đề 401 của trình quản lý chứng chỉ ngoài việc định tuyến qua mạng gia đình cũng đang gửi nó tới thông tin đăng nhập bộ định tuyến thay vì xâm nhập....
Điểm:1
lá cờ jp

Trong trường hợp của tôi, clusterissuer đã trỏ đến lớp xâm nhập sai

nhà phát hành cụm chỉnh sửa kubectl XXXX

người giải quyết:
-http01:
    xâm nhập:
      lớp: nginternal

Hãy chắc chắn rằng lớp đang trỏ đến giống như lối vào.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.