Ngiêm cấm sử đụng PROXY và VPS vào mục đích trái pháp luật bạn sẽ phải chịu toàn bộ trách nhiệm trước pháp luật khi sử dụng dịch vụ của chúng tôi tks!
Envoy dynamic forward proxy: DNS cache và chặn đích lạ

Envoy dynamic forward proxy: DNS cache và chặn đích lạ

Chuyên viên Kỹ thuật ProxyVN 09-02-2026 Đang tính... phút đọc

Envoy dynamic forward proxy là cách dùng Envoy làm proxy chuyển tiếp: Envoy đọc tên máy đích từ yêu cầu, phân giải bằng DNS cache rồi kết nối tới đó. ProxyVN đọc tài liệu Envoy ngày 27/10/2026, dựng cấu hình lab có giới hạn đích và chạy script soát YAML. Bài chưa chạy Envoy gốc.

Envoy dynamic forward proxy: vai trò và khác biệt với proxy IP mua ngoài

Envoy là proxy tầng bảy do Cloud Native Computing Foundation bảo trợ, hay gặp trong service mesh và cổng vào của hệ thống lớn. Bài này không bàn Envoy ở vai trò sidecar hay mesh. Bài chỉ bàn một bộ phận hẹp: dynamic forward proxy.

Trang tài liệu bộ lọc dynamic forward proxy mô tả cách cấu hình Envoy để nó hoạt động như một HTTP forward proxy. Điểm đặc trưng: đích không khai sẵn trong cấu hình. Envoy lấy tên máy từ chính yêu cầu, rồi tự phân giải và kết nối.

Khác gì proxy IP mua ngoài

Proxy IP mua ngoài là dịch vụ của nhà cung cấp, cho anh em IP ở vùng và nhà mạng cụ thể. Envoy là phần mềm anh em tự chạy trên máy của mình. IP thoát của nó là IP của máy chạy Envoy. Envoy không bán IP và không thay được gói proxy thương mại.

Bài forward proxy là gì giải thích khái niệm chung. Bài reverse proxy là gì nói về hướng ngược. Envoy làm được cả hai, và cấu hình ở bài này thuộc hướng forward.

Khi nào nên dùng

Anh em cần một cổng proxy trong hệ thống nội bộ, nơi các dịch vụ muốn gọi ra ngoài qua một điểm kiểm soát duy nhất. Điểm đó ghi log, giới hạn đích, đặt giới hạn kết nối và cache DNS. Đó là việc của dynamic forward proxy, không phải việc chọn IP thoát theo vùng.

Khác Envoy sidecar và service mesh

Trong service mesh, mỗi dịch vụ có một Envoy đi kèm, đích thường là dịch vụ khác trong mạng, và cấu hình do mặt phẳng điều khiển đẩy xuống. Ở bài này, đích là tên miền bất kỳ trên Internet, và cấu hình là một tệp tĩnh. Hai bài toán khác nhau, nên đừng chép cấu hình mesh sang đây.

Mình đã chạy gì, chưa chạy gì

Mình không tải hay chạy tệp thực thi từ bên ngoài trong lần viết này, nên chưa chạy Envoy. Phần đã chạy là script envoy_check.py do mình viết bằng Python với thư viện PyYAML. Script soát cấu hình và mô hình hóa hai quy tắc chặn theo cách đọc tài liệu của mình. Kết quả ghi nguyên văn bên dưới. Mọi hành vi của Envoy thật là điều anh em cần xác nhận.

Dựng Envoy dynamic forward proxy: DNS cache và giới hạn đích

Filter, DNS cache và cluster dùng chung một khối

Filter, DNS cache và cluster dùng chung một khối

Tài liệu nói bộ lọc HTTP và cluster dynamic forward proxy phải cấu hình cùng nhau và trỏ tới cùng một tham số DNS cache. Thiếu một trong hai thì Envoy không hoạt động như proxy chuyển tiếp.

Ba thành phần cần có

Thành phần đầu là bộ lọc HTTP envoy.filters.http.dynamic_forward_proxy. Nó lấy tên máy đích từ yêu cầu, thường là tiêu đề Host hay :authority, rồi yêu cầu DNS cache phân giải. Thành phần thứ hai là DNS cache, nơi lưu kết quả phân giải. Thành phần thứ ba là cluster loại envoy.clusters.dynamic_forward_proxy, nơi kết nối thật tới địa chỉ đã phân giải.

