T3、Http协议格式、认证、Nginx代理uri改写、证书单双向认证

作者: Brinnatt 分类: 小工具 发布时间: 2025-02-16 00:03

1、nginx 反向代理 uri 传递和改写

环境：

我有两个 nginx 反向代理服务器，第一个反向代理服务器匹配 location /web 然后 proxy_pass http://nx.brinnatt.com，然后第二个 nginx 接收，第二个 nginx 有 location /web 和 location /tic。

问题：

1、第一个 nginx 代理匹配的 /web 反向代理的 url 会完全传到第二个吗，毕竟第一个 nginx proxy_pass 没有指定 /web，只是给了 http://nx.brinnatt.com？2、如果我想把第一个 nginx 反向代理的 /web 匹配到第二个 nginx 的 /tic 应该怎么做。

第一个问题的解答：

当第一个 Nginx 的 proxy_pass 仅指定了目标域名而未添加路径时（如http://nx.brinnatt.com），客户端原始请求的 URI 会完整传递到第二个 Nginx 服务器。具体规则如下：

  • 客户端请求示例：http://第一个Nginx的IP/web/api
  • 第一个 Nginx 处理：location /web 匹配后，将请求代理到 http://nx.brinnatt.com/web/api
  • 第二个 Nginx 接收到的 URI：/web/api，因此会尝试匹配自己的 location /web 或 location /tic

第二个问题的解决方案：

若要将第一个 Nginx 的 /web 路径代理到第二个 Nginx 的 /tic 路径，需在第一个 Nginx 的配置中修改 URI 路径。有以下两种方法：

方法1：在 proxy_pass 中直接追加目标路径

location /web {
    proxy_pass http://nx.brinnatt.com/tic;  # 注意末尾的/tic
    # 其他代理参数（如设置Host头）
    proxy_set_header Host $host;
}
  • 效果：客户端请求 /web/test 将被转换为 http://nx.brinnatt.com/tic/test
  • 关键点：proxy_pass 末尾的 /tic 会替换原始 location /web 匹配的部分

方法2：使用 rewrite 指令重写路径

location /web {
    rewrite ^/web/(.*) /tic/$1 break;  # 将/web/xxx重写为/tic/xxx
    proxy_pass http://nx.brinnatt.com;
    # 其他代理参数
    proxy_set_header Host $host;
}
  • 效果：客户端请求 /web/data 将被转换为 http://nx.brinnatt.com/tic/data
  • 优势：更灵活，适合复杂重写逻辑（如正则匹配）

验证配置的正确性：

  1. 执行 nginx -t 检查配置语法
  2. 通过浏览器或 curl 测试请求路径，例如： 
    curl http://第一个Nginx的IP/web/hello

    预期第二个 Nginx 应收到 /tic/hello 的请求，并匹配到 location /tic。

注意事项：

  • 确保第二个 Nginx 已正确定义了 location /tic 来处理转换后的路径
  • 若出现 404 错误，检查第二个 Nginx 的访问日志（access.log）确认实际收到的 URI
  • 若需要保留原始 Host 信息（如域名），需配置 proxy_set_header Host $host;

2、nginx 反向代理接收的 uri 在 http 协议哪个位置，$HOST 和 $HTTP_HOST 区别

问题一：URI 的传递位置（请求头还是请求行）

  1. URI 的位置
    URI（如 /web/api）不在请求头（Header）中，而是位于 HTTP 请求行（Request Line） 中。例如：

    GET /web/api HTTP/1.1
Host: example.com
    • 请求行：定义了请求方法（GET）、URI（/web/api）和协议版（HTTP/1.1）。
    • 请求头：包含 Host、User-Agent 等元信息。
  2. 反向代理中的 URI 传递
    • 第一个 Nginx 收到客户端的请求后，会将 原始 URI（如 /web/api） 连同请求头和请求体一起转发给第二个 Nginx。
    • 第二个 Nginx 收到的请求行中会包含 URI（如 /web/api），与第一个 Nginx 是否修改 URI 有关（见之前的路径重写规则）。

