finally my config looks like this:
docker run -v /etc/openvpn:/etc/openvpn --rm kylemanna/openvpn ovpn_genconfig \
-u udp://192.168.10.152:1194 \
-n 10.3.0.10 \
-n 192.168.10.1 \
-n 8.8.8.8 \
-n 75.75.75.75 \
-n 75.75.75.76 \
-s 10.8.0.0/24 \
-N \
-p "route 10.2.0.0 255.255.0.0" \
-p "route 10.3.0.0 255.255.0.0" \
-p "dhcp-option DOMAIN-SEARCH cluster.local" \
-p "dhcp-option DOMAIN-SEARCH svc.cluster.local" \
-p "dhcp-option DOMAIN-SEARCH default.svc.cluster.local"
-u
for the VPN server address and port
-n
for all the DNS servers to use
-s
to define the VPN subnet (as it defaults to 10.2.0.0 which is used by Kubernetes already)
-d
to disable NAT
-p
to push options to the client
-N
to enable NAT: it seems critical for this setup on Kubernetes
the last part, pushing the search domains to the client, was the key to getting nslookup
etc.. to work.
note that curl didn't work at first, but seems to start working after a few seconds. So it does work but it takes a bit of time for curl to be able to resolve.
So, to resolve the comppi.ns.exampledomain.com
on your network, you will need help from your DHCP server admin and here is why. At the bottom of this answer the Linux option
Windows environment
Unless additional software is installed, a LINUX client is not AD (Active Directory) aware. So, must rely on DHCP server to update the DNS Server on a properly configured Windows environment.
For the DHCP server to register a hostname on the local DNS server, must have dynamic updates authorized. This setting is not user configurable, your network admin should modify it, and yes, you will need this to work.
Along with the IP address from your DHCP server, you also receive the domain suffix for this network; the suffix is stored by your host and will be used later. Please note than unless your DHCP server and DNS server are on the same box, dynamic updates will require the DHCP server to authenticate with your DNS server.
At this point the DHCP server should do the DNS network registration for you. It is not under the client host control, however your host must request that. Currently Debian request the DNS registration automatically.
On windows your can force a re-registration with ipconfig /registernds
.
On a local network, a host can find your using two 'legal' names and methods: the plain hostname and the hostname plus the domain. The suffix '.local
' if often ignored and is used to avoid the addition of another suffix.
1 The first method doesn't use the DNS: using LAN broadcasts the host ask 'who know this name', the subject host will answer with a MAC address and IP.
Every few seconds, hosts broadcast their names so other sharing the LAN will learn about their presence. Often this broadcast are filtered by switch/routers, so unless you are on the same switch it's hard to make it reliable.
2 The second method is to send a request to the LAN designated DNS server, with the 'plain' hostname and also the hostname with the LAN suffix.
Home router and intranets are not public, so the use of generic DNS (8.8.8.8, 8.8.4.4) on your default DNS server will not resolve your local hosts at all. Every local host with a DHCP assigned address will be 'remembered' by your router.
On your host you can add one or more suffixes that you want when resolving a DNS address (using Linux host
or dig
and on windows nslookup
)
I will recommend to have setup your hostname properly. On /etc/hostname
and also on /etc/hosts
(for ::1 and 127.0.0.1) and then run . /etc/init.d/hostname.sh
.
Manually updating DNS Server from Linux
There is another option that only requires manual cooperation on the client. The use of a little known utility nsupdate. This will add the functionality you require to register on a valid DNS Server. It follows RFC published protocols related to DNS.
Example:
$ nsupdate -v
>delete video.domain.com. a
>delete git.domain.com. a
>delete gateway.domain.com. a
>add video.domain.com. 600 a 192.168.1.111
>add git.domain.com. 600 a 192.168.7.10
>add gateway.domain.com. 600 a 192.168.7.10
>send
>quit
You can create a simple file with your dynamically obtained IPV4 or IPv6 addresses and run on 'post-up' script on /etc/network/interfaces
Best Answer
Support has been available for mDNS and related discovery services on most Linux distros for sometime. Static IPs or fixed hostnames are not scalable for cloud/rapid deployment/Vagrant. Ideally, there is some good hackery in the cloud init tools and also possibly generating a unique hostname based on a string template on first boot (along with reseal scripts).
Anyhow, here's the easy way to get mDNS working for most major OSes.
On CentOS/RHEL/Fedora:
On Debian/Ubuntu: http://wiki.debian.org/ZeroConf
On Arch: https://wiki.archlinux.org/index.php/Avahi
All:
What's nice is this gets mDNS working on the Linux box the other way too, so you can usually just start pinging/ssh/etc to your Mac right way. Woot.
avahi-browse --all
is very neat.Don't forget the inbound firewall rule on the box acting as a server.
Also, configure with /etc/avahi/ and restart the daemon.
Incidentially, I am building a CentOS 6.2 x86_64 minimal appliance for a client on my MacBook Pro under VMware Fusion 4.x.
Perhaps someone will add the bit for making sure that the announcement work and publishing of services (esp. ssh and web urls) works correctly for Mac, Linux and even Windows clients.