Cluster dùng chính sách cân bằng tải CLUSTER_PROVIDED. Giá trị này có trong ví dụ đầy đủ của tài liệu, và script của mình báo lỗi nếu cluster dùng chính sách khác.

DNS cache làm những gì

Cấu hình DNS cache nằm ở trang dns_cache.proto. Các trường quan trọng với bài này như sau.

Bảng: DNS cache làm những gì

Trường

Ý nghĩa theo tài liệu

Mặc định

name

Tên cache, filter và cluster phải trỏ cùng tên

Bắt buộc

dns_lookup_family

Họ địa chỉ khi phân giải, ví dụ V4_ONLY

Theo cluster

dns_refresh_rate

Tần suất phân giải lại với host chưa phân giải được

60 giây

dns_min_refresh_rate

Mức tối thiểu khi dùng TTL của DNS

5 giây

host_ttl

Thời gian bỏ host không dùng khỏi cache

5 phút

max_hosts

Số host tối đa trong cache

1024

dns_query_timeout

Hạn của một truy vấn DNS

5 giây

preresolve_hostnames

Phân giải trước khi cache tạo

Không

resolved_address_filter

Loại địa chỉ khớp dải ra khỏi kết quả

Không

Bảng chép từ trang tài liệu bản hiện hành. Khi host đã phân giải, chu kỳ làm mới là TTL của DNS, nhưng không nhỏ hơn dns_min_refresh_rate. Anh em nên kiểm số phiên bản Envoy đang chạy, vì tài liệu mình đọc là bản phát triển 1.41, và vài trường có thể chưa có ở bản cũ.

Hai tầng circuit breaker

Tài liệu nêu hai loại. Loại một là circuit breaker của DNS cache, qua trường dns_cache_circuit_breaker, giới hạn số yêu cầu phân giải đang chờ để khỏi dồn dập vào máy chủ DNS. Envoy dùng giá trị mặc định ngay cả khi anh em không khai. Loại hai là circuit breaker chuẩn của cluster, giới hạn kết nối, yêu cầu đang chờ, yêu cầu và số lần thử lại.

Cả hai đều quan trọng với forward proxy mở, vì một client lỗi vòng lặp có thể tạo hàng nghìn tên miền khác nhau. Ví dụ đầy đủ của tài liệu đặt 1024 cho các ngưỡng. Lab của mình đặt 64 cho dễ thấy.

Giới hạn đích: cảnh báo confused deputy

Tài liệu có một cảnh báo dài, mình nêu ý chính. Máy chủ chạy dynamic forward proxy trong môi trường mà client hoặc đích không đáng tin dễ bị tấn công kiểu confused deputy. Client có thể bảo proxy truy cập cổng trên localhost của máy proxy, địa chỉ link-local, máy chủ metadata của nhà cung cấp đám mây, hoặc mạng riêng nơi proxy chạy. Đích không đáng tin cũng có thể dựng bản ghi DNS trỏ vào các nơi đó.

Tài liệu khuyên bảo vệ bằng tường lửa mạng, RBAC mặc định từ chối và các giới hạn mạng của container hoặc nhân hệ điều hành. Cũng có lời nhắc: mọi địa chỉ proxy tới được đều có thể bị client không đáng tin truy cập. Toàn bộ phần chặn bên dưới là hệ quả của cảnh báo này.

Chuẩn bị topology lab, phiên bản, listener và backend cho Envoy dynamic forward proxy

Một bài kiểm thử có ích cần sơ đồ rõ ràng và phiên bản đã ghi. Với Envoy, vì mô hình cấu hình rất nhiều lớp, việc ghi lại điều kiện càng cần thiết.

Sơ đồ lab

Bốn thành phần: client là curl, Envoy chạy ở 127.0.0.1:10000, một DNS giả hoặc tệp hosts để các tên miền đuôi .test phân giải ra backend, và hai backend. Backend thứ nhất là trang đích được phép, ví dụ shop-a.test:8901. Backend thứ hai là một dịch vụ giả nằm ở địa chỉ mà proxy không được phép tới, để thử chặn.

Admin của Envoy nghe 127.0.0.1:9901. Giữ cả hai cổng ở loopback. Cổng admin cho xem cấu hình và thống kê, không được phơi ra ngoài.

Phiên bản

