Truy cập ứng dụng Container Apps riêng tư qua VPN điểm tới trang

Sổ tay này bao gồm môi trường Container Apps với hồ sơ khối lượng công việc và lối vào mạng ảo nội bộ, được truy cập từ máy tính xách tay qua VPN điểm tới trang đã phê duyệt, dùng FQDN trực tiếp của ứng dụng và không có tuyến HTTP ở cấp môi trường. lối vào của môi trường có thể tiếp cận từ máy khách, phạm vi ingress của ứng dụng chấp nhận người gọi, và tên máy chủ phân giải thành lối vào riêng. Mỗi bước dưới đây để lại kết quả có thể xác minh và khôi phục không đụng đến bất cứ thứ gì bạn không thay đổi. Hãy thực hiện theo thứ tự đã cho, vì không bước nào sau đó có thể bù đắp quyết định phạm vi đưa ra sai ở bước 1.

Trước khi chạm vào DNS, hãy làm rõ từ nội bộ. Trong sản phẩm này nó được dùng cho hai phạm vi khác nhau, và việc hoán đổi chúng là lý do phổ biến nhất khiến một cái tên đang hoạt động vẫn không trả về gì hữu ích.

Bước 1: xác lập phạm vi của môi trường và ứng dụng

Đọc cấu hình ingress của ứng dụng trước khi thay đổi bất kỳ bản ghi nào:

Ingress nội bộ được hiển thị trên bộ cân bằng tải nội bộ của môi trường bên trong VNet của môi trường, vì vậy câu hỏi không phải là máy tính xách tay có phải một ứng dụng container khác không, mà là nó có tiếp cận được VNet đó không. Một máy khách VPN có tuyến vào VNet và miền mặc định của môi trường được phân giải qua vùng riêng là người gọi đủ điều kiện, và đó chính là điều các bước còn lại xây dựng. Một môi trường nội bộ không có lối vào công cộng là sự thật khác với ứng dụng có ingress nội bộ, và ingress bên ngoài ở cấp ứng dụng không cho môi trường một cánh cửa công cộng. Hãy ghi phạm vi vào phiếu và cả cổng thông tin, vì kỹ sư tiếp theo đọc phiếu trước.

Xác nhận phạm vi đó với chủ sở hữu cấu hình trước khi tiếp tục, và giữ cổng hẹp: nếu không có tuyến vào VNet của môi trường, hoặc miền mặc định của môi trường không phân giải qua vùng riêng, hãy dừng lại và sửa đường đó trước. Không bước nào sau đó có thể thay thế một người gọi không tiếp cận được VNet hoặc không phân giải được tên.

Bước 2: thu thập tên máy chủ thật và địa chỉ lối vào

Ghi lại miền mặc định của môi trường, địa chỉ lối vào riêng tĩnh của nó và FQDN đã cấu hình của ứng dụng, lấy từ tài nguyên chứ không phải từ ảnh chụp màn hình cũ hay trang wiki:

az containerapp env show -n ENV -g RG \
  --query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
  --query "properties.configuration.ingress.fqdn"

Hướng dẫn về lối vào riêng của Container Apps mô tả việc khớp miền của môi trường với địa chỉ nội bộ của nó trong khi giữ nguyên tên máy chủ của ứng dụng. Đó chính xác là hình dạng bạn đang dựng thủ công ở đây, vì vậy hãy căn nội dung vùng theo nó thay vì phát minh một sơ đồ đặt tên mới.

Nếu miền bạn đọc không khớp với FQDN mà ứng dụng báo cáo, hãy dừng lại và đối chiếu ngay. Dựng vùng trên hậu tố sai tạo ra một tên máy chủ phân giải hoàn hảo và vẫn rơi vào máy chủ ảo sai.

Bước 3: đặt vùng riêng trên đường phân giải của VPN

