Azure CLI proxy phân loại TLS và quyền truy cập

Azure CLI proxy thường gặp lỗi ở nhiều lớp: gateway, chứng chỉ doanh nghiệp, đăng nhập Entra và quyền subscription. Hãy kiểm bằng lệnh chỉ đọc, xác định request nào thực sự ra mạng và giữ thông tin đăng nhập ngoài log hỗ trợ. ProxyVN hướng dẫn anh em đặt cấu hình đúng phạm vi và kiểm đầu ra trước khi áp dụng.

Azure CLI proxy và phạm vi của tác vụ

Azure CLI chạy trong môi trường có HTTP client và trust store riêng. Khi doanh nghiệp kiểm tra TLS bằng CA nội bộ, CLI có thể báo lỗi certificate dù browser vẫn hoạt động. Lý do cần kiểm môi trường Python của CLI, không chỉ nơi lưu chứng chỉ của trình duyệt.

Đăng nhập Entra, lựa chọn tenant và lựa chọn subscription là các bước danh tính khác với xác thực gateway. Một request đi đúng proxy vẫn có thể bị API từ chối vì role chưa đủ, token hết hạn hoặc ngữ cảnh account sai. Ngược lại lỗi 407 xảy ra ở gateway chưa phản ánh quyền Azure.

Không phải mọi lệnh az đều gửi request. az account show có thể đọc ngữ cảnh đã lưu; dùng nó để biết tài khoản hiện tại nhưng không coi là phép đo tuyến. Một lệnh list hay az rest chỉ đọc tới endpoint quản lý mới phù hợp hơn khi cần quan sát request mạng.

Bài này dùng môi trường lab và không thay subscription mặc định của người dùng. Với lệnh chỉ đọc, vẫn cần giữ kín account ID, token và dữ liệu tổ chức trong log. Kết luận hỗ trợ proxy phải gắn với bản CLI, cơ chế auth và CA thực sự đã được thử.

Các tên khóa và tùy chọn cần được đối chiếu với tài liệu chính thức của công cụ. Phần hướng dẫn dưới là thiết kế triển khai và ca kiểm minh họa, không phải báo cáo đã chạy tất cả các trường hợp trên một gateway thương mại.

Azure CLI proxy chuẩn bị đầu vào có thể kiểm lại

Ghi az version và xác nhận tenant subscription lab trước khi chạy. Chuẩn bị gateway Basic hoặc cơ chế được nhóm hỗ trợ; nếu có TLS inspection, lấy CA bundle PEM từ bộ phận quản lý. Đặt biến trong một shell riêng và giữ bản cấu hình CA nguyên gốc, tránh chỉnh trực tiếp file chứng chỉ của CLI đang cài.

Đặt mục tiêu của bài thử ở Azure CLI trong mạng doanh nghiệp, với đầu ra là account list được làm mới. Trước khi chạy, ghi trạng thái ban đầu và xác định nơi sẽ quan sát tenant subscription và endpoint. Nếu chưa có nguồn dữ liệu hoặc môi trường tương ứng, giữ ca đó ở trạng thái chưa chạy; không lấy một thông báo cú pháp hợp lệ thay cho kết quả truyền dữ liệu.

Thư mục phiên az kiểm chỉ đọc cần tách khỏi dữ liệu đang vận hành. Mẫu REQUESTS_CA_BUNDLE chỉ chứa địa chỉ minh họa và tên biến; credential thật được cấp từ môi trường thử. Những ví dụ dùng Bash và PowerShell sẽ được ghi trong phần giải thích, vì cách đặt biến và quoting giữa hai shell khác nhau. Không dán nguyên cấu hình nhiều định dạng vào cùng một file.

Cấu hình đúng phạm vi

Azure CLI proxy ví dụ cấu hình tối thiểu

Các địa chỉ .test và giá trị biến dưới đây phải được thay bằng hạ tầng lab do anh em quản lý. Nội dung cấu hình và lệnh chạy được đặt chung để tiện theo dõi, nhưng cần lưu vào đúng file hoặc shell như phần giải thích. Không dùng credential thật trong bản sao để chia sẻ.