Trang lịch sử phiên bản ngày 27/10/2026 liệt kê bản ổn định mới nhất 1.40.0, phát hành 13/10/2026, và bản đang phát triển 1.41.0. Các trang tài liệu mình đọc ghi "latest" nên thuộc nhánh phát triển. Chạy envoy --version và ghi lại, rồi đối chiếu từng trường với tài liệu đúng nhánh của bản đang chạy.

Địa chỉ nghe và cổng admin

Ví dụ gốc của tài liệu cho listener nghe 0.0.0.0:10000. Mình đổi thành 127.0.0.1 cho lab. Nếu anh em nghe 0.0.0.0, bất kỳ ai tới được cổng đều dùng được proxy. Script của mình báo cảnh báo cho listener không phải loopback và báo lỗi cho cổng admin không phải loopback.

Phân giải tên trong lab

Tên miền đuôi .test cần được phân giải bởi DNS mà Envoy dùng. Tài liệu có ví dụ trỏ resolver C-ares tới 8.8.8.8:53. Với lab, trỏ resolver tới một DNS giả cục bộ hoặc dùng tệp hosts nếu bản Envoy hỗ trợ. Mình chưa thử việc này.

Bài DNS leak khi dùng proxy giải thích vì sao ai phân giải tên quan trọng. Với forward proxy kiểu Envoy, chính Envoy phân giải, nên DNS của máy client không còn liên quan.

Điều kiện bắt đầu

  • Bản Envoy đã ghi và khớp với nhánh tài liệu.
  • Listener và admin nghe loopback.
  • Danh sách tên miền được phép đã chốt.
  • Danh sách dải địa chỉ phải chặn đã chốt.
  • Nơi ghi log và thống kê đã quyết định.

Ghi lại điều kiện thử

Mỗi lần thử, anh em ghi bốn dòng: số phiên bản Envoy, tên tệp cấu hình, ngày giờ và kết quả script soát. Khi một tuyến bất ngờ hỏng sau một lần nâng cấp, bản ghi này cho biết cấu hình nào từng chạy. Với Envoy, nơi một trường đổi tên giữa các bản là chuyện thường, thói quen này tiết kiệm nhiều giờ.

Tên cache và tên chính sách có nghĩa

Đặt tên cache như dfp_cache_lab và tên chính sách RBAC như dich-duoc-phep. Khi đọc thống kê và log, tên mô tả được việc giúp anh em biết ngay chính sách nào đang chặn hoặc cho qua. Tên chung chung như policy-1 khiến việc rà soát sau vài tháng rất khó.

Cấu hình Envoy dynamic forward proxy tối thiểu: filter, cluster, route

Cấu hình dài hơn các công cụ khác trong chuỗi bài, vì Envoy mô tả mọi thứ rõ ràng. Mình đi từng khối.

Cấu hình lab đầy đủ

admin:
  address:
    socket_address: {protocol: TCP, address: 127.0.0.1, port_value: 9901}
static_resources:
  listeners:
  - name: dfp_lab
    address:
      socket_address: {protocol: TCP, address: 127.0.0.1, port_value: 10000}
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: dfp_lab
          route_config:
            name: local_route
            virtual_hosts:
            - name: all
              domains: ["*"]
              routes:
              - match: {prefix: "/"}
                route: {cluster: dynamic_forward_proxy_cluster}
          http_filters:
          - name: envoy.filters.http.rbac
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC
              rules:
                action: ALLOW
                policies:
                  dich-duoc-phep:
                    permissions:
                    - header: {name: ":authority", string_match: {exact: "shop-a.test:8901"}}
                    - header: {name: ":authority", string_match: {suffix: ".noi-bo.test"}}
                    principals:
                    - any: true
          - name: envoy.filters.http.dynamic_forward_proxy
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.dynamic_forward_proxy.v3.FilterConfig
              dns_cache_config: &dns
                name: dfp_cache_lab
                dns_lookup_family: V4_ONLY
                max_hosts: 64
                host_ttl: 60s
                dns_refresh_rate: 30s
                dns_cache_circuit_breaker: {max_pending_requests: 64}
                resolved_address_filter:
                  ranges:
                  - {address_prefix: 127.0.0.0, prefix_len: 8}
                  - {address_prefix: 10.0.0.0, prefix_len: 8}
                  - {address_prefix: 172.16.0.0, prefix_len: 12}
                  - {address_prefix: 192.168.0.0, prefix_len: 16}
                  - {address_prefix: 169.254.0.0, prefix_len: 16}
                  - {address_prefix: "::1", prefix_len: 128}
                  - {address_prefix: "fc00::", prefix_len: 7}
                  - {address_prefix: "fe80::", prefix_len: 10}
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  clusters:
  - name: dynamic_forward_proxy_cluster
    lb_policy: CLUSTER_PROVIDED
    circuit_breakers:
      thresholds:
      - {priority: DEFAULT, max_connections: 64, max_pending_requests: 64, max_requests: 64, max_retries: 1}
    cluster_type:
      name: envoy.clusters.dynamic_forward_proxy
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.clusters.dynamic_forward_proxy.v3.ClusterConfig
        dns_cache_config: *dns

