Forwarding VLANs over the Internet

Once the leadership of our organization set the task to include an office in another city in the main corporate network. At the same time, several virtual networks (VLANs) were used inside the corporate network - for telephony, database access, equipment management, etc. For some reason, it was not possible to rent a direct channel for forwarding these VLANs.

Since CentOS 6-based machines acted as external routers in both offices, it was decided to use OpenVPN for the transit of internal traffic. The initial idea of ​​a separate tunnel for each VLAN was quickly abandoned due to the low scalability of the solution.

The Open vSwitch project came to the rescue - a soft switch with VLAN support (IEEE 802.1q).
')

The scheme of the virtual network.

OpenVPN Tuning Configuration

There is a lot of information on setting up OpenVPN on the network and on Habré , so I’ll immediately provide a configuration with some comments.


A tap device is used to transmit ethernet frames.

The bridge.sh script is used to make a network tap device into a virtual switch (ovs). When restarting an OpenVPN daemon, it is necessary to bring the tap device into the switch and re-enter it; without this crutch, the traffic from the virtual switch does not reach it. This problem has not yet been resolved beautifully.
As it is not difficult to guess, the tunks parameter describes the ability of the virtual port to transmit the tagged traffic of the specified vlans.

Configure open vSwitch

In most modern distros open vSwitch is already present entirely. At CentOS 6, there is only a kernel module. You will have to search for a package with a virtual switch daemon in third-party repositories, or build it yourself. Information on assembling the package in the network is sufficient; this process should not cause any difficulties. After installing and running the daemon, you need to create a virtual switch device. For this, a configuration file of the ifcfg-ovs0 interface is created:

DEVICE=ovs0 ONBOOT=yes DEVICETYPE=ovs TYPE=OVSBridge BOOTPROTO=static HOTPLUG=no 

what corresponds to the team

 ovs-vsctl add-br ovs0 

Interface Configuration

Configuring the ports of the virtual switch is practically no different from the settings of conventional system network interfaces. To add the interface to the switch, the ifcfg-eth0.197 interface configuration file is created:

 PHYSDEVICE=eth0 DEVICE=eth0.197 ONBOOT=yes DEVICETYPE=ovs TYPE=OVSPort OVS_BRIDGE=ovs0 OVS_OPTIONS="tag=197" BOOTPROTO=none HOTPLUG=no 

What corresponds to the command:

 ovs-vsctl add-port ovs0 eth0.197 

I note that when adding an interface to a virtual switch, the ip-address of this interface is no longer accessible. If you need to use the ip address on this VLAN interface in the north, you need to transfer it to the virtual internal port of the switch. The configuration file ifcfg-vi197 in this case will look like this:

 DEVICE=vi197 ONBOOT=no DEVICETYPE=ovs TYPE=OVSIntPort BOOTPROTO=static IPADDR=10.0.120.253 NETMASK=255.255.255.0 OVS_BRIDGE=ovs0 OVS_OPTIONS="tag=197" HOTPLUG=no ARPCHECK=no 

What corresponds to the command:

 ovs-vsctl add-port ovs0 vi197 tag=197 -- set Interface vi197 type=internal 

By analogy, the remaining interfaces of VLANs are created.

You can view the current state of the virtual switch ports with the command:

 ovs-vsctl show 

In my case, the configuration was as follows:

Conclusion

As a result, we get the passage of tagged traffic over an encrypted channel via the Internet.

The solution turned out to be easily scalable; it is easy to add both new VLANs and new remote networks.

PS: Instead of OpenVPN, you can use the GRE tunnel built into the open vSwitch. He has not had time to figure it out yet and I am not sure about the possibility of encrypting traffic when using it.