I have a situation where I am not sure if I am doing something wrong or if the use case is not supported by Istio at all. This is my setup:
I have a VirtualService connected to a Gateway to make some API externally available, e.g. as api1.example.com. The VirtualService is connected to some Service that performs some request preprocessing (some conditional URL rewriting). Now comes the tricky part: the service should forward the request to some API management solution that is running on the same cluster, in a different namespace, and without Istio enabled. This works in general, but I have some additional requirement that troubles me. The API management needs to know to which endpoint the request was originally sent to (to apply the correct rules), so when I forward the request from my service to the API management pod then the HTTP Host header should still be api1.example.com. This is the point where it breaks, I only get 502 Bad Gateway errors.
Now this is the complete setup but I think you can boil it down to the following one (unfortunately, I currently don't have access to some cluster where I could create and test some minimal working example):
pod1 runs in namespace1 with Istio enabled
pod2 runs in namespace2 with Istio disabled and is exposed as service2
Now from pod1 the following works:
wget -qO- http://service2.namespace2.svc.cluster.local
But the following does not:
wget -qO- --header 'Host: api1.example.com' http://service2.namespace2.svc.cluster.local
Any help or hints are highly appreciated!
Some updates following questions that were raised:
Istio version is 1.4.6
When I do wget -qO- http://service2.namespace2.svc.cluster.local than pod2 receives the request and when I read the Host header then it is service2.namespace2.svc.cluster.local
When I do wget -qO- --header 'Host: api1.example.com' http://service2.namespace2.svc.cluster.local then the request does not arrive at pod2 at all
istioctl proxy-config listeners pod1 shows the following (the service in pod1 is running on port 1024, the one in pod2 is running on port 80)
ADDRESS PORT TYPE
100.96.4.131 1024 HTTP
100.96.4.131 15020 TCP
100.69.164.43 443 TCP
10.250.0.42 10250 TCP
10.250.0.47 10250 TCP
100.64.124.217 443 TCP
100.67.245.255 15011 TCP
10.250.0.46 10250 TCP
10.250.0.48 10250 TCP
10.250.0.9 10250 TCP
10.250.0.24 10250 TCP
10.250.0.50 10250 TCP
100.64.124.217 15032 TCP
100.64.0.1 443 TCP
10.250.0.108 10250 TCP
100.64.0.10 53 TCP
10.250.0.34 10250 TCP
10.250.0.8 10250 TCP
10.250.0.37 10250 TCP
100.64.124.217 15029 TCP
10.250.0.30 10250 TCP
10.250.0.36 10250 TCP
10.250.0.105 10250 TCP
100.64.124.217 15031 TCP
100.64.124.217 15030 TCP
10.250.0.92 10250 TCP
100.66.112.190 443 TCP
100.68.34.255 44134 TCP
100.64.124.217 15443 TCP
10.250.0.91 10250 TCP
10.250.0.97 10250 TCP
0.0.0.0 443 TCP
10.250.0.10 10250 TCP
10.250.0.45 10250 TCP
0.0.0.0 9943 TCP
100.64.132.219 9115 TCP
0.0.0.0 10249 TCP
100.70.99.95 443 TCP
100.65.54.197 26379 TCP
100.64.0.10 9153 TCP
0.0.0.0 9090 TCP
0.0.0.0 15014 TCP
100.71.44.89 6789 TCP
100.70.253.4 2020 TCP
0.0.0.0 9094 TCP
100.67.56.56 443 TCP
100.65.133.0 4314 TCP
0.0.0.0 4005 TCP
100.70.229.77 9411 TCP
0.0.0.0 9901 TCP
100.71.167.108 443 TCP
100.69.145.185 9093 TCP
100.70.32.142 443 TCP
100.66.233.175 42422 TCP
0.0.0.0 8080 TCP
100.69.114.203 6789 TCP
100.70.144.106 3300 TCP
0.0.0.0 20001 TCP
0.0.0.0 4004 TCP
0.0.0.0 9093 TCP
100.67.179.223 9000 TCP
100.70.18.125 3300 TCP
100.64.255.234 9090 TCP
100.66.197.157 9710 TCP
100.67.193.139 3300 TCP
100.69.114.203 3300 TCP
0.0.0.0 16909 TCP
0.0.0.0 3000 TCP
0.0.0.0 15004 TCP
100.68.54.218 9115 TCP
0.0.0.0 8060 TCP
0.0.0.0 8008 TCP
100.70.162.45 9115 TCP
0.0.0.0 15010 TCP
0.0.0.0 10054 TCP
100.65.13.208 5473 TCP
100.67.193.139 6789 TCP
100.71.44.89 3300 TCP
100.70.18.125 6789 TCP
100.67.56.56 8081 TCP
0.0.0.0 9411 TCP
0.0.0.0 2379 TCP
100.66.228.227 8081 TCP
0.0.0.0 9091 TCP
0.0.0.0 5556 TCP
100.64.124.217 15020 TCP
100.68.245.60 7000 TCP
0.0.0.0 9283 TCP
0.0.0.0 80 TCP
0.0.0.0 3100 TCP
100.66.228.227 8080 TCP
100.70.144.106 6789 TCP
0.0.0.0 1024 TCP
100.70.229.77 14268 TCP
0.0.0.0 15019 TCP
0.0.0.0 5558 TCP
100.70.229.77 14267 TCP
100.67.17.80 9100 TCP
0.0.0.0 15001 TCP
0.0.0.0 15006 TCP
100.96.1.142 443 TCP
0.0.0.0 15090 HTTP
In order to be able to communicate between istio injected service and service that is external (to istio service-mesh), You will need to use ServiceEntry object.
According to istio documentation:
ServiceEntry enables adding additional entries into Istio’s internal service registry, so that auto-discovered services in the mesh can access/route to these manually specified services. A service entry describes the properties of a service (DNS name, VIPs, ports, protocols, endpoints). These services could be external to the mesh (e.g., web APIs) or mesh-internal services that are not part of the platform’s service registry (e.g., a set of VMs talking to services in Kubernetes). In addition, the endpoints of a service entry can also be dynamically selected by using the workloadSelector field. These endpoints can be VM workloads declared using the WorkloadEntry object or Kubernetes pods. The ability to select both pods and VMs under a single service allows for migration of services from VMs to Kubernetes without having to change the existing DNS names associated with the services.
Like You mentioned:
pod1 that runs in namespace1 with Istio enabled
pod2 that runs in namespace2 with Istio disabled and is exposed as service2
In this scenario the service2 will require a ServiceEntry object that will add it to Istio service mesh registry. This will allow the service2 to be used as if it was within Istio. Note that istio features that require envoy proxy will not work for this service as it is not actually istio injected.
I suggest following this istio Accessing External Services guide.
Related
I'm using Squid Proxy for (DNS Filtering), I have configured squid proxy behind my GCP Cloud NAT in transparent mode to intercept HTTP and HTTPS Web Traffic, I have added only below rules to redirect HTTP and HTTPS traffic to squid.
iptables -t nat -A PREROUTING -s 0.0.0.0/0 -p tcp --dport 80 -j REDIRECT --to-port 3129
iptables -t nat -A PREROUTING -s 0.0.0.0/0 -p tcp --dport 443 -j REDIRECT --to-port 3130
But as I have learned so far Squid is a web proxy and only handling HTTP, HTTPS, TCP & FTP Requests, Squid does't understand SMTP,UDP and any other protocol request, but above iptables rules only working for HTTP and HTTPS rest of the thing are getting block like SMTP & UDP Request. As I understand we can't tell squid to handle SMTP and UDP Request therefore I only want to handle HTTP and HTTPS traffic on squid and rest of the traffic directly redirected or bypass to my GCP Cloud NAT.
Can anybody help me which iptables rule I need to write to only redirect port 80, 443 to Squid, and rest of the port request I want to bypass or redirect directly to my GCP Cloud NAT
I only want to redirect port 80, 443 to squid and rest of the port I want to bypass or redirected to GCP Cloud NAT.
I used WAMP in the past without problem.
I needed to use skype for once, so I did and now the Apache service of WAMP won't start. When I test port 80 using the WAMP tools, I get this message:
***** Test which uses port 80 *****
===== Tested by command netstat filtered on port 80 =====
Test for TCP
Port 80 is not found associated with TCP protocol
Test for TCPv6
Port 80 is not found associated with TCP protocol
===== Tested by attempting to open a socket on port 80 =====
Your port 80 seems not actually used.
Unable to initiate a socket connection
Error number: 10061 -
I tried changing the port Skype uses, but this is not possible in the Windows 10 version. I installed Skype Classic and changed the port there, no result. Then changed Apache to port 8080, without result, so I changed it back to 80.
I fully uninstalled both Skype and Skype classic, then I uninstalled WAMP and installed it fresh again. Even after the removal of Skype and resinstallation of WAMP I still get the same error message.
I also tried to kill the tasks using port 80, but the only task I can actually kill is my firefox browser, result of netstat below.
C:\Windows\system32>netstat -aon | findstr :80
TCP 192.168.178.27:49893 93.184.220.29:80 ESTABLISHED 13120
TCP 192.168.178.27:49917 216.58.211.99:80 TIME_WAIT 0
TCP 192.168.178.27:49918 23.208.79.207:80 TIME_WAIT 0
TCP 192.168.178.27:49919 88.221.254.211:80 TIME_WAIT 0
TCP 192.168.178.27:49926 52.85.249.5:80 TIME_WAIT 0
TCP 192.168.178.27:49931 23.208.77.171:80 TIME_WAIT 0
TCP 192.168.178.27:49939 23.208.77.171:80 TIME_WAIT 0
TCP 192.168.178.27:49953 216.58.211.99:80 TIME_WAIT 0
TCP 192.168.178.27:49960 216.58.211.99:80 TIME_WAIT 0
Any help is appreciated.
I'm doing a GET request to my EC2 instance, but I'm getting the following error:
80: Connection refused
These are the security rules of my instance:
Ports Protocol Source launch-wizard-1
80 tcp 0.0.0.0/0 ✔
22 tcp 177.32.53.207/32 ✔
What's wrong with these rules? Why can't I access port 80?
EDIT
I attached my apache conf file (/etc/apache2/apache2.conf) in this url, since it's too big to post all the code here.
EDIT2
when I run netstat -ntlp | grep LISTEN
I get this:
(No info could be read for "-p": geteuid()=1000 but you should be root.)
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN -
tcp6 0 0 :::80 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN
What is the source of your connection request? Are you attempting to access your instance from outside of Amazon or from a difference EC2 instance in the same availability zone? Are you supplying an IP address or a DNS name as the argument to your connecting code?
Keep in mind that AWS EC2 uses SDN (software defined networking) which doesn't work quite like classical TCP/IP routing that you may be expecting from using Linux, or other OSes, on bare metal systems (or even on VMs using more traditional networking).
Ultimately you will probably want to allocate "elastic IP" (EIP) from AWS and bind it to your web server instance. Then route your requests to that IP address. (Often you'd also create a DNS entry, perhaps through Amazon's "Route53" service to use the a name rather than the address).
It's possible to get to your instance from within and from outside their network. But you have to use the Amazon generated DNS name to do so then, because they use split-horizon, your clients will get the correct (internal or external) IP address.
Also you have to consider the security settings on your VPC (virtual private cloud) network(s) as well as those you've applied to your instance.
When I start Tomcat I see the following using netstat (filtered by tomcat PID):
TCP 0.0.0.0:5007 xxxx34793KZ:0 LISTENING
TCP 0.0.0.0:8081 xxxx34793KZ:0 LISTENING
TCP 0.0.0.0:8543 xxxx34793KZ:0 LISTENING
TCP 127.0.0.1:8005 xxxx34793KZ:0 LISTENING
TCP 127.0.0.1:29821 xxxx34793KZ:29822 ESTABLISHED
TCP 127.0.0.1:29822 xxxx34793KZ:29821 ESTABLISHED
TCP 127.0.0.1:29823 xxxx34793KZ:29824 ESTABLISHED
TCP 127.0.0.1:29824 xxxx34793KZ:29823 ESTABLISHED
TCP 127.0.0.1:29830 xxxx34793KZ:29831 ESTABLISHED
TCP 127.0.0.1:29831 xxxx34793KZ:29830 ESTABLISHED
TCP 127.0.0.1:29832 xxxx34793KZ:29833 ESTABLISHED
TCP 127.0.0.1:29833 xxxx34793KZ:29832 ESTABLISHED
TCP 127.0.0.1:29834 xxxx34793KZ:29835 ESTABLISHED
TCP 127.0.0.1:29835 xxxx34793KZ:29834 ESTABLISHED
TCP 127.0.0.1:29836 xxxx34793KZ:29837 ESTABLISHED
TCP 127.0.0.1:29837 xxxx34793KZ:29836 ESTABLISHED
TCP [::]:8081 xxxx34793KZ:0 LISTENING
TCP [::]:8543 xxxx34793KZ:0 LISTENING
Ports 29821-29824 and 29830-29837 are what I'm wondering about.
I have searched the web, tomcat documentation, tomcat source code and any mailing list I can think of (including Stackoverflow) and can find nothing on the purpose of these TCP ports. They come in pairs which implies to me that they are possibly configured to loopback. I'm stumped as to why Tomcat needs these.
Our application that runs on Tomcat gets installed into environments where IT Security is quite robust, so they want to know the reason for every port in use.
Any ideas?
I am running an Ubuntu 12.04 server with Apache 2.2 and OpenSSL 1.01(recent). I am attempting to serve a self signed certificate across for HTTPS browsing. The server is also running webmin, and a tomcat application server.
Currently HTTPS requests do not work for the primary server, returning an er_connection_refused.
I am currently using virtual hosts to specify locations for https connections. HTTPS only works for my webmin portal and not for any other location on the webserver. I had assumed this was a port conflict between miniserv and apache, however there doesn't appear to be any conflict that I can determine. I have checked for other possible webservers that may be using SSL (such as jetty or nginx) but there doesn't appear to be any.
Is there any way to determine which services are associate with which ports. Failing that is there any way to determine which services are currently using SSL.
Thanks in advance.
To find out which services are listening on SSL run:
netstat -tulpn | grep :443
It will generate output like:
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 1607/https
It sounds like it could also be a conflict in the way you have set up SSL for the virtual hosts. Often vhost config can be a bit funny if you're sharing the same certificate for multiple vhosts.
Edit:
Also another good one for finding what is using a given port is:
lsof -i :443 | grep LISTEN
Which generates output as:
httpd 1132 apache 5u IPv6 22762080 0t0 TCP *:https (LISTEN)
httpd 3084 apache 5u IPv6 22762080 0t0 TCP *:https (LISTEN)
httpd 3312 apache 5u IPv6 22762080 0t0 TCP *:https (LISTEN)
httpd 3555 apache 5u IPv6 22762080 0t0 TCP *:https (LISTEN)
httpd 3593 apache 5u IPv6 22762080 0t0 TCP *:https (LISTEN)