# PowerShell trong phien rieng
az version
$env:HTTP_PROXY = $env:LAB_PROXY_URL
$env:HTTPS_PROXY = $env:LAB_PROXY_URL
# Neu mang lab yeu cau CA noi bo
# $env:REQUESTS_CA_BUNDLE = "C:/lab/ca-bundle.pem"
az account show --query "{tenant:tenantId,subscription:id}" --output json
az account list --refresh --query "[].{id:id,state:state}" --output json

Lệnh account show dùng để kiểm ngữ cảnh; account list --refresh yêu cầu làm mới danh sách và cần kết nối cùng danh tính hợp lệ. Không đưa output chứa ID thật vào bài công khai. Nếu chưa đăng nhập môi trường lab, không nhận rằng lỗi của lệnh list đã kiểm được gateway.

REQUESTS_CA_BUNDLE được tài liệu Azure CLI nêu cho tình huống CA của mạng doanh nghiệp. Đường dẫn cần chứa bundle đúng định dạng và đọc được bởi tiến trình CLI. Việc đặt biến vào terminal không tự thêm CA vào mọi extension, subprocess hay ứng dụng khác.

Ví dụ không chạy az login thay người dùng và không dùng tùy chọn ghi tài nguyên. Nếu cần thiết lập đăng nhập lab, làm theo quy trình tổ chức rồi quay lại phép kiểm. Dòng auth token, bearer header và bộ nhớ đăng nhập không nằm trong artifact chia sẻ.

Azure CLI proxy cơ chế và nguồn cấu hình

Nhóm ca đầu xác định cơ chế của Azure CLI trong mạng doanh nghiệp. Kiểm nguồn cấu hình trước khi đo đường mạng giúp nhận ra trường hợp công cụ đang dùng một giá trị khác với file vừa sửa.

Context cục bộ và request mạng

Một lệnh đọc account đã lưu có thể thành công mà không xác minh được tuyến tới Azure.

Cách thực hiện trong lab: Dùng account show để xác định ngữ cảnh rồi account list --refresh cho phép kiểm kết nối.

Bắt đầu phần context cục bộ và request mạng bằng một giả thuyết có thể kiểm. Với Azure CLI trong mạng doanh nghiệp, điều cần xác định trước tiên là thành phần nào thực hiện kết nối và thành phần nào chỉ đọc cấu hình. Nếu hai vai trò bị gộp, một giá trị lưu đúng trong REQUESTS_CA_BUNDLE có thể bị coi nhầm là bằng chứng request đã đi đúng tuyến.

Lập một hàng thử có tên riêng trước khi gọi lệnh. Hàng đó cần ghi phiên bản công cụ, vị trí thực thi, đầu vào được cấp và trạng thái account list được làm mới trước lượt chạy. Các thông tin này giải thích được vì sao cùng một lệnh có thể tạo request ở máy này nhưng không tạo ở máy khác, nhất là khi đã có dữ liệu từ lần trước.

Khi đọc kết quả, tách phần công cụ báo khỏi phần hệ thống đối chứng quan sát. Dòng thông báo trong terminal mô tả phía client; log origin hoặc gateway mô tả nơi nhận kết nối. Chỉ nối hai dữ liệu bằng thời điểm và mã lượt phù hợp, tránh ghép một log cũ với output mới rồi suy rằng cả quy trình đã được xác minh.

Điều kiện chấp nhận: Báo cáo tách dữ liệu cache khỏi request mới và đối chiếu thời điểm với gateway. Không dùng một output JSON từ cache làm bằng chứng gateway đang hoạt động.

HTTP_PROXY và HTTPS_PROXY

Biến môi trường cần nằm trong shell thực sự khởi chạy az và không mâu thuẫn runner.

Cách thực hiện trong lab: Đặt gateway ở phiên PowerShell riêng rồi gọi lệnh chỉ đọc với profile lab đã đăng nhập.

