Istio使用公司代理后面的TLS起源访问外部站点

时间：2020-01-31 12:39:52

标签： istio

在进行tls发起时，我难以配置istio以通过我们的公司代理，我创建了一个demo项目，该项目可重现此用例并显示：

  • [NO-PROXY] https请求www.wikipedia.org 工作
  • [PROXY] https对www.wikipedia.org的请求工作
  • [NO-PROXY] http请求www.wikipedia.org 使用tls来源的工作
  • [PROXY]对www.wikipedia.org的http请求不起作用

要设置演示项目，请启动istio / start.sh

I followed this guide for proxy

and this guide for tls origination

但是我无法使这两个功能一起工作。

关于我做错了什么的任何线索，或者在istio中无法做到这一点？

我目前的猜测是，使用tcp协议配置代理会禁用执行tls生成所需的istios功能

我也开始使用出口网关，如果可以的话会进行更新。

与此同时，您将在演示项目中看到以下内容：

https没有代理-有效

microk8s.kubectl exec -it $(microk8s.kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- sh -c "curl -I https://www.wikipedia.org 2>/dev/null | head -n 1"

log istio-proxy 

[2020-01-31T12:00:39.247Z] "- - -" 0 - "-" "-" 850 4413 576 - "-" "-" "-" "-" "91.198.174.192:443" outbound|443||www.wikipedia.org 10.1.21.153:33064 91.198.174.192:443 10.1.21.153:33062 www.wikipedia.org -

http没有代理-有效

microk8s.kubectl exec -it $(microk8s.kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- sh -c "curl -I http://www.wikipedia.org 2>/dev/null | head -n 1"

log istio-proxy 

[2020-01-31T12:02:17.012Z] "HEAD / HTTP/1.1" 200 - "-" "-" 0 0 181 180 "-" "curl/7.64.0" "09dddb0e-94b2-9f52-8505-e2a790f2d0c6" "www.wikipedia.org" "91.198.174.192:443" outbound|443|tls-origination|www.wikipedia.org - 91.198.174.192:80 10.1.21.153:45598 - -

https代理-有效

microk8s.kubectl exec -it $(microk8s.kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- sh -c "https_proxy=$PROXY curl -I https://www.wikipedia.org 2>/dev/null | head -n 1"

istio日志

[2020-01-31T12:04:38.819Z] "- - -" 0 - "-" "-" 976 4429 253 - "-" "-" "-" "-" "10.1.21.154:3128" outbound|3128||proxy 10.1.21.153:41184 10.1.21.154:3128 10.1.21.153:41182 - -

乌贼代理日志

1580472279.072    252 10.1.21.153 TCP_TUNNEL/200 4429 CONNECT www.wikipedia.org:443 - HIER_DIRECT/91.198.174.192 -

http代理-无法正常工作

microk8s.kubectl exec -it $(microk8s.kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- sh -c "http_proxy=$PROXY curl -I http://www.wikipedia.org 2>/dev/null | head -n 1"

istio日志

[2020-01-31T12:06:40.069Z] "- - -" 0 - "-" "-" 136 681 88 - "-" "-" "-" "-" "10.1.21.154:3128" outbound|3128||proxy 10.1.21.153:42398 10.1.21.154:3128 10.1.21.153:42396 - -

乌贼代理日志

1580472400.158     85 10.1.21.153 TCP_MISS/301 681 HEAD http://www.wikipedia.org/ - HIER_DIRECT/91.198.174.192 -

我使用Wikipedia是因为通过查看响应代码可以清楚地知道它接收的是哪种请求。我的HTTP请求为301，https请求为

编辑：

Microk8s

  • microk8s。 kubectl版本：1.17
  • microk8s。 istioctl版本：1.3.4

我在 IBM Cloud Private

上遇到了同样的麻烦
  • kubectl 版本：1.12
  • istioctl 版本：1.2.2

1 个答案:

答案 0 :(得分：0)

您正在内部容器中执行的curl命令没有重定向后的-L标志。

根据istio documentation：

请注意 curl 的-L标志，该标志指示 curl 遵循重定向。在这种情况下，服务器将HTTP请求的重定向响应（301 Moved Permanently）返回到http://edition.cnn.com/politics。重定向响应指示客户端这次使用HTTPS向https://edition.cnn.com/politics发送附加请求。对于第二个请求，服务器返回了所请求的内容和 200 OK 状态码。

因此，通过在curl命令中添加-L标志，我们可以获得如下重定向的输出：

$ curl -I -L http://wikipedia.org
HTTP/1.1 301 TLS Redirect
Date: Mon, 03 Feb 2020 12:04:56 GMT
Server: Varnish
X-Varnish: 107796482
X-Cache: cp3058 int
X-Cache-Status: int-front
Server-Timing: cache;desc="int-front"
Set-Cookie: WMF-Last-Access=03-Feb-2020;Path=/;HttpOnly;secure;Expires=Fri, 06 Mar 2020 12:00:00 GMT
Set-Cookie: WMF-Last-Access-Global=03-Feb-2020;Path=/;Domain=.wikipedia.org;HttpOnly;secure;Expires=Fri, 06 Mar 2020 12:00:00 GMT
X-Client-IP: REDACTED
Location: https://wikipedia.org/
Content-Length: 0
Connection: keep-alive

HTTP/2 301 
date: Sun, 02 Feb 2020 15:48:09 GMT
content-type: text/html; charset=iso-8859-1
content-length: 234
server: mw1333.eqiad.wmnet
location: https://www.wikipedia.org/
vary: X-Forwarded-Proto
x-ats-timestamp: 1580658489
x-varnish: 325572256 37161482
age: 73007
x-cache: cp3062 miss, cp3050 hit/75960
x-cache-status: hit-front
server-timing: cache;desc="hit-front"
strict-transport-security: max-age=106384710; includeSubDomains; preload
set-cookie: WMF-Last-Access=03-Feb-2020;Path=/;HttpOnly;secure;Expires=Fri, 06 Mar 2020 12:00:00 GMT
set-cookie: WMF-Last-Access-Global=03-Feb-2020;Path=/;Domain=.wikipedia.org;HttpOnly;secure;Expires=Fri, 06 Mar 2020 12:00:00 GMT
x-client-ip: REDACTED
set-cookie: GeoIP=REDACTED; Path=/; secure; Domain=.wikipedia.org

HTTP/2 200 
date: Mon, 03 Feb 2020 01:38:38 GMT
cache-control: s-maxage=86400, must-revalidate, max-age=3600
server: ATS/8.0.5
x-ats-timestamp: 1580693918
etag: W/"12be8-59c0633ed3519"
content-type: text/html
last-modified: Mon, 13 Jan 2020 14:22:18 GMT
backend-timing: D=320 t=1579084179579408
vary: Accept-Encoding
x-varnish: 335524839 907054142
age: 37578
x-cache: cp3062 miss, cp3050 hit/406421
x-cache-status: hit-front
server-timing: cache;desc="hit-front"
strict-transport-security: max-age=106384710; includeSubDomains; preload
set-cookie: WMF-Last-Access=03-Feb-2020;Path=/;HttpOnly;secure;Expires=Fri, 06 Mar 2020 12:00:00 GMT
x-client-ip: REDACTED
accept-ranges: bytes

因此您的配置可能没有问题。

尝试使用以下命令：

microk8s.kubectl exec -it $(microk8s.kubectl get pod -l app=sleep -o jsonpath={.items..metadata.name}) -c sleep -- sh -c "http_proxy=$PROXY curl -I -L  http://www.wikipedia.org 2>/dev/null | head -n 1"

希望这将向您显示集群配置是否与公司代理一起使用。

编辑：

检查您的鱿鱼配置以进行HTTP访问。根据{{​​3}}文档：

基于已定义的访问列表允许或拒绝访问

要允许或拒绝通过HTTP，HTTPS或FTP端口接收的消息： http_access allow | deny [！] aclname ...

注意默认值：

如果没有“访问”行，则默认为拒绝 请求。

如果“访问”行均未引起匹配，则默认为 列表中最后一行的对面。如果最后一行被拒绝，则 默认为允许。相反，如果允许最后一行，则默认 会否认。由于这些原因，“拒绝”是一个好主意。 访问列表末尾的“全部”条目，以避免潜在的 混乱。

此子句支持快速和慢速ACL类型。看到 squid了解详情。

在http://wiki.squid-cache.org/SquidFaq/SquidAcl中，您具有以下条件：

http_access deny CONNECT !SSL_ports

它拒绝连接到安全SSL端口以外的其他端口。

我建议修改squid配置片段以匹配您正在使用的端口/协议。因为这可能是HTTP带有代理的请求无法正常工作的原因。

希望这会有所帮助。

相关问题
最新问题