Building on top of what we have setup in the last article: Site to Site VPN guide with Wireguard we should probably make our routing setup persist in between restarts. We don't want our work to vanish after a reboot and render our infrastructure unavailable, are we?Now with our objective defined, how do we tackle this? First off, as mentioned in the previous article I run Debian stable which means that the networking stack isn't managed via systemd-networkd, but rather via /etc/network/. Therefore this configuration will be assuming you run the same.To refresh your memory in my setup, I have only 2 peers:Peer 1 in home site acts as a gateway to my LAN.Peer 2 acts just as a standard Wireguard peer.ConfigurationMost of the configuration will be added to the interfaces configuration file that can be found at /etc/network/interfacesOne small change will be added to your sysctl configuration file, generally found at /etc/sysctl.confPeer 1 - Home Site (vpn.m8.sk)This is where I keep main part of the network configuration as this peer is our entry gateway to my LAN, therefore it acts as a router for any incoming traffic to LAN from my VPN network device.This router functionality is achieved by running a NAT, that enables 2 networks( 10.170.1.0/24 & 192.168.0.0/16) to interact between each other.The specific configuration how to achieve this functionality is following:# VPN Tunnel auto wg0 iface wg0 inet static address 10.170.1.1/24 netmask 255.255.255.0 pre-up ip link add dev wg0 type wireguard pre-up wg setconf wg0 /data/containers/conf/vpn.m8.sk/wg0.conf pre-up iptables -A FORWARD -o wg0 -j ACCEPT pre-up iptables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADE post-down ip link delete dev wg0 post-down iptables -D FORWARD -o wg0 -j ACCEPT post-down iptables -t nat -D POSTROUTING -o enp1s0 -j MASQUERADE/etc/network/interfacesAs you can see there is nothing fancy going on, Wireguard accepts simple configuration, therefore we don't do any real magic in here. Let's go through what is being set:We specify what interface we want to configure.We assign IP address and broadcast to the interface.Before we bring up the network device, we create it.Once the network interface is created, we assign Wireguard configuration to it.Now, the main part! We setup NAT via iptables. Thing to watch out for is that you need to specify your main network interface that has access to your LAN in here. In my case this is enp1s0 and that's it!Last few bits are just cleanup commands for when we bring down the interface. In short, it deletes the network device and removes the setup NAT.Last bit is to make sure that our Linux kernel knows how to forward ip packets. This can be achieved by adding following line into your /etc/sysctl.confnet.ipv4.ip_forward = 1/etc/sysctl.confWith all this said, that's it. We don't need to do any further configuration on Peer 1. We can now verify that the setup works by rebooting our Peer 1Reboot test of Peer 1Peer 2 - Remote Site (hertzner-box)Peers that will be connecting to your LAN via VPN, don't need any fancy NATs. The only thing that we need to add to the standard network interface configuration is a static route to our LAN.We apply somewhat similar configuration, again to the same file located at /etc/network/interfaces:# VPN Tunnel auto wg0 iface wg0 inet static address 10.170.1.2/24 netmask 255.255.255.0 pre-up ip link add dev wg0 type wireguard pre-up wg setconf wg0 /data/containers/conf/vpn-2.m8.sk/wg0.conf up ip route add 192.168.0.0/16 dev wg0 post-down ip link del dev wg0/etc/network/interfacesThis configuration is not that different than the first one, so let's go through the differences:The only difference is that after we bring the interface up, we setup a static route to my LAN. In this case 192.168.0.0/16 via wg0 VPN interface.Setup wise we are done, let's test and see, if our configuration works!ifdown && ifup test on Peer 2We can see that the configuration works, and once the interface is brought up it gets setup properly and it automatically connects to Peer 1. In case you would have more peers, you just repeat the above configuration as many times as you have peers. Assuming your peers are setup properly for Wireguard in the first place.Reverse route bonus!Now that our remote site can access our LAN in our home site and the configuration is persisted, we should maybe look into the way, how we can enable our LAN clients to access VPN network without the need to install VPN!Say no more! This part is specific for EdgeRouters, if you have other router taking care of your LAN, you will have to find the appropriate settings yourself.Login to EdgeRouter WebUI, navigate to Routing section in the upper right menu bar. Once there, click the Add Static Route button.Following window will pop up, here you will have to fill it based on your network configuration. In my case, my VPN network subnet is 10.170.1.0/24 and my VPN instance in home site that handles the VPN connections has an address 192.168.1.170/32Static route dialogOnce set, your configuration should look like something around these lines:Now, it's testing time! Let's SSH into some of my machines in home site and test pinging one of our clients in VPN network.Bingoo, everything works as a charm. Now I can reach my remote sites from all my devices on LAN and all my servers in remote sites can reach LAN without an issue. This opens up a lot of possibilities for the future projects! Let's see what will be our next project
Connecting your remote locations with your home network has never been so easy!For quite a long time I've been running 2 sites, my home lab running multiple docker containers, VMs and many more devices that utilized LAN. Then for heavy duty stuff I pay fo
We were slowly, but surely laying down the foundation for our final setup in the Wireguard VPN series. We setup the site to site connection, we made it persistent. Now we put the last piece together; the on-the-go VPN on your smartphone! This is where you
Registrujte nové domény NEWS, SITE nebo INFO se super slevou!
prejsť na článokNew day, new task as an operation guy. This time I have been assigned a task to expand one of our production ElasticSearch clusters. The target; perform it without the downtime of our application nor the cluster. Simple enough, but you never know what can