When the Fedora 20 server at my parents rebooted because of a general
power failure, the tinc tunnel between my parents and myself didn’t work
anymore.
Troubleshooting
I enabled the debug logging by sending an INT signal to the daemon.
tincd -n ubbink -k INT
This resulted in the following log items (journalctl -f -l –unit
tincd@ubbink.service):
tinc.ubbink[9707]: Got INT signal
tinc.ubbink[9707]: Temporarily setting debug level to 5. Kill me with SIGINT again to go back to level 0.
tinc.ubbink[9707]: Trying to connect to amys (xxx.xxx.xxx.xxx port 655)
tinc.ubbink[9707]: xxx.xxx.xxx.xxx port 655: Network is unreachable
tinc.ubbink[9707]: Could not set up a meta connection to amys
tinc.ubbink[9707]: Trying to re-establish outgoing connection in 35 seconds
tinc.ubbink[9707]: Purging unreachable nodes
I couldn’t find why this was happening because when I used netcat to
connect to port 655 via udp everything worked.
nc -vu xxx.xxx.xxx.xxx 655
Also a telnet to port 655 worked, but why wasn’t tinc able to make the
connection?
Why use :> instead of > ? During a IRC conversation somebody mentioned that using :> was a better way than using >. So to make a file named testfile empty you would use :> testfile
The explaination is that :> is more portable. Some shells (such as zsh) auto-instantiate a cat in the current shell and listen for stdin when given a redirect with no command. Rather than cat /dev/null, : is much simpler.
This blogpost was original posted on Capitar’s blog
The problem When customers ask us to allow some IP addresses to their services they might give us an IP-range in the following way.
10.0.0.1-6 This means they want the following IP addresses to have access: 10.0.0.1, 10.0.0.2, 10.0.0.3, 10.0.0.4, 10.0.0.5 and 10.0.0.6. But when you use this notation with iptables it gives an warning.
# iptables -A INPUT -m iprange --src-range 10.