We are having following setup :-
Azure Linux VM in subnet1 inside VNET01
Azure databricks hosted using custom connected VNET inside VNET01.
While making a connection from Azure VM with ADB we are facing following issue :-
export DATABRICKS_TOKEN=sdgsdgsyd2382732
curl -X GET --header "Authorization: Bearer $DATABRICKS_TOKEN" https://adb-xyz.azuredatabricks.net/api/2.0/clusters/list -vvv
About to connect() to adb-xyz.azuredatabricks.net port 443 (#0)
Trying 40.74.30.80...
Connected to adb-xyz.azuredatabricks.net (30.85.20.80) port 443 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
NSS error -5938 (PR_END_OF_FILE_ERROR)
Encountered end of
It is able to connect to ADB host however fails afterward, we suspect its related to certificates, if it is how can this be resolved, if not, can someone please explain how to handle this issue and make a connection?
Related
I am trying to configure mesibo communication services On-Premise Deployment and tried to deploy while backend application using docker - FastCGI - NGINX. I have followed the below URL https://mesibo.com/documentation/on-premise/#hosting-mesibo-backend-apis Please see the title "Hosting mesibo backend APIs". I have used the 11443 port to deploy the application in the docker.
While checking the command sudo netstat -ltnp getting the following output. So the process is running correctly.
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 267497/mysqld
tcp 0 0 0.0.0.0:11443 0.0.0.0:* LISTEN 535097/backend
When I try to run the command
curl http://0.0.0.0:11443 => getting error as "curl: (56) Recv failure: Connection reset by peer"
Please help me to get out of this issue.
========= Found the Issue - But it may be help someone
run the command 'ifconfig' to find the docker ip address. then try the curl command with that ip address.
Please note, mesibo DOES NOT have any web server so you can't use curl directly.
Refer to this document
https://mesibo.com/documentation/on-premise/#hosting-mesibo-backend-apis
It clearly says you should configure and point to your web server. In turn, your web server will connect to the mesibo FastCGI server. From the above doc
you need to configure a URL on your webserver to access backend APIs.
Any API request received on this URL should be forwarded to the mesibo
backend FastCGI server at the port specified in the command, port 5000
in above example.
Please follow the document and configure a URL on your web server and then curl to that URL.
We are facing issues on 15001 port in istio deployed in Azure AKS.
Currently we have deployed Istio in AKS and trying to connect to Azure cache redis instance in cluster mode. Our Azure redis instance is having more than two shards with SSL enabled and one of the master node is assigned on port 15001. We were able to connect to Azure redis from AKS pods over ports 6380, 15000, 15002, 15003, 15004 and 15005 ports. However when we try to connect to over 15001 we see some issues. When we try to connect to redis over 15001 port from a namespace without istio sidecar injection from same aks cluster the connection is working fine.
Below are the logs from rediscli pod deployed in our AKS cluster.
Success case:
redis-cli -h our-redis-host.redis.cache.windows.net -p 6380 -a our-account-key --cacert "BaltimoreCyberTrustRoot.pem" --tls ping
OUTPUT:
Warning: Using a password with ‘-a’ or ‘-u’ option on the command line interface may not be safe.
PONG
We are able to connect over all ports - 6380, 15000, 15002, 15003, 15004 and 15005 to redis. However when we try to conenct using 15001. We are getting below error
Failure case:
redis-cli -h our-redis-host.redis.cache.windows.net -p 15001 -a our-account-key --cacert "BaltimoreCyberTrustRoot.pem" --tls ping
OUTPUT:
Warning: Using a password with ‘-a’ or ‘-u’ option on the command line interface may not be safe.
Could not connect to Redis at our-redis-host.redis.cache.windows.net :15001: SSL_connect failed: Success
I could not see any entry in istio-proxy logs when trying from 15001 port. However when trying for other ports we can see entry in logs as below
[2021-05-05T00:59:18.677Z] "- - -" 0 - - - "-" 600 3982 10 - "-" "-" "-" "-" "172.XX.XX.XX:6380" PassthroughCluster 172.XX.XX.XX:45478 172.22.XX.XX:6380 172.XX.XX.XX:45476 - -
Is this because 15001 port blocks the outbound requests or manipulates certs for requests on 15001 port. If yes, is there any configuration to update the proxy_port to other ports than 15001?
Note: Posted this on istio forum . Posting here for better reach.
Istio versions:
> istioctl version
client version: 1.8.2
control plane version: 1.8.3
data plane version: 1.8.3
Port 15001 is used by Envoy in Istio. Applications should not use ports reserved by Istio to avoid conflicts.
You can read more here
We have utilised the concept of istio excludeOutboundPorts annotation to bypass the the istio envoy proxy interception of the traffic on outbound ports for which we are see the problem due to istio port requirements
Using annotations provided by istio, we can use either IP or port ranges to exclude the interception. Below is an explain with ports
template:
metadata:
labels:
app: 'APP-NAME'
annotations:
traffic.sidecar.istio.io/excludeOutboundPorts: "15001"
References:
Istio Annotations
Istio traffic capture limitations
Istio Port Requirement
My CentOS 7 server which is in AWS private cloud (company network), is unable to connect to some sites. After some work I managed to narrow the problem down to following problem.
(1) The following internal site is not accessible (SSL by public CA):
curl -v https://git.example.com
which returns:
About to connect() to git.example.com port 443 (#0)
Trying 10.62.124.6...
Connected to git.example.com (10.62.124.6) port 443 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
(2) But following internal site works (SSL by public CA):
curl -v https://alm.example.com
which returns:
About to connect() to alm.example.com port 443 (#0)
Trying 10.64.167.137...
Connected to alm.example.com (10.64.167.137) port 443 (#0)
Initializing NSS with certpath: sql:/etc/pki/nssdb
CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
...
...
...
Accept: */*
Any idea why number (1) is not working? These are both internal sites trusted by same public CA.
Thanks for the help.
It turned out to be the following case in our company.
git.example.com was hosted in private Azure and
alm.example.com was hosted in private AWS. And my working server also happens to be in AWS which is why the Azure one was having some trouble in the network. As advised by network team I set the MTU size in linux kernal to 1350 and this was resolved.
Moreover, our company had also started intercepting SSL traffic for which they have installed a intermediate certificate in the proxy and expect all internal servers to trust this certificate. My problem stated above was due to mix of both of these issues, where the certificate issue could have been sorted by trusting it or ignoring SSL verification.
Hope this helps someone.
I have two VMs setup to learn Puppet - one running puppetserver as my master and another as just a Puppet agent for DNS.
The VMs are running in Hyper-V (Windows 10) and are on the same virtual switch.
After setting up the internal DNS server using this Puppet module - https://github.com/ajjahn/puppet-dns my second, DNS VM can no longer connect to the puppetserver. I receive this error on puppet agent -t runs:
Error: Could not request certificate: No route to host - connect(2) for "puppet.myname.homelab" port 8140
On the puppetserver I have reissued its own agent cert, which changed the cert from puppet <sha-omitted> to "puppet.myname.homelab" <sha omitted> (alt names: "DNS:puppet", "DNS:puppet.myname.homelab")
Running puppet agent -t on the puppetserver to update itself works fine post cert renewal.
I am able to successfully perform a nslookup on any of the hosts using the DNS server, and they do resolve with the new myname.homelab domain.
I still have DHCP enabled on my home router, but I have it set to be the second nameserver in /etc/resolv.conf on both VMs:
search myname.homelab
nameserver 192.168.1.107
nameserver 192.168.1.1
I am running Ubuntu 16.04 and Puppet 4 on both VMs. I have allowed port 8140 in UFW on both VMs, and have even tried disabling UFW with no luck.
I'm still learning Puppet and am a novice to networking, so any suggestions on what else to try and to point me in the right direction would be appreciated.
Thanks!
I slept on it and realized this morning that my router had reassigned my Puppetserver to a new IP, so the DNS A record for it was wrong, even though it was manually assigned in the router's DHCP.
Correcting that did the trick and now everything is working.
Same issue but another cause: the firewwall on the puppet server blocked port 8140. The can be checked on the client as follows:
$ curl -k -I https://puppet:8140
curl: (7) couldn't connect to host
After disabling the firewall on the server (e.g. systemctl stop firewalld):
$ curl -k -I https://puppet:8140
HTTP/1.1 404 Not Found
Date: Thu, 24 Oct 2019 11:27:26 GMT
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html; charset=ISO-8859-1
Content-Length: 278
Server: Jetty(9.2.z-SNAPSHOT)
which is the expected output, and also the puppet agent runs as expected.
According the the Charles Proxy configuration page, you can manually set up a proxy if you use your localhost with port 8080.
The syntax is curl --proxy localhost:8080 http://google.com/
However, this is not working for me. Here is my syntax and results - i'm also using the -v option for debugging:
curl -v --proxy localhost:8080 http://google.com/
* About to connect() to proxy localhost port 8080 (#0)
* Trying 127.0.0.1... Connection refused
* Trying ::1... Connection refused
* Trying fe80::1... Connection refused
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host
I can connect to localhost:8080 in the web browser, and the results are logged in the proxy. However this is not working, the connecting is refused and nothing is logged.
So far I have also tried:
- executing this as root
- using 127.0.0.1 instead of localhost
- using wget instead of curl
- disabling the system firewall
What am I doing wrong? What else can I try?
I had some success using port 8888:
curl http://www.google.com --proxy 127.0.0.1:8888
Connection refused would suggest that nothing is listening on port 8080. Charles has to be running (and listening on port 8080) for curl to be able to use it as a proxy. That or you've got a firewall actively blocking that port, preventing anything from connecting.