Phép so cho http_proxy và https_proxy cần hai điều kiện chỉ khác ở yếu tố đang đánh giá. Giữ nguyên phiên bản, nguồn dữ liệu và danh tính lab khi thay cách cấu hình Azure CLI trong mạng doanh nghiệp. Nếu đồng thời đổi nguồn hoặc trạng thái account list được làm mới, kết quả khác nhau sẽ không chỉ ra được tác động của tuyến mạng.

Tạo bản mô tả đầu vào trước mỗi lượt thay vì ghi nhớ bằng mắt. Với cấu hình REQUESTS_CA_BUNDLE, chỉ lưu các giá trị không nhạy cảm cùng tên nơi cấp secret. Có thể ghi rằng credential đến từ môi trường hoặc kho bí mật mà không chụp toàn bộ màn hình chứa giá trị. Thông tin để tái lập và thông tin bí mật là hai loại dữ liệu cần quản lý riêng.

So đầu ra theo điều kiện của ca, không chỉ theo tốc độ kết thúc. tenant subscription và endpoint cần được đánh giá trong ngữ cảnh lượt chạy và trạng thái dữ liệu ban đầu. Một lượt chạy nhanh vì không phải làm tác vụ mạng vẫn có thể đúng chức năng, nhưng chưa phù hợp để so đường kết nối với lượt thật sự truyền dữ liệu.

Điều kiện chấp nhận: Log cho thấy CLI gọi endpoint dự kiến qua gateway trong đúng khoảng thử. Nếu chạy từ IDE hay scheduler, kiểm môi trường của tiến trình đó thay vì terminal khác.

Đối chứng đầu ra

Azure CLI proxy đối chứng dữ liệu và trạng thái

Nhóm tiếp theo tập trung vào account list được làm mới. So dữ liệu và trạng thái ban đầu giúp phân biệt thao tác mới với kết quả được tái sử dụng từ lượt trước.

CA bundle cho Python requests

Azure CLI có thể cần CA nội bộ qua REQUESTS_CA_BUNDLE khi mạng kiểm tra TLS.

Cách thực hiện trong lab: Tạo bản bundle riêng với CA được cấp, kiểm đường dẫn rồi thử lại cùng lệnh đọc.

Đầu ra của ca bundle cho python requests cần một điều kiện chấp nhận cụ thể. Với account list được làm mới, việc đối tượng hoặc đường dẫn xuất hiện chưa nói nội dung đã đúng, đầy đủ hay thuộc lượt chạy hiện tại. Xác định dấu hiệu cuối cùng cần có trước khi bắt đầu giúp tránh thay tiêu chuẩn theo output vừa nhìn thấy.

Lưu dữ liệu đối chứng từ phía nguồn hoặc từ trạng thái đã được nhóm kiểm soát. Đừng tạo giá trị mong đợi bằng chính output đang cần đánh giá rồi so hai thứ với nhau. Khi tenant subscription và endpoint có nhiều thành phần, kiểm từng thành phần và ghi phần nào chưa có bằng chứng, thay vì gộp chúng thành một nhãn thành công duy nhất.

Nếu công cụ trả dữ liệu dở, giữ bản nhỏ có thể tái hiện lỗi và ghi giai đoạn đã hoàn thành. Thành công ở tầng kết nối có thể đi cùng thất bại ở tầng xác thực, tải nội dung hoặc xử lý đầu ra. Phân biệt các mốc đó giúp người nhận chọn đúng lớp cần sửa và không làm lại mọi thiết lập của REQUESTS_CA_BUNDLE.

Điều kiện chấp nhận: TLS được xác minh và không phải bỏ kiểm chứng certificate để request hoàn tất. Một file PEM sai hoặc thiếu chain cần được xử lý ở trust store, chưa đổi tài khoản proxy.

Proxy auth và đăng nhập Entra

Danh tính của gateway khác danh tính người dùng hoặc service principal trên Entra.

Cách thực hiện trong lab: Kiểm lần lượt lỗi proxy credential rồi lỗi đăng nhập lab trong khi giữ phần còn lại.

