OpenVPN: routing LAN - Revision history

Unknown user: /* Banyak mesin di belakang OpenVPN (dev tun) */

2022-12-05T00:50:17Z

Banyak mesin di belakang OpenVPN (dev tun)

← Older revision		Revision as of 00:50, 5 December 2022
Line 9:		Line 9:
	Asumsinya IP LAN di belakang OpenVPN server adalah 10.66.0.0/24		Asumsinya IP LAN di belakang OpenVPN server adalah 10.66.0.0/24

			Alternatif lain, disisi client OpenVPN tambahkan

			route 10.66.0.0 255.255.255.0

			Atau via CLI secara manual

			route add -net 10.66.0.0/24 gw ip-server-OpenVPN dev tun0

	== LAN Client di broadcast ke OpenVPN (dev tun) ==		== LAN Client di broadcast ke OpenVPN (dev tun) ==

Unknown user at 00:45, 5 December 2022

2022-12-05T00:45:21Z

← Older revision		Revision as of 00:45, 5 December 2022
Line 3:		Line 3:
	== Banyak mesin di belakang OpenVPN (dev tun)==		== Banyak mesin di belakang OpenVPN (dev tun)==

	Tambahkan di ~~client.ovpn~~		Tambahkan di config server OpenVPN

	push "route 10.66.0.0 255.255.255.0"		push "route 10.66.0.0 255.255.255.0"

Unknown user at 00:44, 5 December 2022

2022-12-05T00:44:56Z

← Older revision		Revision as of 00:44, 5 December 2022
Line 1:		Line 1:
	Sumber: https://openvpn.net/community-resources/expanding-the-scope-of-the-vpn-to-include-additional-machines-on-either-the-client-or-server-subnet/		Sumber: https://openvpn.net/community-resources/expanding-the-scope-of-the-vpn-to-include-additional-machines-on-either-the-client-or-server-subnet/

	== Banyak mesin di belakang OpenVPN (dev tun)		== Banyak mesin di belakang OpenVPN (dev tun)==

	Tambahkan di client.ovpn		Tambahkan di client.ovpn

Unknown user at 00:44, 5 December 2022

2022-12-05T00:44:46Z