Dòng &dns và *dns là neo YAML: chúng bảo đảm filter và cluster dùng cùng một khối dns_cache_config, đúng yêu cầu của tài liệu. Envoy đọc YAML đã bung neo, nên cách viết này hợp lệ, nhưng mình chưa kiểm trên Envoy thật.

Khối listener và route

Listener nghe 127.0.0.1:10000 và dùng bộ quản lý kết nối HTTP. Virtual host nhận mọi tên miền bằng "*" và một route duy nhất trỏ vào cluster dynamic forward proxy. Tài liệu có ví dụ thêm route với host_rewrite_literal để ép đổi tiêu đề Host trước khi phân giải, ví dụ /force-host-rewrite đổi sang www.example.org. Lab không dùng.

Cổng này nhận yêu cầu HTTP có tiêu đề Host. Client gọi curl tới 127.0.0.1:10000 với tiêu đề Host là tên miền đích. Cấu hình CONNECT cho HTTPS qua proxy là một chủ đề khác mà tài liệu mình đọc không đi sâu, nên bài không bao gồm.

Thứ tự bộ lọc

Thứ tự trong http_filters quan trọng. RBAC đứng đầu để từ chối trước khi bộ lọc dynamic forward proxy yêu cầu DNS. Router đứng cuối. Nếu RBAC đứng sau dynamic forward proxy, DNS đã bị hỏi cho một tên miền không được phép, và kết quả có thể vào cache. Script báo lỗi khi RBAC đứng sau.

TLS tới đích

Tài liệu ghi: cấu hình transport_socket tên envoy.transport_sockets.tls trên cluster, kèm trusted_ca, khiến Envoy dùng TLS khi kết nối tới đích và kiểm chuỗi chứng chỉ. Envoy còn tự kiểm SAN theo tên máy đã phân giải và gửi tên đó qua SNI.

Cấu hình lab của mình bỏ phần này để kiểm bằng HTTP thường, nên script đưa ra cảnh báo. Khi dùng thật tới website HTTPS, thêm khối transport_socket với trusted_ca trỏ tới gói chứng chỉ của hệ thống.

Phân giải tên qua resolver riêng

Ví dụ của tài liệu dùng typed_dns_resolver_config với resolver C-ares, trỏ tới 8.8.8.8:53, bật use_tcp_for_dns_lookups và no_default_search_domain. Tài liệu liệt kê các resolver có sẵn: apple, cares, getaddrinfo và hickory. Lab của mình để mặc định, vì chỉ cần thấy cấu trúc.

Quyền truy cập và chặn upstream của Envoy dynamic forward proxy

Bốn lớp chặn đích của forward proxy

Bốn lớp chặn đích của forward proxy

Đây là phần quan trọng nhất của bài. Dynamic forward proxy không có danh sách đích. Nếu không chặn, nó nối tới mọi tên miền client yêu cầu, kể cả những nơi proxy không nên tới.

Lớp một: RBAC theo authority

Trang RBAC filter mô tả bộ lọc phân quyền cho các hành động của client. Nó hỗ trợ danh sách cho phép (ALLOW) hoặc danh sách chặn (DENY). Trong cấu hình lab, mình dùng ALLOW: chỉ yêu cầu khớp một chính sách mới đi tiếp, mọi thứ khác bị chặn mặc định.

Mỗi chính sách có permissions và principals. Permission so khớp tiêu đề :authority bằng string_match với exact hoặc suffix. Principal là any, tức mọi client. Tài liệu giao thức RBAC ghi hành động ALLOW cho phép yêu cầu khi và chỉ khi có chính sách khớp, còn DENY cho phép khi không có chính sách nào khớp.