Trạng thái trước lượt kiểm ảnh hưởng trực tiếp đến proxy auth và đăng nhập entra. Trong Azure CLI trong mạng doanh nghiệp, cần xem context cache và request API đang được tạo mới, tái sử dụng hay giữ lại từ lần trước. Cùng câu lệnh nhưng khác trạng thái ban đầu có thể thực hiện lượng công việc khác nhau, nên so kết quả mà bỏ qua điều này dễ dẫn tới chẩn đoán sai.

Tạo một mốc có kiểm soát trong phiên az kiểm chỉ đọc. Ghi artifact nào đã có sẵn và artifact nào phải được tạo trong lượt mới. Nếu cần thử lại từ đầu, chỉ dùng đường dẫn thử riêng đã được nhận diện; không dọn kho dữ liệu dùng chung để ép công cụ phát sinh một request. Mục tiêu là kiểm hành vi, không thay đổi môi trường làm việc của người khác.

Sau khi chạy, so trạng thái trước và sau theo đúng ca. Sự khác nhau trong account list được làm mới phải được giải thích bằng thao tác dự kiến chứ không bằng một tác vụ nền ngoài hồ sơ. Khi công cụ có cơ chế tái sử dụng kết nối hoặc dữ liệu, thêm một lượt mới và một lượt lặp để người đọc hiểu vì sao lượng request có thể khác.

Điều kiện chấp nhận: 407 được tách khỏi lỗi tenant token và quyền của account Azure. Không dùng secret service principal làm mật khẩu gateway vì cơ chế nhận khác nhau.

Azure CLI proxy phân loại lỗi và giới hạn

Các ca sau đánh giá điều kiện lỗi và khả năng của phiên bản đang dùng. Mục tiêu là nhận đúng giới hạn của Azure CLI trong mạng doanh nghiệp, không biến mọi thất bại thành lỗi gateway.

Tenant và subscription đúng mục tiêu

Tài khoản có thể đăng nhập nhưng đang nhìn tenant hoặc subscription khác môi trường muốn kiểm.

Cách thực hiện trong lab: Ghi các ID đã che một phần từ context rồi đối chiếu inventory lab của tổ chức.

Chẩn đoán tenant và subscription đúng mục tiêu nên theo thứ tự sự kiện của Azure CLI trong mạng doanh nghiệp. Xác định thông báo xuất hiện trước khi mở kết nối, tại gateway, khi liên lạc origin hay lúc xử lý account list được làm mới. Thứ tự này quan trọng hơn việc mọi lỗi có chung chữ proxy trong mô tả người dùng.

Mỗi lần sửa chỉ đổi một nguyên nhân có giả thuyết. Nếu thông báo liên quan danh tính, giữ URL và dữ liệu nguồn như cũ rồi kiểm lớp auth tương ứng. Nếu lỗi thuộc quyền đọc file cấu hình hoặc quyền ghi đầu ra, xử lý quyền đó trước. Không thay cả secret, endpoint và tham số proxy auth cùng TLS inspection trong cùng một lượt rồi nhận rằng đã tìm ra nguyên nhân.

Dùng ca âm có kiểm soát để kiểm chất lượng phân loại lỗi. Chỉ thay một đầu vào lab thành giá trị không hợp lệ, đặt thời hạn kết thúc và xem chương trình phản hồi thế nào. Sau ca âm, khôi phục giá trị rồi chạy lại mốc; nếu mốc vẫn lỗi, môi trường chưa trở lại điều kiện để tiếp tục các phép so.

Điều kiện chấp nhận: Lệnh đọc dùng đúng ngữ cảnh đã được cấp quyền mà không sửa mặc định của người khác. Danh sách rỗng cần kiểm quyền và tenant trước khi nhận rằng proxy làm mất dữ liệu.

Endpoint đăng nhập và quản lý

Luồng lấy token và luồng gọi API quản lý có thể đi tới các hostname khác nhau.

Cách thực hiện trong lab: Theo dõi từng giai đoạn trong lab và xây allowlist từ endpoint thực sự cần thiết.

