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.
Related
I have installed GitLab server on a virtual machine (VMWare). GitLab IP address is 192.168.1.4 . I can see GitLab from browser. I generated ssh-key and added to GitLab server.
When I run ssh -T git#192.168.1.4 I got this error:
ssh: connect to host 192.168.1.4 port 22: Connection refused
Not only you need to run SSHD in your GitLab server (type netstat -l -t -n to check that it listens on port 22, as in here).
But you also need to check for:
firewall rules
port mapping (in your VMWare configuration)
I've a Python 3 Flask app running in an ECS cluster. The Flask app is configured to run in SSL mode. The app can't be accessed via the ALB Cname, as it generates connection refused as seen here -
curl -Il https://tek-app.example.com/health
curl: (7) Failed to connect to tek-app.example.com port 443: Connection refused
When the ALB is hit directly and ignoring the SSL cert exception, it works as seen here -
curl -Il -k https://tek-w-appli-1234.eu-west-1.elb.amazonaws.com/health
HTTP/2 200
date: Sun, 24 Feb 2019 14:49:27 GMT
content-type: text/html; charset=utf-8
content-length: 9
server: Werkzeug/0.14.1 Python/3.7.2
I understand the main recommendation is to run it behind a Nginx or Apache proxy and to set the X-Forward headers via their configs, but I feel this is over engineering the solution.
I've also tried enabling the following in the app -
from werkzeug.contrib.fixers import ProxyFix
...
app = Flask(__name__)
app.wsgi_app = ProxyFix(app.wsgi_app)
...
And this fix now produces the correct source IP's in the Cloudwatch logs, but doesn't allow connections via the ALB Cname.
Is there something simple that I'm missing here?
Reply to first answer
Thank you - the Cname is pointing to the correct ALB. I ran into a similar issue two weeks back with an Apache server, and the fix was to ensure X-Forward-Proto was in use in the Apache vhosts.conf file. So I'm thinking this may be something similar.
I did it again - while developing locally I edited my /etc/hosts file to have a local entry to play with. Then when the Flask app was pushed to the cloud and tested from the same desktop, it was referencing the local DNS entry as opposed to the public equivalent, thus the connection refused. With the local entry removed, all is now working.
I am new to using Google Cloud Platform and am trying to host a very simple static site. I have followed Google's tutorial for running a basic apache webserver exactly and yet, when I click on the external IP of my site, I am taken to a page that says "This site can't be reached. <my site's IP address> unexpectedly closed the connection ERR_CONNECTION_CLOSED.
Since creating the VM, I have run the following commands:
sudo apt-get update && sudo apt-get install apache2 -y
echo '<!doctype html><html><body><h1>Hello World!</h1></body></html>' | sudo tee /var/www/html/index.html
I also ran ping <site IP address> and saw lines of the form
PING <IP address> 56(84) bytes of data.
64 bytes from <IP address>: icmp_seq=1 ttl=76 time=0.746 ms
I have ensured that the Firewall settings on my VM are set to allow both HTTP and HTTPS traffic.
Why can I not see the simple Hello World page that should be hosted at my site? Do I need to manually start apache? I have tried to and not had any success.
(My VM has Debian 8 as the Boot Image)
UPDATE
At the request of a user below, I ran sudo service apache2 status but got the response below:
apache2.service - LSB: Apache2 web server
Loaded: loaded (/etc/init.d/apache2)
Drop-In: /lib/systemd/system/apache2.service.d
└─forking.conf
Active: active (running) since Mon 2017-01-23 01:27:44 UTC; 11h ago
CGroup: /system.slice/apache2.service
├─2570 /usr/sbin/apache2 -k start
├─2573 /usr/sbin/apache2 -k start
└─2574 /usr/sbin/apache2 -k start
Running sudo service apache2 start did not seem to do anything.
service apache2 status
and
service apache2 start
On the VM did you check the boxes to allow HTTP?
Can you telnet to port 80 of your server ?. Try the following command:
telnet your-server-ip 80
If the above command does not work, then most likely the firewall is blocking port 80. Do you have a second firewall running on your server, such as iptables?.
You need to enable SSL for apache.
(the important bit is making a syslink in the sites-enabled folder of the ssl config file in the site-available folder) that will get it running but you'll need to tinker with the ssl key/cert stuff (check out certbot)
here is a guide: https://hallard.me/enable-ssl-for-apache-server-in-5-minutes/
To those facing this same issue, by default google tries to access URL/IP on HTTPS. But since SSL is not installed, it will not be able to access it. You have two options, 1) Install SSL on the root IP or remove the 's' in the https://xxxxxx address.
https://xxxipORwebAddress
to
http://xxxipORwebAddress
I hope it helps
I'd like to use forticlientsslvpn on Cent OS 7 through a proxy but it doesn't work with a message "Can not connect to proxy" or "Can not resolve proxy address". I guess it needs some dependent libraries but I don't know them.
I downloaded the latest Forticlient SSLVPN 4.4.2329-1 64bit from here. (I installed it on debian then copied the forlder(/opt/forticlientsslvon) to the clean Cent OS 7.)
Both forticlientsslvpn CLI and GUI failed on the same error. This is the result of the cli command.
[root#cent7 /]# cd ~/forticlient-sslvpn/64bit/
[root#cent7 /]# ./forticlientsslvpn_cli --proxy 10.0.0.73:3128 --server 203.0.113.1:10443 --vpnuser myuser
Password for VPN:
STATUS::Setting up the tunnel
STATUS::Connecting...
NOTICE::Can not connect to proxy.
STATUS::Set up tunnel failed
SSLVPN down unexpectedly with error:2
Press Ctrl-C to quit
Clean up...
# Another proxy variable
[root#cent7 /]# ./forticlientsslvpn_cli --proxy http://10.0.0.73:3128 --server 172.17.97.85:10443 --vpnuser myuser
Password for VPN:
08/19/2016 18:19:26 [23461] can not resolve name http://10.0.0.73
Init SSLVPN error:Can not resolve proxy address
# Check the proxy connection
[root#cent7 /]# telnet 10.0.0.73 3128
Trying 10.0.0.73...
Connected to 10.0.0.73.
Escape character is '^]'. # OK
# Check DNS
[root#cent7 /]# nslookup 10.0.0.73
Server: 10.0.0.70
Address: 10.0.0.70#53
Non-authoritative answer:
73.0.0.10.in-addr.arpa name = dns.example.com.
Of cource my forticlient on windows in the same network works with the proxy to the server. And FireFox/wget on this Cent OS 7 server works with the proxy. Does anyone know anything about "Can not connect to proxy" error?
My IP was wrong and needed ip route add
Although the error message was "Can not connect to proxy", my destination forti IP was wrong. It was connected after I fixed it.
One more thing, I noticed a confusing point. I have two proxies like a socks proxy and a web proxy at this time. I knew ssl-vpn uses only web connections but I guessed forticlient might use ssh command during the connection. But it didn't. Forticlient_sslvpn needs only a web proxy so we just need to fill the proxy form of forticlient with a web proxy's url.
And one more thing. After I connected to ssl-vpn, it doesn't work perfectly because I can ping to internal server but not to DMZ(Of course my windows forticlient works well for both). I added ip route to DMZ and it started to work.
ip route add 192.168.3.0 via 10.0.0.5
I guessed this GW 10.0.0.5 is not the same everytime and every machine so I made the dynamic command.
ip route add 192.168.3.0/24 via $(ip route | grep 10.0.0 | awk '{print $3}' | head -1)
I hope this helps someone.
I have Two Linux Machine Redhat & Centos Under Window 7(as host) In Vmware Workstation.
I configure DNS server & DHCP Server in Redhat(10.0.0.1).
Client which is Centos is able to get IP(10.0.0.30) from DHCP server but it is not picking up name from DNS Server.
Problem is At server 10.0.0.1 i am able to ping itself by hostname like
root#server->ping server.example.com Ping successfull
But Client is not able to ping Server by Hostname like
root#localhost->ping server.example.com Ping Not Successfull
Client is able to ping Server by its ip like
root#localhost->ping 10.0.0.1 Ping Successfull
Now My questn is that Why Client is not able to ping server by its hostname & why client is not picking up name from DNS server,
Just had similar issue on my Debian VM running on a Win7 host.
Setting up DNS server isn't enough to resolve server name, especially when proxy is used in your network environment.
To solve it, you've to export http_proxy environment variable on command line before calling other executables. For example:
export http_proxy="http://{your proxy ip address here}:{your proxy port here}"
As usual, remember to add it to your profile script so you don't redo it after each boot.