问题二：proxy_set_header 的作用与常用参数

  1. proxy_set_header 的作用
    用于 修改转发到上游服务器（第二个 Nginx）的请求头。默认情况下，Nginx 会直接传递客户端的原始请求头，但通过此指令可以覆盖或新增头信息。

  2. 常用参数示例 

    location /web {
   proxy_pass http://nx.brinnatt.com;

   # 常用配置示例：
   proxy_set_header Host $host;                  # 修改 Host 头
   proxy_set_header X-Real-IP $remote_addr;      # 传递客户端真实 IP
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  # 记录请求链路
   proxy_set_header X-Forwarded-Proto $scheme;    # 传递协议（http/https）
}
    • X-Real-IP：将客户端真实 IP 传递给上游服务器（常用于日志记录）。
    • X-Forwarded-For：记录请求经过的代理链（多个代理 IP 会以逗号分隔）。
    • X-Forwarded-Proto：告诉上游服务器客户端使用的协议（如 http 或 https）。

问题三：$host 与 $http_host 的区别与影响

  1. $host vs $http_host

    • $host：

      • 按以下优先级获取值（不含端口）：
        1. 请求行中的 Host 头（如 Host: example.com）
        2. Nginx 配置中 server_name 匹配的域名（若 Host 头缺失或无效）
      • 示例：客户端请求 Host: example.com:8080 → $host = example.com。

    • $http_host：

      • 直接读取客户端请求头中的 Host 值（包含端口）。
      • 示例：客户端请求 Host: example.com:8080 → $http_host = example.com:8080。

    区别总结：

    • $host 不包含端口，$http_host 包含端口。
    • 如果客户端请求头中没有 Host，则 $http_host 为空，而 $host 会使用 server_name 的值。

  2. 能否修改 Host 头？

    • 可以。通过 proxy_set_header Host xxx 可以强制修改上游服务器收到的 Host 头。
    • 典型场景：
      上游服务器通过 Host 头区分不同网站（虚拟主机），若反向代理不传递正确的 Host，可能导致上游服务器返回错误内容。

  3. 修改 Host 对响应头的影响

    • 响应头中的 Host：
      上游服务器返回的响应头中通常不会包含 Host 头，因为 Host 是请求头而非响应头。
    • 响应头中的其他相关字段：
      上游服务器可能返回 Server（标识自身软件）或 Location（重定向地址，需注意是否受代理影响）。

总结与注意事项

  1. 常见配置： 

    proxy_set_header Host $host;      # 推荐：传递域名（不含端口）
proxy_set_header Host $http_host; # 可选：传递域名+端口（需明确需求）

  2. 调试技巧：

    • 通过第二个 Nginx 的 access.log 检查实际收到的 Host 和 URI： 
      log_format main '$host $http_host $request_uri';
access_log /var/log/nginx/access.log main;

  3. 典型问题：

    • 若上游服务器返回 404，可能是 Host 头未正确传递（如上游服务器依赖 Host 匹配虚拟主机）。
    • 使用 curl -v 或浏览器开发者工具检查请求头和响应头。

3、HTTP 协议完整格式，uri 和 url 区别

HTTP 请求的完整格式

HTTP 请求由 请求行（Request Line）、请求头（Headers）、空行 和 请求体（Body） 四部分组成。以下是一个示例请求及其各部分详解：

POST /api/v1/login?user=test HTTP/1.1      ← 请求行
Host: example.com                          ← 请求头开始
User-Agent: Mozilla/5.0
Content-Type: application/json
Content-Length: 52

{                                         ← 空行后是请求体
  "username": "admin",
  "password": "123456"
}                                         ← 请求体结束

1. 请求行（Request Line）

  • 位置：HTTP 请求的第一行。
  • 内容：<请求方法> <URI> <协议版本>。
  • 示例： 
    GET /search?q=nginx HTTP/1.1
  • 组成部分：
    • 请求方法：如 GET、POST、PUT、DELETE。
    • URI（Uniform Resource Identifier）：标识资源的路径和参数（例如 /search?q=nginx）。
    • 协议版本：如 HTTP/1.1 或 HTTP/2。