Chọn ALLOW là chọn mặc định từ chối, đúng lời khuyên của trang dynamic forward proxy. DENY chỉ chặn những gì anh em nhớ ra để liệt kê, nên luôn thiếu.

Cạm bẫy: authority có kèm cổng

Giá trị :authority có thể gồm cổng, ví dụ shop-a.test:8901. Nếu chính sách chỉ ghi exact là shop-a.test thì yêu cầu có cổng không khớp. Mô hình của mình cho thấy đúng hiện tượng này, xem bảng kết quả bên dưới. Muốn cho cả hai dạng, ghi hai chính sách hoặc dùng cách so khớp khác như biểu thức chính quy.

Dùng suffix cho các tên miền con, như .noi-bo.test, tiện nhưng rộng. Nó cho mọi tên dưới đuôi đó, kể cả tên mà người khác đăng ký thêm sau này. Chỉ dùng cho tên miền anh em kiểm soát.

Lớp hai: lọc địa chỉ phân giải

RBAC chặn theo tên. Một tên được phép vẫn có thể phân giải ra địa chỉ nội bộ, nếu DNS bị đầu độc hoặc chủ tên miền cố tình trỏ vào đó. Đây là tấn công DNS rebinding. Trường resolved_address_filter của DNS cache trả lời đúng bài toán này.

Tài liệu ghi: trường là một bộ khớp địa chỉ tùy chọn, loại khỏi phản hồi DNS những địa chỉ khớp dải đã khai. Nếu mọi địa chỉ bị loại, phép phân giải coi như thất bại và host giữ địa chỉ đã phân giải trước đó. Tài liệu nói rõ có thể dùng làm cơ chế phòng SSRF và chống DNS rebinding về địa chỉ nội bộ hoặc riêng tư.

Cấu hình lab liệt kê tám dải: 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, ::1/128, fc00::/7 và fe80::/10. Đó là loopback, mạng riêng, link-local, kể cả dải 169.254 nơi nhiều máy chủ metadata đám mây nằm.

Lớp ba: giới hạn tài nguyên

Hai tầng circuit breaker và max_hosts giới hạn thiệt hại khi bị lạm dụng. Với max_hosts bằng 64, cache không thể phình ra vì một client sinh tên miền ngẫu nhiên. Với host_ttl bằng 60 giây, host không dùng bị xóa nhanh.

Anh em đặt thêm giới hạn ở tầng hệ điều hành và tường lửa, vì cấu hình Envoy không thay được các lớp đó. Tài liệu nhắc rõ phải kiểm toán cấu hình mạng của máy chủ proxy.

Lớp bốn: không phơi admin và listener

Admin của Envoy trả cấu hình và thống kê, và có thể chứa thông tin nhạy cảm. Nghe 127.0.0.1. Listener cũng nghe loopback trong lab. Khi cần cho máy khác dùng, nghe địa chỉ mạng riêng, đặt tường lửa theo nguồn, và thêm cách xác thực ở lớp trước Envoy.

Bài Proxy Protocol và bài HAProxy nói về cách giữ IP gốc và cân bằng tải ở lớp trước, hai việc thường đi kèm khi đặt Envoy sau một thiết bị khác.

Chạy ca đúng sai và đọc log, thống kê của Envoy dynamic forward proxy

Mình đã chạy script soát cấu hình. Các ca trên Envoy thật là kế hoạch.

Kết quả script trên cấu hình lab

Script envoy_check.py đọc YAML, soát các điều kiện trong phần trước, rồi mô hình hóa hai quy tắc chặn. Kết quả trên file lab, kèm sáu authority mẫu và hai địa chỉ DNS giả.