Khả năng của endpoint đăng nhập và quản lý cần được kiểm theo đúng phiên bản đang dùng. Một tùy chọn xuất hiện trong tài liệu hiện hành chưa chứng minh binary cũ trên máy đã nhận nó. Trước khi dùng kết quả để hướng dẫn người khác, đối chiếu trợ giúp của công cụ và thông tin phiên bản với cú pháp trong REQUESTS_CA_BUNDLE.

Với Azure CLI trong mạng doanh nghiệp, lưu cả môi trường thực thi nếu có nhiều máy hoặc tiến trình. Hệ điều hành, backend TLS, công cụ con và vị trí phân giải hostname đều có thể tạo khác biệt. Đừng lấy kết quả của trình duyệt trên laptop để thay cho tiến trình chạy trong máy ảo, container hay node khác khi bài kiểm đang nhắm môi trường đó.

Giữ những giả định chưa kiểm ở một cột riêng trong hồ sơ. Entra token và extension có thể cần một bộ dữ liệu hoặc cơ chế transport khác với ca hiện tại. Việc ghi chưa kiểm không làm mất giá trị kết quả đã có; nó giúp tránh mở rộng một quan sát nhỏ thành lời cam kết vượt quá phạm vi.

Điều kiện chấp nhận: Gateway cho phép đủ host của luồng được kiểm, không chỉ một URL trang đăng nhập. Mở được portal trong browser không chứng minh CLI gọi được mọi endpoint của luồng auth.

Phân biệt các lớp lỗi

Azure CLI proxy vận hành và bàn giao

Nhóm cuối giữ đủ hồ sơ để người khác tiếp tục trong phiên az kiểm chỉ đọc. Cấu hình mẫu, dữ liệu đã che và việc hoàn nguyên cần được kiểm trước khi bàn giao.

Extension và công cụ con

Extension hoặc subprocess có thể dùng thư viện mạng và CA khác phần lõi Azure CLI.

Cách thực hiện trong lab: Giữ lệnh lõi làm ca cơ sở rồi thêm đúng extension cần dùng trong bài thử riêng.

Quản lý dữ liệu cho extension và công cụ con cần giữ đủ khả năng truy nguyên mà không lộ bí mật. Trong Azure CLI trong mạng doanh nghiệp, log có thể chứa địa chỉ gateway, URL nguồn, thông tin danh tính và đường dẫn account list được làm mới. Chọn dữ liệu cần lưu theo mục đích chẩn đoán, tránh thu tất cả rồi mới tìm cách che sau.

Tạo bản log làm việc ở nơi có quyền phù hợp và một bản chia sẻ đã được rà. Khi che giá trị, giữ cấu trúc giúp nhận diện loại dữ liệu, chẳng hạn hostname, loại auth và mã trạng thái không nhạy cảm. Nếu che đến mức mất cả endpoint và thời điểm, người nhận khó khớp với tenant subscription và endpoint và không còn đủ dữ liệu để kiểm giả thuyết.

File cấu hình cũng cần phân loại tương tự. Mẫu REQUESTS_CA_BUNDLE có thể được chia sẻ khi chỉ chứa tên biến và địa chỉ minh họa; bản đang chứa token hoặc userinfo phải được xử lý riêng. Xóa secret khỏi phiên bản cuối chưa đủ nếu nó đã nằm trong lịch sử repository, archive cũ hoặc log của runner đã được phát hành.

Điều kiện chấp nhận: Bảng kết quả ghi tên version extension và tiến trình gọi request. Không mở rộng kết luận lệnh account sang mọi extension có mặt trên máy.

Quản lý log và phiên thử

Az debug và dữ liệu account có thể làm lộ thông tin tổ chức dù lệnh chỉ đọc.

Cách thực hiện trong lab: Giữ log tối thiểu, che token cùng ID nhạy cảm rồi phục hồi biến môi trường ban đầu.

Kết thúc quản lý log và phiên thử là một bước của phép thử, không chỉ là đóng cửa sổ terminal. Kiểm Azure CLI trong mạng doanh nghiệp còn tác vụ nền hay tài nguyên đang hoạt động không, và account list được làm mới đã ở trạng thái cuối hay đang tiếp tục thay đổi. Chốt kết quả khi còn tiến trình ghi dữ liệu có thể làm hash hoặc metadata không ổn định.