关键点：
URI 是请求行的核心部分，明确告诉服务器“客户端请求的是哪个资源”。

2. 请求头（Headers）

  • 位置：请求行之后，空行之前。
  • 作用：传递请求的元信息（如客户端类型、内容格式、认证信息等）。
  • 常见头字段：
    • Host: example.com：目标服务器的域名（HTTP/1.1 中必须包含）。
    • User-Agent: Mozilla/5.0：客户端标识（如浏览器类型）。
    • Content-Type: application/json：请求体的数据格式。
    • Authorization: Bearer xxxxx：认证信息。

关键点：
请求头不包含 URI 路径，URI 路径仅在请求行中定义。

3. 请求体（Body）

  • 位置：空行之后。
  • 作用：携带客户端提交的数据（如表单内容、JSON 数据等）。
  • 示例： 
    {
"username": "admin",
"password": "123456"
}
  • 适用场景：POST、PUT 等方法通常需要请求体。

URI 与 URL 的区别

  • URI（Uniform Resource Identifier）：
    统一资源标识符，广义概念，标识一个资源（不一定是网络资源）。
    示例：/api/v1/login?user=test

  • URL（Uniform Resource Locator）：
    统一资源定位符，URI 的子集，明确提供资源的访问路径和协议。
    示例：https://example.com/api/v1/login?user=test

关系总结：

  • 所有 URL 都是 URI，但 URI 不一定是 URL。
  • URL = 协议（http/https） + 域名（example.com） + URI（/api/v1/login?user=test）。

Nginx 代理中的 URI 传递

  • 默认行为：
    如果第一个 Nginx 的 proxy_pass 未指定路径（如 http://nx.brinnatt.com），则客户端请求的 完整 URI（包括路径和参数） 会原样传递给第二个 Nginx。
    示例：

    • 客户端请求：http://proxy1.com/web/data?id=1

    • 第二个 Nginx 收到的请求行：GET /web/data?id=1 HTTP/1.1

    • 修改 URI 路径：
      若需要将 /web 代理到 /tic，需在第一个 Nginx 中重写路径（通 proxy_pass 或 rewrite）。
      示例配置： 

    location /web {
  proxy_pass http://nx.brinnatt.com/tic;  # 路径替换
  proxy_set_header Host $host;
}
    • 客户端请求：http://proxy1.com/web/hello
    • 第二个 Nginx 收到的请求行：GET /tic/hello HTTP/1.1

关键调试技巧

  1. 查看实际请求的 URI：
    在第二个 Nginx 的 access.log 中记录 $request_uri： 

    log_format main '$remote_addr - $request_uri';
access_log /var/log/nginx/access.log main;

  2. 使用 curl 验证请求路径： 

    curl -v http://proxy1.com/web/hello
    • -v 参数会输出完整的请求行和响应头。

总结

  • URI 是请求行的核心，URL 是包含协议和域名的完整路径。
  • 请求头仅传递元信息（如 Host），路径和参数在请求行中。
  • 反向代理中修改 URI 需显式配置（proxy_pass 或 rewrite）。

4、HTTP 协议中携带认证信息 Authorization 在什么位置，比如 postman 请求 http？

HTTP 认证信息的位置与格式

当你在 Postman 中添加认证信息（如 Authorization: Basic 或 Bearer Token）时，这些信息会被放置在 HTTP 请求头（Headers） 中。以下是详细说明和示例：

1. HTTP 认证信息的分类与位置

(1) 基本认证（Basic Authentication）

  • 格式： 
    Authorization: Basic

  • 示例：
    用户名 admin，密码 123456 → 编码后为 YWRtaW46MTIzNDU2。
    HTTP 请求头中显示： 

    Authorization: Basic YWRtaW46MTIzNDU2

(2) Bearer Token 认证（如 JWT）

  • 格式： 
    Authorization: Bearer
  • 示例： 
    Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