== envoy_tot.yaml
  [OK] admin nghe 127.0.0.1:9901
  [OK] listener 'dfp_lab' nghe 127.0.0.1:10000
  [OK] cluster 'dynamic_forward_proxy_cluster' lb_policy = CLUSTER_PROVIDED
  [OK] cluster co circuit_breakers
  [CANH BAO] cluster khong co transport_socket TLS: moi ket noi ra ngoai la plaintext
  [OK] filter va cluster dung chung dns_cache_config 'dfp_cache_lab'
  [OK] resolved_address_filter phu loopback, rieng tu, link-local
  [OK] RBAC action = ALLOW (ALLOW = chi cho khop chinh sach)
  [OK] RBAC dung truoc dynamic_forward_proxy (vi tri 0 < 1)
  KET QUA: DAT
  RBAC mo hinh | authority shop-a.test:8901           -> CHO QUA (dich-duoc-phep)
  RBAC mo hinh | authority shop-a.test                -> TU CHOI
  RBAC mo hinh | authority api.noi-bo.test            -> CHO QUA (dich-duoc-phep)
  RBAC mo hinh | authority localhost:9901             -> TU CHOI
  RBAC mo hinh | authority 169.254.169.254            -> TU CHOI
  RBAC mo hinh | authority evil.test:80               -> TU CHOI
  loc dia chi | DNS tra ['10.0.0.5', '93.184.216.34'] -> con lai ['93.184.216.34']

Dòng thứ hai từ cuối của khối RBAC cho thấy bẫy cổng: authority shop-a.test không kèm cổng bị từ chối vì chính sách chỉ ghi dạng có cổng. Dòng cuối cho thấy bộ lọc địa chỉ loại 10.0.0.5 và giữ địa chỉ công khai.

Một ca khác: tên evil.rebind.test cho DNS trả 127.0.0.1 và 10.1.2.3. Mô hình trả kết quả rỗng, nghĩa là mọi địa chỉ bị loại, phép phân giải thất bại, đúng như tài liệu mô tả.

Cấu hình xấu và lỗi bắt được

Mình cũng soạn file envoy_xau.yaml mô phỏng cấu hình vội. Kết quả.

== envoy_xau.yaml
  [LOI] admin nghe 0.0.0.0:9901
  [CANH BAO] listener 'mo' nghe 0.0.0.0:10000
  [LOI] cluster 'dfp' lb_policy = ROUND_ROBIN
  [LOI] dns_cache_config cua filter va cluster khac nhau o: ['name'] (tai lieu: hai noi phai tro cung tham so)
  [LOI] khong co resolved_address_filter: ten mien tro ve dia chi noi bo van duoc noi toi
  [LOI] RBAC action = DENY (ALLOW = chi cho khop chinh sach)
  [LOI] RBAC dung SAU dynamic_forward_proxy
  KET QUA: KHONG DAT

Kết quả rút gọn, mình bỏ các cảnh báo thiếu max_hosts, host_ttl và circuit breaker. Cấu hình xấu có sáu lỗi chặn, từ admin mở ra mạng tới RBAC đứng sai chỗ.

Dòng DENY đánh dấu LOI là chính sách của script, không phải lỗi cú pháp Envoy. DENY hợp lệ về cú pháp, nhưng chỉ chặn đúng thứ đã liệt kê, nên mình coi là yếu.

Mô hình này đáng tin tới đâu

Phải nói rõ: các dòng "RBAC mo hinh" và "loc dia chi" là mô hình do mình viết theo cách đọc tài liệu. Chúng thể hiện ý đồ cấu hình, không chứng minh Envoy xử lý đúng như vậy. Ví dụ mình mô phỏng exact và suffix, còn Envoy có nhiều kiểu string_match khác.

Giá trị của script là bắt lỗi cấu trúc trước khi chạy, và buộc anh em nghĩ về các ca chặn. Việc kiểm thật phải làm bằng curl trên Envoy.

Kế hoạch tám ca trên Envoy thật

Tám ca đúng sai trên Envoy lab

Tám ca đúng sai trên Envoy lab

Bảng: Kế hoạch tám ca trên Envoy thật

Ca

Việc làm

Kết quả cần thấy

1

curl tới 127.0.0.1:10000 với Host shop-a.test:8901

Trang đích trả về

2

Cùng ca 1 lần thứ hai

Phân giải từ cache, không hỏi DNS lại

3

Host là shop-a.test không cổng

Bị từ chối bởi RBAC

4

Host là localhost:9901

Bị từ chối, admin không bị chạm tới

5

Host là 169.254.169.254

Bị từ chối

6

Host được phép nhưng DNS trả 127.0.0.1

Phân giải thất bại do resolved_address_filter

7

200 tên miền khác nhau liên tiếp

Số host cache không vượt max_hosts

8

Vượt ngưỡng circuit breaker của cluster

Một phần yêu cầu bị từ chối