← Older revision		Revision as of 00:44, 5 December 2022
Line 1:		Line 1:
	Sumber: https://openvpn.net/community-resources/expanding-the-scope-of-the-vpn-to-include-additional-machines-on-either-the-client-or-server-subnet/		Sumber: https://openvpn.net/community-resources/expanding-the-scope-of-the-vpn-to-include-additional-machines-on-either-the-client-or-server-subnet/

	~~Including multiple machines on the server side when using a routed VPN~~ (dev tun)		== Banyak mesin di belakang OpenVPN (dev tun)
	Once the VPN is operational in a point-to-point capacity between client and server, it may be desirable to expand the scope of the VPN so that clients can reach multiple machines on the server network, rather than only the server machine itself.

	For the purpose of this example, we will assume that the server-side LAN uses a subnet of 10.66.0.0/24and the VPN IP address pool uses 10.8.0.0/24 as cited in the server directive in the OpenVPN server configuration file.		Tambahkan di client.ovpn

	~~First, you must advertise the~~ 10.66.0.0~~/24 subnet to VPN clients as being accessible through the VPN~~. ~~This can easily be done with the following server-side config file directive:~~		push "route 10.66.0.0 255.255.255.0"

	~~push "route~~ 10.66~~.0.0 255.255.255.0"~~		Asumsinya IP LAN di belakang OpenVPN server adalah 10.66.0.0/24
	~~Next, you must set up a route on the server-side LAN gateway to route the VPN client subnet (10.8~~.0.0/24~~) to the OpenVPN server (this is only necessary if the OpenVPN server and the LAN gateway are different machines).~~

	~~Make sure that you've enabled IP and TUN/TAP forwarding on the OpenVPN server machine.~~

	~~Including multiple machines on the server side when using a bridged VPN~~ (dev ~~tap~~)		== LAN Client di broadcast ke OpenVPN (dev tun) ==
	~~One of the benefits of using ethernet bridging is that you get this for free without needing any additional configuration.~~

	~~Including multiple machines on the~~ client ~~side when using a routed VPN (dev tun)~~		Pastikan
	~~In a typical road-warrior or remote access scenario, the~~ client ~~machine connects to the VPN as a single~~ machine. ~~But suppose the client machine is a gateway for a local LAN~~ (~~such as a home office~~)~~, and you would like each machine on the client LAN to be able to route through the VPN.~~		* setiap client mempunya Common Name yang unik di sertifikat-nya.
			* IP & TUN/TAP forwarding di enable di client machine.
			* buat directiry ccd di server OpenVPN (di Linux biasanya di bawah /etc/openvpn)

	~~For this example, we will assume that the~~ client ~~LAN is using the 192.168.4.0/24 subnet~~, and that the VPN client is using a certificate with a common name of client2. Our goal is to set up the VPN so that any machine on the client LAN can communicate with any machine on the server LAN through the VPN.		Tambahkan di konfigurasi server ada reference ke client configuration directory, seperti di bawah ini

	~~Before setup, there are some basic prerequisites which must be followed:~~		client-config-dir ccd

	~~The client LAN subnet~~ (~~192.168.4.0/24 in our example~~) ~~must not be exported to the VPN by the server or any other client sites which are using the same subnet. Every subnet which is joined to the VPN via routing must be unique.~~		Lakukan
	~~The client must have a unique Common Name in its certificate ("~~client2~~" in our example)~~, ~~and the duplicate-cn flag must not be used in the OpenVPN server configuration file.~~		* buat file client2 (misalnya) di directory ccd,
	~~First~~, ~~make sure that IP and TUN/TAP forwarding is enabled on the client machine.~~		* isi file client2 dengan, misalnya,

	~~Next, we will deal with the necessary configuration changes on the server side~~. ~~If the server configuration file does not currently reference a client configuration directory, add one now:~~		iroute 192.168.4.0 255.255.255.0

	~~client-config-dir ccd~~		ini akan memberitahukan OpenVPN server bahwa 192.168.4.0/24 akan melalui client2.
	~~In the above directive, ccd should be the name of a directory which has been pre-created in the default directory where the~~ OpenVPN server ~~daemon runs~~. ~~On Linux this tends to be~~ /~~etc/openvpn and on Windows it is usually \Program Files\OpenVPN\config~~. ~~When a new client connects to the OpenVPN~~ server, the daemon will check this directory for a file which matches the common name of the connecting client. If a matching file is found, it will be read and processed for additional configuration file directives to be applied to the named client.		* Tambahkan di konfigurasi server,

	~~The next step is to create a file called client2 in the ccd directory~~. ~~This file should contain the line:~~		route 192.168.4.0 255.255.255.0

	iroute ~~192.168.4.0 255.255.255.0~~		Mengapa ada perintah route dan iroute yang berlebihan? Alasannya adalah,
	~~This will tell the OpenVPN server that the 192.168.4.0/24 subnet should be routed to client2.~~		* route mengontrol perutean dari kernel ke server OpenVPN (melalui interface TUN)
			* iroute mengontrol perutean dari server OpenVPN ke remote client.
	~~Next~~, ~~add the following line to the main server config file (not the ccd/client2 file):~~		* kedua-nya di perlukan.

	route ~~192.168.4.0 255.255.255.0~~
	~~Why the redundant route and iroute statements, you might ask? The reason is that route controls the routing from the~~ kernel ~~to the~~ OpenVPN ~~server~~ (~~via the~~ TUN ~~interface~~) ~~while~~ iroute ~~controls the routing from the~~ OpenVPN ~~server to the~~ remote ~~clients. Both are necessary.~~

	~~Next, ask yourself if you would like to allow network traffic between client2's subnet (192.168.4.0/24) and other clients of the OpenVPN server~~. ~~If so, add the following to the server config file.~~

	~~client~~-~~to-client~~
	~~push "route 192.168.4.0 255.255.255.0"~~
	~~This will cause the OpenVPN server to advertise client2's subnet to other connecting clients.~~

	The last step, and one that is often forgotten, is to add a route to the server's LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box (you won't need this if the OpenVPN server box is the gateway for the server LAN). Suppose you were missing this step and you tried to ping a machine (not the OpenVPN server itself) on the server LAN from 192.168.4.8? The outgoing ping would probably reach the machine, but then it wouldn't know how to route the ping reply, because it would have no idea how to reach 192.168.4.0/24. The rule of thumb to use is that when routing entire LANs through the VPN (when the VPN server is not the same machine as the LAN gateway), make sure that the gateway for the LAN routes all VPN subnets to the VPN server machine.

	Similarly, if the client machine running OpenVPN is not also the gateway for the client LAN, then the gateway for the client LAN must have a route which directs all subnets which should be reachable through the VPN to the OpenVPN client machine.

			Jika kita ingin agar LAN OpenVPN client dapat dihubungi oleh client lainnya, maka tambahkan perintah berikut di config server,

			client-to-client
			push "route 192.168.4.0 255.255.255.0"

	==Referensi==		==Referensi==

	* https://openvpn.net/community-resources/expanding-the-scope-of-the-vpn-to-include-additional-machines-on-either-the-client-or-server-subnet/		* https://openvpn.net/community-resources/expanding-the-scope-of-the-vpn-to-include-additional-machines-on-either-the-client-or-server-subnet/

Unknown user: Created page with "Sumber: https://openvpn.net/community-resources/expanding-the-scope-of-the-vpn-to-include-additional-machines-on-either-the-client-or-server-subnet/ Including multiple machin..."

2022-12-05T00:21:41Z