(3) 其他认证方式

  • API Key： 
    X-API-Key: your_api_key
  • Digest 认证： 
    Authorization: Digest username="admin", realm="protected", ...
  • AWS 签名认证： 
    Authorization: AWS4-HMAC-SHA256 Credential=...

2. 完整 HTTP 请求示例（Postman 发送）

假设在 Postman 中配置了 Authorization: Bearer Token 和 Content-Type，请求体为 JSON 数据： 

POST /api/data HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Type: application/json
User-Agent: PostmanRuntime/7.29.0
Content-Length: 27

{
  "key": "value"
}
  • 关键位置：
    • 请求行：POST /api/data HTTP/1.1
    • 请求头：包含 Authorization、Content-Type 等字段。
    • 请求体：JSON 数据。

3. Postman 中的操作对应到 HTTP 请求

在 Postman 中配置认证的两种常见方式：

(1) 直接通过 "Authorization" 标签页配置

  • 选择认证类型（如 Basic Auth、Bearer Token），输入用户名/密码或 Token。
  • Postman 会自动生成 Authorization 头并添加到请求头中。

(2) 手动在 "Headers" 标签页添加

  • 直接输入 Authorization 头字段和值（如 Bearer your_token）。

4. 认证信息是否可能放在请求体（Body）中？

  • 通常不建议：
    标准做法是将认证信息放在请求头中（尤其是令牌或密钥），因为：

    • 安全性更高（避免被日志记录或缓存）。
  • 符合 HTTP 协议规范（认证信息属于元数据，而非业务数据）。
  • 例外情况：
    某些场景可能要求将认证参数放在请求体中，例如：

    • OAuth 2.0 的 client_credentials 模式： 
      POST /oauth/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
client_id=your_client_id&client_secret=your_client_secret
    • 简单 API Key 传递（非标准做法）： 
      {
"api_key": "your_key",
"data": { ... }
}

总结

  • 认证信息的位置：

    • 标准认证（如 Basic、Bearer、Digest）→ 请求头的 Authorization 字段。
    • 非标准认证（如自定义 API Key）→ 可能放在请求头或请求体，具体取决于服务端要求。

  • 在 Postman 中的操作：
    通过 "Authorization" 或 "Headers" 标签页配置，最终生成的 Authorization 头会位于 HTTP 请求头 中。

  • 调试建议：
    使用 Postman 的 "Code" 功能（右上角）生成代码片段，查看完整的 HTTP 请求格式。

5、什么是单向双向证书认证，如何配置证书，如何传递证书，比如 google 访问 nginx，kubectl 访问 apiserver

问题一：Nginx 的 HTTPS 访问与证书认证类型

1. 为什么未配置客户端证书仍能访问？

当你的浏览器通过 HTTPS 访问 Nginx 时，如果未提示客户端证书错误且能正常访问，说明你配置的是 单向 TLS 认证（即标准 HTTPS），而非双向认证。

  • 单向认证流程：

    1. 浏览器（客户端）发起 HTTPS 请求。
    2. Nginx（服务端）返回自己的 SSL 证书（由 CA 签发或自签名）。
    3. 浏览器验证服务端证书的合法性（如是否过期、是否被信任）。
    4. 验证通过后建立加密连接，后续 HTTP 数据在加密通道中传输。

  • 关键点：
    单向认证中，只有服务端需要提供证书，客户端无需证书。这是最常见的 HTTPS 配置。

2. 单向认证的证书配置（Nginx 示例）

假设你的 Nginx 配置如下（单向认证）： 

server {
    listen 443 ssl;
    server_name example.com;

    # 服务端证书配置（单向认证）
    ssl_certificate /path/to/server.crt;    # 服务端证书
    ssl_certificate_key /path/to/server.key;  # 服务端私钥

    # 其他配置...
}

  • 证书类型：

    • server.crt：服务端证书（通常包含公钥和 CA 签名）。
    • server.key：服务端私钥，必须严格保密。

  • 浏览器行为：
    浏览器内置了信任的根 CA 列表，若服务端证书由这些 CA 签发（如 Let's Encrypt），浏览器会自动信任；若使用自签名证书，浏览器会提示“不安全”，但用户可手动跳过警告。