Mình chưa chạy tám ca này. Mã phản hồi cụ thể khi RBAC từ chối, tài liệu mình đọc không ghi, chỉ ghi chi tiết rbac_access_denied_matched_policy trong RESPONSE_CODE_DETAILS. Anh em ghi mã thật khi chạy.

Đọc log và thống kê

Tài liệu RBAC nói khi yêu cầu bị từ chối, RESPONSE_CODE_DETAILS có tên chính sách bị khớp theo dạng rbac_access_denied_matched_policy[tên], và là none nếu không chính sách nào khớp. Nhờ đó phân biệt được Envoy từ chối với backend từ chối.

Bộ lọc RBAC cũng xuất thống kê dưới không gian http.<stat_prefix>.rbac, gồm bộ đếm allowed và denied. Bật track_per_rule_stats nếu muốn đếm theo từng chính sách. Theo dõi hai bộ đếm này trên cổng admin để thấy tỉ lệ từ chối, ví dụ một client dò nhiều đích lạ.

Trang admin còn cho xem cấu hình và thống kê của DNS cache. Mình không đọc chi tiết các điểm cuối đó, nên không liệt kê.

Khi ca thất bại

Kiểm theo thứ tự cố định. Đầu tiên là cú pháp: Envoy báo lỗi khi tải cấu hình. Sau đó là khớp tên cache giữa filter và cluster. Tiếp theo là thứ tự bộ lọc. Cuối cùng là phân giải tên, vì thất bại DNS cho triệu chứng giống thất bại kết nối.

Hoàn nguyên, giới hạn tài nguyên và dùng Envoy dynamic forward proxy thật

Sau lab, dọn dẹp trước, rồi mới nói chuyện triển khai.

Hoàn nguyên lab

Dừng tiến trình Envoy, xóa tệp cấu hình lab và tệp log. Xóa tệp thực thi đã tải nếu không dùng lại. Gỡ DNS giả hoặc dòng trong tệp hosts đã thêm cho các tên .test. Kiểm danh sách cổng nghe, xác nhận 9901 và 10000 đã đóng.

Giới hạn tài nguyên khi chạy lâu

Các tham số mình đặt cho lab, như 64 kết nối, nhỏ hơn nhiều so với ví dụ 1024 của tài liệu. Khi chạy thật, chọn số theo tải đo được, không đoán. Đặt thêm giới hạn mô tả tệp mở của tiến trình và giới hạn bộ nhớ của container.

Cache DNS giữ tên miền trong host_ttl. Với max_hosts lớn, bộ nhớ tăng theo. Với TTL ngắn, tần suất truy vấn DNS tăng. Hai tham số này đánh đổi nhau, và dns_cache_circuit_breaker giới hạn thiệt hại ở phía DNS.

Tài liệu còn có trường key_value_config để xả cache DNS ra kho lưu dài hạn. Mình không dùng vì lab không cần.

Điều kiện áp dụng vào hệ thống thật

  • Bản Envoy khớp với nhánh tài liệu dùng.
  • Danh sách đích được phép là danh sách trắng tường minh, rà định kỳ.
  • resolved_address_filter phủ mọi dải nội bộ của môi trường, kể cả dải riêng của nhà cung cấp đám mây.
  • RBAC đứng trước dynamic forward proxy, hành động ALLOW.
  • Cổng admin chỉ nghe loopback hoặc có lớp bảo vệ riêng.
  • TLS tới đích đã cấu hình với trusted_ca khi đích là HTTPS.
  • Tường lửa mạng ngăn proxy tới các dải không cần thiết, như lời khuyên của tài liệu.
  • Có log và cảnh báo cho số yêu cầu bị từ chối tăng đột biến.

Rà soát định kỳ danh sách đích

Danh sách đích được phép không đứng yên. Dịch vụ mới cần gọi ra ngoài, tên miền cũ bị bỏ. Mỗi tháng anh em xem lại các chính sách RBAC, xóa tên không còn dùng và đối chiếu với số liệu từ chối trên cổng admin. Một tên miền cũ vẫn nằm trong danh sách trắng sau khi hết người dùng là một lối đi mở không cần thiết.

Khi nào không nên dùng Envoy làm forward proxy