Tạo hoặc dùng lại vùng DNS riêng được hỗ trợ cho miền mặc định thực tế của môi trường, với các bản ghi ký tự đại diện và địa chỉ có tài liệu trỏ đến lối vào tĩnh. Liên kết vùng đó với mạng ảo phù hợp, và làm cho cơ quan riêng có thể tiếp cận qua đường phân giải đã phê duyệt của VPN thay vì giả định rằng liên kết là đủ.

Máy khách điểm tới trang thường cần một điểm cuối đến của trình phân giải riêng hoặc một bộ chuyển tiếp DNS được hỗ trợ để tiếp cận vùng đó. Việc liên kết vùng thay đổi điều Azure phân giải cho các mạng được liên kết; nó không chuyển hướng trình phân giải công cộng của mọi máy tính xách tay bên ngoài. Đừng thay thế nó bằng vùng DNS điểm cuối riêng vay mượn từ mô hình mạng Container Apps khác, vì tên bản ghi và hậu tố vùng sẽ không khớp.

Khôi phục cho bước này là xóa liên kết vùng hoặc bản ghi bạn đã thêm. Ghi lại đó là cái nào, vì xóa một vùng dùng chung để hoàn tác một liên kết là cách nổi tiếng để làm hỏng môi trường thứ hai.

Bước 4: kiểm tra tên, sau đó kiểm tra đối tượng bị từ chối

Kiểm tra tên máy chủ và danh tính TLS cùng nhau, không chỉ địa chỉ. Để chẩn đoán ánh xạ tên có kiểm soát, bạn có thể ghim địa chỉ trong khi giữ tên máy chủ:

curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
    https://app.ENVIRONMENT_DOMAIN/

Thay tên máy chủ bằng FQDN thật của ứng dụng và thay địa chỉ bằng lối vào nội bộ thật. Điều này chỉ ảnh hưởng đến một yêu cầu đó và không phải việc cấp phát DNS. Đừng thêm -k để biến lỗi danh tính thành một lần vượt qua bề ngoài, vì chứng chỉ không khớp là dấu hiệu cho thấy bạn đang đánh vào trình lắng nghe sai.

Yêu cầu trực tiếp địa chỉ số có thể chọn sai máy chủ ảo hoặc làm xác thực thất bại ngay cả khi TCP 443 trả lời, vì vậy hãy coi một bài kiểm tra IP thành công là bằng chứng về mạng và không hơn. Từ máy tính xách tay dự kiến, đường phân giải bình thường là bộ chuyển tiếp DNS của máy khách hoặc điểm cuối đến của trình phân giải riêng lưu trữ vùng, và lỗi ở đó là vấn đề khả năng tiếp cận của trình phân giải, không phải bản ghi bị thiếu. Xác nhận cùng yêu cầu thành công trên đường đó, sau đó xác nhận đối tượng bị từ chối vẫn bị từ chối.

Những gì cần ghi lại và những gì cần khôi phục

Cổng đích của container và cổng HTTPS của máy khách là các thiết lập riêng. Đừng công bố cổng đích của container qua VPN vì container lắng nghe ở đó, và đừng mở rộng quy tắc mạng để một bài kiểm tra cổng vượt qua. Cả hai thay đổi đều tồn tại sau sự cố và khó quy trách nhiệm về sau.

Kết thúc bằng một thao tác ứng dụng mới từ máy tính xách tay dự kiến, với danh tính được ủy quyền và DNS bình thường của nó, sau đó kiểm tra rằng một người gọi không được ủy quyền vẫn thất bại. Trong khi bạn ở trong cấu hình ứng dụng, cũng xác nhận xem một tuyến HTTP ở cấp môi trường có đưa ứng dụng này làm mục tiêu hay không, vì tuyến đó là cánh cửa thứ hai mà phạm vi ingress không mô tả.

Ghi lại năm giá trị cùng nhau: phạm vi môi trường, phạm vi ingress của ứng dụng, FQDN, địa chỉ lối vào riêng và chủ sở hữu trình phân giải. Năm giá trị đó mô tả toàn bộ hợp đồng truy cập, và người tiếp theo gỡ lỗi nó sẽ hỏi đúng những giá trị ấy.