3. 双向认证（mTLS）的配置

若需强制客户端提供证书（双向认证），需在 Nginx 中添加以下配置： 

server {
    listen 443 ssl;
    server_name example.com;

    # 服务端证书配置
    ssl_certificate /path/to/server.crt;
    ssl_certificate_key /path/to/server.key;

    # 启用客户端证书验证（双向认证）
    ssl_client_certificate /path/to/ca.crt;  # 信任的 CA 证书（用于验证客户端证书）
    ssl_verify_client on;  # 强制要求客户端证书

    # 其他配置...
}

  • 证书要求：

    • 服务端：需配置自己的证书和私钥。
    • 客户端：必须提供由 ca.crt 对应的 CA 签发的客户端证书（如 client.crt 和 client.key）。

  • 浏览器访问：
    双向认证时，浏览器会弹出对话框要求选择客户端证书，若未安装有效证书，连接将被拒绝。

问题二：Kubernetes 的双向认证机制

Kubernetes 集群中，kubectl 与 apiserver 的通信基于双向 TLS 认证（mTLS）。以下是关键配置细节：

1. 证书的配置位置

  • kubectl（客户端）证书配置：

    • 证书信息存储在 kubeconfig 文件中（默认位于 ~/.kube/config）。
    • 关键字段：
    users:
- name: my-user
  user:
    client-certificate: /path/to/client.crt  # 客户端证书
    client-key: /path/to/client.key          # 客户端私钥
    certificate-authority: /path/to/ca.crt   # 信任的 CA 证书

  • apiserver（服务端）证书配置：

    • apiserver 启动时需指定服务端证书和私钥：
    kube-apiserver \
  --tls-cert-file=/path/to/apiserver.crt \
  --tls-private-key-file=/path/to/apiserver.key \
  --client-ca-file=/path/to/ca.crt  # 用于验证客户端证书的 CA

2. 双向认证流程

  1. 客户端（kubectl）发起请求：

    • 使用 client.crt 和 client.key 对请求签名，并在 TLS 握手阶段发送客户端证书。

  2. 服务端（apiserver）验证客户端证书：

    • 用 --client-ca-file 指定的 CA 证书验证 client.crt 的合法性。

  3. 服务端返回自己的证书：

    • apiserver 发送 apiserver.crt 给客户端。

  4. 客户端验证服务端证书：

    • kubectl 用 certificate-authority（即 ca.crt）验证 apiserver.crt。

  5. 建立加密通道：
    双向验证通过后，后续通信在加密通道中进行。

3. 证书不在 HTTP 协议中

  • 证书传递位置：
    客户端和服务端证书的交换发生在 TLS 握手阶段，属于传输层（TLS/SSL）协议，而非 HTTP 协议层。

    • 客户端证书：通过 TLS 的 Certificate 消息发送。
    • 服务端证书：通过 TLS 的 ServerCertificate 消息发送。

  • HTTP 协议无关性：
    HTTP 请求头和请求体中不会包含证书内容，所有证书验证在 TLS 层完成。

总结

  1. Nginx 的单向 vs 双向认证：

    • 单向认证：仅服务端提供证书，适用于普通 HTTPS 网站。
    • 双向认证：客户端和服务端均提供证书，适用于高安全场景（如内部 API）。

  2. Kubernetes 的双向认证：

    • kubectl 的证书配置在 kubeconfig 中，apiserver 的证书通过命令行参数指定。
    • 证书验证通过 TLS 握手完成，与 HTTP 协议无关。

  3. 调试建议：

    • Nginx：检查 ssl_verify_client 配置和错误日志（error.log）。
    • Kubernetes：使用 openssl s_client 或 kubectl --v=9 查看详细握手过程。

通过理解 TLS 分层机制和证书配置位置，可以更好地管理 HTTPS 和双向认证场景。