Nếu chỉ cần một cổng HTTP đơn giản cho vài người, Envoy quá nặng. Cấu hình dài, nhiều lớp, và lỗi bảo mật dễ nảy sinh khi thiếu một khối. Các proxy nhỏ hơn dễ vận hành hơn. Envoy đáng cân nhắc khi hệ thống đã có Envoy, cần số liệu thống kê tốt, hoặc cần kiểm soát đích chi tiết.

Envoy dynamic forward proxy: checklist và câu hỏi thường gặp

Phần cuối gom checklist và các câu hỏi mà người mới hay hỏi.

Checklist nhanh

Checklist trước khi dùng Envoy forward proxy thật

Checklist trước khi dùng Envoy forward proxy thật

  • Chạy envoy --version, ghi số phiên bản.
  • Chạy envoy_check.py hoặc cách soát tương đương.
  • Filter và cluster dùng cùng một dns_cache_config.
  • RBAC ALLOW đứng trước dynamic forward proxy.
  • Có resolved_address_filter phủ dải nội bộ.
  • Đặt max_hosts, host_ttl và circuit breaker.
  • Listener và admin nghe loopback.
  • Chạy đủ ca đúng và ca bị chặn, ghi mã phản hồi thật.

Nếu cần IP thoát đúng vùng cho các dịch vụ gọi ra ngoài, anh em có thể mua proxy giá rẻ tại ProxyVN, gồm proxy dân cư tĩnh Viettel, VNPT, FPT, datacenter Việt Nam và proxy xoay. Các gói hỗ trợ HTTP và SOCKS5 với tài khoản user và mật khẩu.

Dynamic forward proxy cho phép đi tới mọi tên miền. Vì vậy phần giới hạn đích mới là phần phải làm trước.

Câu hỏi thường gặp

Envoy dynamic forward proxy có thay proxy dân cư mua ngoài không. Không. IP thoát là IP của máy chạy Envoy. Nó giúp kiểm soát và ghi log lưu lượng đi ra, không cho anh em IP ở nhà mạng hay vùng khác.

Có nối Envoy với proxy cấp trên mua ngoài được không. Tài liệu dynamic forward proxy mình đọc không có ví dụ chuỗi sang proxy khác. Mình không khẳng định cách làm. Nếu cần, đọc tài liệu về upstream proxy của Envoy ở đúng phiên bản, và bài định dạng proxy giúp tách chuỗi tài khoản.

Có cần đặt no_proxy không. Biến no_proxy do ứng dụng client đọc, quyết định tên nào không đi qua proxy. Nó bổ sung cho giới hạn ở Envoy, không thay thế. Xem bài no_proxy là gì.

Có dùng được cho HTTPS không. Cấu hình ví dụ nhận yêu cầu HTTP có tiêu đề Host rồi dùng TLS ở cluster tới đích. Việc nhận CONNECT từ client để đi qua HTTPS là cấu hình khác, và mình không đọc đủ nên không hướng dẫn.

Tên miền con tạo động có bị lọt không. Nếu chính sách dùng suffix, mọi tên con đều lọt. Dùng exact cho tên cần thiết nếu muốn chặt hơn, và lọc địa chỉ phân giải để chặn trường hợp tên con trỏ vào nơi nội bộ.

Envoy dynamic forward proxy và những điều cần nhớ

Envoy dynamic forward proxy phải có cùng DNS cache ở filter và cluster, RBAC ALLOW chặn theo authority và resolved_address_filter loại địa chỉ nội bộ. Hãy giữ admin ở loopback và kiểm từng ca chặn. Cần proxy ổn định cho IP thoát, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam cho Envoy dynamic forward proxy.

Quảng cáo
Xem ngay
TIN TỨC LIÊN QUAN
Kinh Nghiệm Mua Proxy: 12 Điều Cần Hỏi Trước Khi Trả Tiền
Kinh Nghiệm Mua Proxy: 12 Điều Cần Hỏi Trước Khi Trả Tiền
Chuyên viên Kỹ thuật ProxyVN 03-11-2026
Nên Mua Proxy Loại Nào? Bảng Chọn Theo Từng Việc
Nên Mua Proxy Loại Nào? Bảng Chọn Theo Từng Việc
Chuyên viên Kỹ thuật ProxyVN 02-11-2026
Proxy Tĩnh Là Gì? Khi Nào Nên Giữ Một IP Cố Định
Proxy Tĩnh Là Gì? Khi Nào Nên Giữ Một IP Cố Định
Chuyên viên Kỹ thuật ProxyVN 01-11-2026