Lưu các giá trị ban đầu của môi trường trước khi phục hồi cấu hình. Với REQUESTS_CA_BUNDLE, cần phân biệt giá trị chỉ sống trong một tiến trình với cấu hình được lưu cho các lượt sau. Một lần bỏ biến trong shell không xóa được giá trị đã ghi vào profile hoặc file; ngược lại không cần sửa cấu hình toàn máy nếu chỉ một phiên thử bị ảnh hưởng.

Chạy lại mốc sau hoàn nguyên bằng dữ liệu nhỏ đã biết. Mục đích là xác nhận môi trường trở về điều kiện dự kiến và không còn thừa hưởng trạng thái lỗi do ca trước tạo ra. Ghi kết quả cuối cùng cùng thời điểm để người nhận hiểu đâu là output cuối, đâu là log của giai đoạn sửa lỗi.

Điều kiện chấp nhận: Bản hỗ trợ có status endpoint và CA source nhưng không chứa bộ token đăng nhập. Không gửi cả thư mục .azure để làm ví dụ cho một lỗi chứng chỉ.

Azure CLI proxy đọc kết quả theo đúng phạm vi

Quy trình Azure nên bắt đầu bằng việc nhận diện context cục bộ, sau đó mới chọn một thao tác buộc làm mới dữ liệu. Nếu account show đọc thông tin đã lưu, kết quả của nó chỉ nói CLI có context. Gateway đã tắt mà lệnh vẫn in JSON trong trường hợp này không phải một phép chứng minh bypass.

REQUESTS_CA_BUNDLE phải trỏ tới file có thật và tiến trình CLI đọc được. Khi bổ sung CA doanh nghiệp, giữ bundle gốc và tạo một bản thử riêng. Cần xác định chain tin cậy và hostname, không chèn một certificate bất kỳ chỉ vì nó được lấy từ trang lỗi trình duyệt.

Đăng nhập Entra có thể chạm các endpoint khác với API quản lý Azure. Một allowlist chỉ cho host quản lý có thể khiến việc làm mới token lỗi. Bản hỗ trợ nên mô tả giai đoạn thất bại và hostname liên quan để nhóm mạng biết đang xử lý đường auth hay đường API.

Kết quả không có subscription còn có thể do tenant hoặc quyền của danh tính lab. Không sửa subscription mặc định của công việc khác để làm phép thử. Sử dụng context riêng và giữ các ID ở dạng đã che trong tài liệu, nhất là khi log được chuyển ra ngoài nhóm vận hành.

Khi chẩn đoán, có thể tra cơ chế HTTP proxy và tunnel của MDN, ý nghĩa HTTP status và cơ sở kiểm chứng TLS. Các tài liệu giao thức giúp hiểu nguyên nhân, còn kết luận tương thích vẫn cần phép thử trên công cụ và môi trường cụ thể.

Nếu cần rà cấu trúc đầu vào, dùng hướng dẫn định dạng proxy. Khi có bypass, đối chiếu khái niệm no_proxy với quy tắc riêng của công cụ; cùng một chuỗi host không được mặc định có ý nghĩa giống nhau ở mọi runtime.

Một tùy chọn được chấp nhận, một kết nối thành công và một đầu ra đúng là ba điều kiện cần được kiểm riêng.

Hồ sơ bàn giao

Khi cần mua proxy uy tín cho Azure CLI trong mạng doanh nghiệp, anh em nên xác nhận giao thức, cách cấp tài khoản và khả năng kết nối từ môi trường thực thi, rồi thử bằng đầu ra nhỏ có đối chứng trước khi chọn cấu hình dùng lâu dài.

Anh em nên giữ cấu hình mẫu và kết quả từng ca trước khi mở rộng tác vụ. Theo dõi Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam để tham khảo nội dung liên quan. Khi thay phiên bản hoặc môi trường, kiểm lại đầu ra và phạm vi của Azure CLI proxy.