6、k8s 客户端和服务器端验证对方证书时使用的CA是一样的吗？必须一样吗？

在 Kubernetes 中，客户端（如 kubectl）和服务端（如 apiserver）验证对方证书时，使用的 CA 不一定需要相同，但必须满足以下条件：

1. 双向认证的证书信任关系

  • 客户端验证服务端证书：
    kubectl 需要信任服务端证书的签发 CA（即 apiserver 证书的 CA）。
  • 服务端验证客户端证书：
    apiserver 需要信任客户端证书的签发 CA（即 kubectl 证书的 CA）。

这两个 CA 可以不同，但双方必须配置为信任对方的 CA。

2. 默认场景（使用相同 CA）

在大多数 Kubernetes 集群（如通过 kubeadm 安装的集群）中，默认使用 同一个根 CA 签发所有证书，包括：

  • Apiserver 的服务端证书（由 CA 签发）。
  • kubectl 的客户端证书（由同一 CA 签发）。

此时：

  • Apiserver 的 --client-ca-file 参数指向该 CA（用于验证客户端证书）。
  • kubectl 的 certificate-authority 字段也指向该 CA（用于验证 apiserver 的服务端证书）。

优点：配置简单，统一管理。

3. 使用不同 CA 的场景

如果希望客户端和服务端使用不同的 CA，需满足以下条件：

(1) Apiserver 的配置

  • 服务端证书：由 CA1 签发。
  • 客户端证书的信任 CA：通过 --client-ca-file 指定 CA2（用于验证 kubectl 的客户端证书）。

(2) Kubectl 的配置

  • 客户端证书：由 CA2 签发。
  • 服务端证书的信任 CA：通过 certificate-authority 字段指定 CA1（用于验证 apiserver 的服务端证书）。

(3) 证书信任链示例

#Apiserver 的证书配置：
apiserver.crt（由 CA1 签发）
apiserver.key  
--client-ca-file=CA2.crt（信任 CA2 签发的客户端证书）

#Kubectl 的证书配置：
client.crt（由 CA2 签发）  
client.key  
certificate-authority=CA1.crt（信任 CA1 签发的 apiserver 证书）

4. 关键验证流程

  1. 客户端验证服务端：

    • kubectl 使用 CA1.crt 验证 apiserver 的证书（确保是 CA1 签发的合法证书）。

  2. 服务端验证客户端：

    • Apiserver 使用 CA2.crt 验证 kubectl 的证书（确保是 CA2 签发的合法证书）。

5. 是否必须使用相同的 CA？

  • 否。只要双方的信任链正确，即使使用不同的 CA，双向认证仍可正常工作。
  • 典型用例：
    • 企业内部系统使用不同的 CA 管理客户端和服务端证书（例如客户端证书由企业 CA 签发，服务端证书由云服务商 CA 签发）。
    • 跨团队协作时，团队 A 管理服务端 CA，团队 B 管理客户端 CA。

6. 验证失败的常见原因

  1. CA 信任链未正确配置：

    • Apiserver 的 --client-ca-file 未包含 kubectl 客户端证书的签发 CA。
    • kubectl 的 certificate-authority 未包含 apiserver 服务端证书的签发 CA。

  2. 证书过期或格式错误：

    • 证书文件必须是 PEM 格式，且包含完整的证书链（如中间 CA）。

7. 调试命令

  • 检查服务端证书信任链： 

    openssl s_client -connect apiserver-ip:6443 -showcerts
  • 检查客户端证书是否被信任： 
    kubectl get pods --v=9  # 查看详细 TLS 握手日志

总结

  • Kubernetes 的双向认证不要求客户端和服务端使用相同的 CA，但必须满足 双方信任对方的 CA。
  • 默认情况下，Kubernetes 使用同一 CA 简化管理，但在复杂场景中可灵活使用不同 CA。
  • 重点在于正确配置 --client-ca-file（服务端）和 certificate-authority（客户端）。
更多阅读
标签云