I have found a partial answer to this question, and it is successfully setting the machine at the desired IP address. But the network is unreachable from inside a docker-machine created with the Hyper-V driver.
The TLDR on the answer above is to create a script, /var/lib/boot2docker/bootsync.sh:
sudo cat /var/run/udhcpc.eth0.pid | xargs sudo kill
sudo ifconfig eth0 192.168.XXX.YYY netmask 255.255.255.0 broadcast 192.168.XXX.255 up
Once I make the script, I restart the machine.
When I restart the machine, the IP is set to my desired address (expected). I can remote in at the address, so it is at least available through the host. But when I test for connections, there is no connection to the internet (unexpected).
Boot2Docker version 17.05.0-ce, build HEAD : 5ed2840 - Fri May 5 21:04:09 UTC 2017
Docker version 17.05.0-ce, build 89658be
docker#machine:~$ docker pull ubuntu
Using default tag: latest
Error response from daemon: Get https://registry-1.docker.io/v2/: dial tcp: lookup registry-1.docker.io on [::1]:53: read udp [::1]:48331->[::1]:53: read: connection refused
docker#machine:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network is unreachable
If I remove the script and restart again, I am reassigned a new/random IP address (expected), remote in at that new IP address, and can do network connections (expected):
docker#pm:~$ docker pull ubuntu
Using default tag: latest
latest: Pulling from library/ubuntu
aafe6b5e13de: Pull complete
0a2b43a72660: Pull complete
18bdd1e546d2: Pull complete
8198342c3e05: Pull complete
f56970a44fd4: Pull complete
Digest: sha256:f3a61450ae43896c4332bda5e78b453f4a93179045f20c8181043b26b5e79028
Status: Downloaded newer image for ubuntu:latest
docker#pm:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=43 time=18.424 ms
64 bytes from 8.8.8.8: seq=1 ttl=43 time=27.638 ms
The accepted answer has several up votes, but it reads like this is a confirmed work around on VirtualBox. Not sure what about Hyper-V would be causing the IP assignment to cut off internet access.
I had the same problem, and I solved it by adding the following to the end of bootsync.sh:
route add default gw <address>
There was no default route to the gateway or the internet, so it must be set manually.
Related
I am trying to use a single IP as a "floating IP" by assigning it to a secondary interface eth1 between 2 VMs. The primary interface eth0 has 2 different IPs for both VMs. Only one of the VMs will have the IP assigned to eth1 at any given time. If we have any issues with the primary VM we will unassign the IP from eth1 of the primary VM and reassign it to the secondary VM.
We are unassigning and assigning the IP using -
/sbin/ip addr ${ACTION} ${IP} dev ${INTERFACE}
However once we unassign the IP from eth1 of the primary VM and assign it to eth1 of the secondary VM I am unable to ssh to the secondary VM right away. I get a -
ssh: connect to host x.x.x.x port 22: Connection timed out
After about 15 mins some cache somewhere gets cleared and then I am able to ssh to the secondary box.
Have the following setting already updated in sshd_config and sshd has been restarted.
GSSAPIAuthentication no
UseDNS no
We are using Redhat 7.6
Any help in the troubleshooting what could be causing the delay in ssh'ing to the secondary box is much appreciated!
Thanks!
Your issue is with your network gear and the clients arp tables.
After you change the address check your arp tables with arp -a on Linux and show ip arp (Cisco gear). You will see the old MAC address maps to the old server IP.
After you change ip addresses send a gratuitous arp and that will force everything to update.
Assume your ethernet address is 10.0.10.1 and you are using eth1.
yum install arping -y
arping -A -I eth1 10.0.10.1
This very similar to what VMware does when you VMotion a VM to another host. It sends an RARP to notify the network the MAC address has moved to different a port.
EDIT: Also note, in older RHEL ver ifup-eth script used the arping tool to send a GARP. That means I might also try ip link set eth1 down and ip link set eth1 up see if that works.
This issue got resolved. We had to update the arp neihbor cache to get this to work so incorporated that into our script.
I have searched and I know people have asked this before, but I have been through all settings and double, triple checked everything but I can't get it to work for the life of me. I have not this before with other machines, but I don't know why this isn't working.
*note: numbers have been changed for security reasons
Here is what I have:
Client
Raspberry Pi 3 with IP: 192.168.0.133
manual port in raspberry pi 3 sshd_config file: 1502
Router:
NAT Virtual Server:
External port: 1502
Internal port: 22
IP address: 192.168.0.133
DNS(duckdns.org)
- checked to make sure public IP address points to the domain: testing2#duckdns.org
ssh command that works on client:
ssh -p 1502 client#192.168.0.133
ssh command that doesn't work
ssh -p 1502 client#testing2.duckdns.org
So I'm not sure where it's going on. here is output from ssh -v -p 1502 client#testing2.duckdns.org
OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: Reading configuration data /Users/testing/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to testing2.duckdns.org [188.45.22.61] port 1502.
debug1: connect to address 188.45.22.61 port 1502: Connection refused
ssh: connect to host testing2.duckdns.org port 1502: Connection refused
Any ideas? I really would appreciate any insights.
EDIT: To add some more clarifying information:
When I run the second command listed above, that is failing:
ssh -p 1502 client#testing2.duckdns.org
This goes out to the DNS I have setup (testing2.duckdns.org) and that DNS points to my network's public facing IP address. At that point, it hits the NAT routing rule I have setup on my router that forwards any requests from port 1502 to the internal port of 22 to the IP address of 192.168.0.133.
This is why I don't understand where it is failing, all the rules are there and the route should be open. Is there a setting on the raspberry pi (within the config file) that I'm missing?
So I figured out what was going on, and although I am still not able to connect remotely, I have solved what the original question posed.
The problem was I had changed the port on the raspberry pi (the internal port) to 1502. This meant that the route was forwarding correctly (from external of 1502 to internal of 22) but then the internal port was set to 1502, so it failed to connect.
This also explains why it would connect locally with the above command because the local port was 1502.
I still can't connect remotely because the raspberry pi is running a VPN and this is causing the SSH request to timeout, but that is a separate question.
Thanks for the help everyone!
For a project, I need to access the faculty server
Remotely through ssh after connecting the faculty VPN with my credentials.
Before,I log in quietly until recently with:
ssh my_name_user#147.163.26.244
it appeared to enter the password and entering the credentials I accessed the server (actually a virtual machine mounted on the server for me).
Now with the command above nothing happens and after waiting a bit I get:
ssh: connect to host 147.163.26.244 port 22: Connection timed out
What may have happened?
Yesterday I changed my password to access University services (mandatory after 3 months for security reasons). After doing so I had to change that new password in the VPN configurations and I was able to have access to the VPN and also to the server, until this all ok. From today at 13.00 this problem occurs.
Does anyone have any idea what this is all about?
(I'm on Ubuntu. The server(the virtual machine is a Lubuntu system))
Thanks for your attention.
Update:
The command
ping 147.163.26.244
gives me:
PING 147.163.26.244 (147.163.26.244) 56(84) bytes of data.
and
telnet 147.163.26.244 22
gives:
Trying 147.163.26.244...
and it remain running. What can I deduce?
As ssh shows connection timeout its nothing to do with your credentials. It hasn't go to the authentication level but failing before that itself.
First of all check if the IP is accessible from you machine using Ping (hoping ICMP should be allowed by the Firewall).
ping server_ip
If it shows not accessible- then make sure there is a route for the IP/IP subnet of the server IP through the vpn tunnel. You can do it by using route/netstat
example
netstat -nr | grep "147.163"
If route is not present you may have to add a route for this IP through the VPN tunnel. You can find the "route add.." or "ip route add ... " commands for this from google depending on your machine platform.
If the Ping shows the IP is pinging, we need to make sure the ssh service is running on the port 22. Just do a telnet and check
telnet <server_ip> 22
if the connection shows UP, in your case which shouldn't show UP btw :)as you got a timeout already. Then problem can be
(1) ssh service not running
(2) any firewall blocking your connection
You may have to get in touch with the ADMIN in that case.
===== Update =========
I guess your ping itself is failing.
Ping should show it is getting response.
example :
XXXXXXX$ ping 216.58.217.174
PING 216.58.217.174 (216.58.217.174): 56 data bytes
64 bytes from 216.58.217.174: icmp_seq=0 ttl=43 time=273.068 ms
64 bytes from 216.58.217.174: icmp_seq=1 ttl=43 time=317.405 ms
64 bytes from 216.58.217.174: icmp_seq=2 ttl=43 time=361.682 ms
64 bytes from 216.58.217.174: icmp_seq=3 ttl=43 time=266.436 ms
Check for the routes in your machine using route or netstat.
Possibilities :
server is down
Proper route is not present for the IP/subnet of the ssh server through VPN tunnel
Let me explain my very strange problem. I have one server (Linux Debian Jessie) which had access to my git repository on gitlab.com
Two days ago, I tried to pull some modifications on this server with a simple git pull. I received an error message :
ssh: connect to host gitlab.com port 22: Connection timed out
Si I have done some tests
1. TELNET
To understand why, I have tried a telnet on 22 port = TIMEOUT
2. IPTABLES
I checked my iptables to be sure that SSH port was allowed. It is. If I try a telnet on another service for example like github.com, it works. So I'm allowed in OUTPUT on this port.
3. PING
I thought a ip translation problem. I have done a ping, I obtain this message :
PING 104.210.2.228 (104.210.2.228) 56(84) bytes of data.
--- 104.210.2.228 ping statistics ---
87 packets transmitted, 0 received, 100% packet loss, time 86534ms
4. FAIL2BAN
I use fail2ban, so I have checked if gitlab was in jail address, but it seems not.
So my problem is that I can't reach gitlab.com
If I try from my local machine or from another server, I don't have this problem. It works.
I can't reach gitlab.com only from this server but I don't know why. Maybe someone has an idea which cans be very precious to help me ?
Probably some modification of firewall caused this. For a quick solution use http protocol instead of ssh. Change your url in the git config file to http.
git config --local -e
change entry of
url = git#gitlab.com:username/repo.git , to
url = https://gitlab.com/username/repo.git
You need to give your username and password to authenticate yourself while making a push or pull though as it's http based.
Setup my local dev environment similar to this post and everything was working fine but recently I am unable to access my local dev domains when I am offline. When I am connected to the internet it works fine. I'm wondering if something changed with how resolver is used in Yosemite. It seems as if resolver rules are ignored if I'm offline.
dnsmasq.conf:
address=/.dev/127.0.0.1
listen-address=127.0.0.1
/etc/resolver/dev
nameserver 127.0.0.1
When online:
ping -c 1 mydomain.dev
PING mydomain.dev (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.038 ms
--- mydomain.dev ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.038/0.038/0.038/0.000 ms
scutil --dns
resolver #1
search domain[0] : nomadix.com
nameserver[0] : 203.124.230.12
nameserver[1] : 202.54.157.36
if_index : 4 (en0)
flags : Request A records
reach : Reachable
resolver #2
domain : dev
nameserver[0] : 127.0.0.1
flags : Request A records, Request AAAA records
reach : Reachable,Local Address
when offline:
ping -c 1 mydomain.dev
ping: cannot resolve mydomain.dev: Unknown host
scutil --dns
No DNS configuration available
OSX Yosemite + resolver + dnsmasq offline === resolved !!
when you're offline every interface on your computer, but 127.0.0.1, goes down.
so if you want to have a dns resolution your dns server have to listen to 127.0.0.1. In my case it's dnsmasq I choose because you don't have to be a sys admin to make it work, and it does !
following those simple steps I got it working:
1) brew install dnsmasq
2) cp /usr/local/opt/dnsmasq/dnsmasq.conf.example /usr/local/etc/dnsmasq.conf
if like me it's not properly installed in /usr/local/opt you should be able to read in the brew installation debug lines something like this :
make install PREFIX=/usr/local/Cellar/dnsmasq/2.72
in this case run the following command:
ln -s /usr/local/Cellar/dnsmasq/2.72 /usr/local/opt/dnsmasq
and then back to step 2
3) vi /usr/local/etc/dnsmasq.conf
and add your domains like this for exemple:
address=/foo.dev/192.168.56.101
where in that case every url ending with foo.dev (http://www.foo.dev, http://foo.dev, http://what.ever.you.want.foo.dev, etc...) will be resolved as 192.168.56.101 (this is the kind of ip you have using Virtualbox, 192.168.56.*)
4) sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
5) try it before putting it into the resolver
nslookup foo.dev 127.0.0.1
and expect this :
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: foo.dev
Address: 192.168.56.101
6) mkdir -p /etc/resolver
vi /etc/resolver/dev
add those two lines :
nameserver 127.0.0.1
search_order 1
7) ping foo.dev or hint http://foo.dev or http://so.cool.foo.dev in your browser address bar and you're good to go !!!
8) Be happy !! You can work offline AGAIN !!!!
I've been checking this question for months hoping for an answer. I believe this will help when 10.10.4 drops: http://arstechnica.com/apple/2015/05/new-os-x-beta-dumps-discoveryd-restores-mdnsresponder-to-fix-dns-bugs/
Apple are replacing discoveryd with mDNSresponder (like it used to be)
The problem is when you are offline you should specify a resolver for the root domain '.':
When we search for www.google.com
There is a "." (root domain) added automatically at the end like: www.google.com.
So all you have to do is :
Set all your network interface dns servers to 127.0.0.1:
networksetup -setdnsservers Ethernet 127.0.0.1
networksetup -setdnsservers Wi-Fi 127.0.0.1
...
Create a file /etc/resolver/whatever:
nameserver 127.0.0.1
domain .
See this question for more details