Created page with "Sumber: https://openvpn.net/community-resources/expanding-the-scope-of-the-vpn-to-include-additional-machines-on-either-the-client-or-server-subnet/ Including multiple machin..."

New page

Sumber: https://openvpn.net/community-resources/expanding-the-scope-of-the-vpn-to-include-additional-machines-on-either-the-client-or-server-subnet/

Including multiple machines on the server side when using a routed VPN (dev tun)
Once the VPN is operational in a point-to-point capacity between client and server, it may be desirable to expand the scope of the VPN so that clients can reach multiple machines on the server network, rather than only the server machine itself.

For the purpose of this example, we will assume that the server-side LAN uses a subnet of 10.66.0.0/24and the VPN IP address pool uses 10.8.0.0/24 as cited in the server directive in the OpenVPN server configuration file.

First, you must advertise the 10.66.0.0/24 subnet to VPN clients as being accessible through the VPN. This can easily be done with the following server-side config file directive:

push "route 10.66.0.0 255.255.255.0"
Next, you must set up a route on the server-side LAN gateway to route the VPN client subnet (10.8.0.0/24) to the OpenVPN server (this is only necessary if the OpenVPN server and the LAN gateway are different machines).

Make sure that you've enabled IP and TUN/TAP forwarding on the OpenVPN server machine.

Including multiple machines on the server side when using a bridged VPN (dev tap)
One of the benefits of using ethernet bridging is that you get this for free without needing any additional configuration.

Including multiple machines on the client side when using a routed VPN (dev tun)
In a typical road-warrior or remote access scenario, the client machine connects to the VPN as a single machine. But suppose the client machine is a gateway for a local LAN (such as a home office), and you would like each machine on the client LAN to be able to route through the VPN.

For this example, we will assume that the client LAN is using the 192.168.4.0/24 subnet, and that the VPN client is using a certificate with a common name of client2. Our goal is to set up the VPN so that any machine on the client LAN can communicate with any machine on the server LAN through the VPN.

Before setup, there are some basic prerequisites which must be followed:

The client LAN subnet (192.168.4.0/24 in our example) must not be exported to the VPN by the server or any other client sites which are using the same subnet. Every subnet which is joined to the VPN via routing must be unique.
The client must have a unique Common Name in its certificate ("client2" in our example), and the duplicate-cn flag must not be used in the OpenVPN server configuration file.
First, make sure that IP and TUN/TAP forwarding is enabled on the client machine.

Next, we will deal with the necessary configuration changes on the server side. If the server configuration file does not currently reference a client configuration directory, add one now:

client-config-dir ccd
In the above directive, ccd should be the name of a directory which has been pre-created in the default directory where the OpenVPN server daemon runs. On Linux this tends to be /etc/openvpn and on Windows it is usually \Program Files\OpenVPN\config. When a new client connects to the OpenVPN server, the daemon will check this directory for a file which matches the common name of the connecting client. If a matching file is found, it will be read and processed for additional configuration file directives to be applied to the named client.

The next step is to create a file called client2 in the ccd directory. This file should contain the line:

iroute 192.168.4.0 255.255.255.0
This will tell the OpenVPN server that the 192.168.4.0/24 subnet should be routed to client2.

Next, add the following line to the main server config file (not the ccd/client2 file):

route 192.168.4.0 255.255.255.0
Why the redundant route and iroute statements, you might ask? The reason is that route controls the routing from the kernel to the OpenVPN server (via the TUN interface) while iroute controls the routing from the OpenVPN server to the remote clients. Both are necessary.

Next, ask yourself if you would like to allow network traffic between client2's subnet (192.168.4.0/24) and other clients of the OpenVPN server. If so, add the following to the server config file.

client-to-client
push "route 192.168.4.0 255.255.255.0"
This will cause the OpenVPN server to advertise client2's subnet to other connecting clients.

The last step, and one that is often forgotten, is to add a route to the server's LAN gateway which directs 192.168.4.0/24 to the OpenVPN server box (you won't need this if the OpenVPN server box is the gateway for the server LAN). Suppose you were missing this step and you tried to ping a machine (not the OpenVPN server itself) on the server LAN from 192.168.4.8? The outgoing ping would probably reach the machine, but then it wouldn't know how to route the ping reply, because it would have no idea how to reach 192.168.4.0/24. The rule of thumb to use is that when routing entire LANs through the VPN (when the VPN server is not the same machine as the LAN gateway), make sure that the gateway for the LAN routes all VPN subnets to the VPN server machine.

Similarly, if the client machine running OpenVPN is not also the gateway for the client LAN, then the gateway for the client LAN must have a route which directs all subnets which should be reachable through the VPN to the OpenVPN client machine.

==Referensi==

* https://openvpn.net/community-resources/expanding-the-scope-of-the-vpn-to-include-additional-machines-on-either-the-client-or-server-subnet/