OpenVPN: IPv4 routed LAN - Revision history

Onnowpurbo: /* Teori */

2020-03-31T03:31:39Z

Teori

← Older revision		Revision as of 03:31, 31 March 2020
Line 77:		Line 77:
	iroute		iroute

	ini diletakan dalam file2 di bawah folder		Dalam contoh ini, diletakan dalam file2 di bawah folder

	/etc/openvpn/ccd/		/etc/openvpn/ccd/

Onnowpurbo: /* Teori */

2020-03-31T03:10:35Z

Teori

← Older revision		Revision as of 03:10, 31 March 2020
Line 76:		Line 76:

	iroute		iroute

			ini diletakan dalam file2 di bawah folder

			/etc/openvpn/ccd/

	==Referensi==		==Referensi==

Onnowpurbo: /* Teori */

2020-03-31T03:09:41Z

Teori

← Older revision		Revision as of 03:09, 31 March 2020
Line 59:		Line 59:


	~~At this point~~, ~~some background on how~~ OpenVPN ~~works internally is in order.~~		Berikut ini, sedikit teori / latar belakang bagaimana OpenVPN bekerja.
	When OpenVPN receives a packet or frame on the tun/tap interface to forward, it encrypts it and encapsulates it into one or more UDP datagrams, which are then sent out to some remote (usually public) IP address where another VPN node will receive it on its public IP, decapsulate and decrypt them, and send them to the local tun/tap interface, where they will be finally seen by the OS. The process also works in the opposite direction of course.

	~~If the~~ IP ~~addresses involved are only those belonging to the~~ VPN~~, OpenVPN has no trouble to associate a certain~~ VPN IP ~~to the~~ public ~~IP address of a~~ remote ~~VPN peer (as long as the addresses were pushed by the server to the clients and not statically assigned)~~.		Saat OpenVPN menerima sebuah paket / frame pada interface tun/tap untuk di forward, maka OpenVPN akan meng-enkript paket tersebut dan meng-enkapsulasi-nya menjadi satu atau lebih UDP datagram, yang kemudian dikirim ke remote (biasanya public) IP address dari VPN node lain. VPN Node tersebut akan menerima di IP public-nya, meng-dekapsulasi dan dekript paket / frame tersebut, dan mengirimkan paket tersebut ke interface tun/tap lokal, dimana packet tersebut akan akhirnya berinteraksi dengan sistem operasi di komputer remote tersebut. Tentu saja proses ini juga berlaku untuk arah yang berlawanan.

	~~However, when non-~~VPN ~~packets are involved~~, OpenVPN needs more information. In our A-to-C example, when gwA receives the packet with src=192.168.1.1 and dst=192.168.3.1, the routing table sends it to the tun0 interface, and thus to OpenVPN. Now, how does OpenVPN know behind which remote peer ~~that destination IP is? That is a necessary piece of information it needs in order to know the destination IP to use for the encapsulating UDP packets~~.		Jika IP address yang terlibat disini hanya milik VPN saja, OpenVPN tidak akan memperoleh masalah untuk mengasosiasikan sebuah IP VPN ke IP public milik remote VPN peer (selama address ini di push oleh server ke client dan tidak secara statik dialokaikan).

	~~Similarly~~, ~~in the C~~-to-~~A direction~~, ~~when~~ gwA~~'s OpenVPN sees a packet with~~ src=192.168.3.1 ~~and~~ dst=192.168.1.1, ~~it needs to make sure that it knows how to reach the source address~~, ~~in order to send replies later~~. ~~So it's just a different aspect of the same problem~~.		Yang akan menjadi masalah, jika ada non-VPN paket yang terlibat, OpenVPN membutuhkan informasi lebih lanjut. Untuk kasus kita antara A-to-C, jika gwA menerima paket dengan src=192.168.1.1 dan dst=192.168.3.1, maka tabel routing akan mengirimkannya ke interface tun0, dan kemudian ke OpenVPN. Pertanyaannya, bagaimana OpenVPN bisa tahu destination IP berada di belakang remote peer yang mana? Informasi ini diperlukan agar OpenVPN dapat meng-enkapsulasi UDP Paket ke IP remote OpenVPN yang benar.

	~~Since there can be~~ (~~and there actually is~~) ~~more than one~~ peer, OpenVPN ~~needs to know which~~ network ~~is behind each~~ peer. ~~You might think (as I naively did) that it should be able to somehow infer that information from the routes in the~~ routing ~~table~~, ~~for example since~~ gwA ~~has this route in the routing table~~		Hal yang sama, untuk arah C-to-A, saat OpenVPN gwA melihat paket dengan src=192.168.3.1 dan dst=192.168.1.1, OpenVPN gwA membutuhkan informasi bagaimana untuk mencapai source address, agar nantinya dapat mengirim reply. Jadi ini masalah yang sama dengan diatas, hanya dari sudut pandang yang berbeda.

			Karena kemungkinan (dan sebenanrnya) bisa ada lebih dari satu peer, maka OpenVPN butuh tahu setiap network di belakang setiap peer. Kita kemungkinan akan berfikir, kita bisa menambahkan tabel routing, misalnya di gwA, sebagai,

	192.168.3.0/24 via 10.0.0.3 dev tun0		192.168.3.0/24 via 10.0.0.3 dev tun0

	~~it could assume that~~ 192.168.3.0/24 ~~is behind~~ 10.0.0.3, ~~and thus use~~ gwC's public IP ~~to send~~ encapsulated traffic ~~destined to~~ 192.168.3.0/24. ~~Well~~, ~~it seems that it doesn't work that way~~. ~~You have to explicitly tell~~ OpenVPN ~~which~~ network ~~is behind each~~ client. ~~This is where our iroute~~ directive ~~comes into play.~~		yang akan mengasumsikan bahwa 192.168.3.0/24 berada di belakang 10.0.0.3, dan akan menggunakan gwC public IP untuk mengirimkan encapsulated traffic yang ditujukan ke 192.168.3.0/24. Sayangnya, OpenVPN tidak bekerja seperti itu. Kita perlu secara explisit memberitahukan OpenVPN network mana dibelakang setiap client. Ini dilakukan menggunakan directive

			iroute

	==Referensi==		==Referensi==

Onnowpurbo: /* Pranala Menarik */

2020-03-31T01:17:58Z

Pranala Menarik

← Older revision		Revision as of 01:17, 31 March 2020
Line 81:		Line 81:
	==Pranala Menarik==		==Pranala Menarik==

	* [[OpenVPN]]		* [[OpenVPN: IPv4 /32 single client]]
			* [[OpenVPN: IPv4 /32 multi-client]]
			* [[OpenVPN: IPv4 routed LAN]]
			* [[OpenVPN: IPv4 routed 2 LAN]]
			* [[OpenVPN: IPv6 /128 single client]]
			* [[OpenVPN: IPv6 routed LAN]]
			* [[OpenVPN: IPv6 routed 2 LAN]]

			* [[IPv6: OpenVPN: Ubuntu roadwarrior]]
			* [[OpenVPN: Simple Server using Script]]
			* [[OpenVPN: Free VPN untuk Ubuntu]]
			* [[Instalasi OpenVPN]]
			* [[Instalasi OpenVPN Client di Linux]]
			* [[Capture Screen Proses Instalasi OpenVPN di Windows]]
			* [[Instalasi OpenVPN di Windows]]
			* [[WNDW: OpenVPN]]
			* [[OpenVPN: Instalasi di Ubuntu 16.04]]
			* [[OpenVPN: Instalasi di Ubuntu 18.04]]
			* [[OpenVPN: Briding dan Routing]]

Onnowpurbo: /* gwA */

2019-02-17T01:32:41Z

gwA

← Older revision		Revision as of 01:32, 17 February 2019
Line 23:		Line 23:
	ifconfig-push 10.0.0.2 255.255.255.0		ifconfig-push 10.0.0.2 255.255.255.0
	push "route 192.168.1.0 255.255.255.0 10.0.0.1"		push "route 192.168.1.0 255.255.255.0 10.0.0.1"
			iroute 192.168.2.0 255.255.255.0

	gwA # cat /etc/openvpn/ccd/gwC		gwA # cat /etc/openvpn/ccd/gwC
	ifconfig-push 10.0.0.3 255.255.255.0		ifconfig-push 10.0.0.3 255.255.255.0
	push "route 192.168.1.0 255.255.255.0 10.0.0.1"		push "route 192.168.1.0 255.255.255.0 10.0.0.1"
			iroute 192.168.3.0 255.255.255.0

	==gwB==		==gwB==

Onnowpurbo at 23:20, 16 February 2019

2019-02-16T23:20:43Z

← Older revision		Revision as of 23:20, 16 February 2019
Line 1:		Line 1:
	Sumber: https://backreference.org/2009/11/15/openvpn-and-iroute/		Sumber: https://backreference.org/2009/11/15/openvpn-and-iroute/

			[[File:Iroute.png\|center\|300px\|thumb]]

			==gwA==

			gwA # cat /etc/openvpn/server.conf
			# gwA
			local 172.20.0.1
			port 1194
			proto udp
			dev tun
			topology subnet
			mode server
			tls-server
			ifconfig 10.0.0.1 255.255.255.0
			route 192.168.2.0 255.255.255.0 10.0.0.2
			route 192.168.3.0 255.255.255.0 10.0.0.3
			client-config-dir ccd
			# snip rest of config

			gwA # cat /etc/openvpn/ccd/gwB
			ifconfig-push 10.0.0.2 255.255.255.0
			push "route 192.168.1.0 255.255.255.0 10.0.0.1"
			gwA # cat /etc/openvpn/ccd/gwC
			ifconfig-push 10.0.0.3 255.255.255.0
			push "route 192.168.1.0 255.255.255.0 10.0.0.1"


			==gwB==

			gwB # cat /etc/openvpn/client.conf
			# gwB
			remote 172.20.0.1 1194
			proto udp
			dev tun
			topology subnet
			# snip rest of config


			==gwC==

			gwC # cat /etc/openvpn/client.conf
			# gwC
			remote 172.20.0.1 1194
			proto udp
			dev tun
			topology subnet
			# snip rest of config

			==Cek==

			ping
			route

			==Teori==


			At this point, some background on how OpenVPN works internally is in order.
			When OpenVPN receives a packet or frame on the tun/tap interface to forward, it encrypts it and encapsulates it into one or more UDP datagrams, which are then sent out to some remote (usually public) IP address where another VPN node will receive it on its public IP, decapsulate and decrypt them, and send them to the local tun/tap interface, where they will be finally seen by the OS. The process also works in the opposite direction of course.

			If the IP addresses involved are only those belonging to the VPN, OpenVPN has no trouble to associate a certain VPN IP to the public IP address of a remote VPN peer (as long as the addresses were pushed by the server to the clients and not statically assigned).

			However, when non-VPN packets are involved, OpenVPN needs more information. In our A-to-C example, when gwA receives the packet with src=192.168.1.1 and dst=192.168.3.1, the routing table sends it to the tun0 interface, and thus to OpenVPN. Now, how does OpenVPN know behind which remote peer that destination IP is? That is a necessary piece of information it needs in order to know the destination IP to use for the encapsulating UDP packets.

			Similarly, in the C-to-A direction, when gwA's OpenVPN sees a packet with src=192.168.3.1 and dst=192.168.1.1, it needs to make sure that it knows how to reach the source address, in order to send replies later. So it's just a different aspect of the same problem.

			Since there can be (and there actually is) more than one peer, OpenVPN needs to know which network is behind each peer. You might think (as I naively did) that it should be able to somehow infer that information from the routes in the routing table, for example since gwA has this route in the routing table

			192.168.3.0/24 via 10.0.0.3 dev tun0

			it could assume that 192.168.3.0/24 is behind 10.0.0.3, and thus use gwC's public IP to send encapsulated traffic destined to 192.168.3.0/24. Well, it seems that it doesn't work that way. You have to explicitly tell OpenVPN which network is behind each client. This is where our iroute directive comes into play.

Onnowpurbo: Created page with "Sumber: https://backreference.org/2009/11/15/openvpn-and-iroute/ ==Referensi== * https://backreference.org/2009/11/15/openvpn-and-iroute/ ==Pranala Menarik== * OpenVPN"

2019-02-16T10:45:31Z

Created page with "Sumber: https://backreference.org/2009/11/15/openvpn-and-iroute/ ==Referensi== * https://backreference.org/2009/11/15/openvpn-and-iroute/ ==Pranala Menarik== * OpenVPN"

New page

Sumber: https://backreference.org/2009/11/15/openvpn-and-iroute/

==Referensi==

* https://backreference.org/2009/11/15/openvpn-and-iroute/

==Pranala Menarik==

* [[OpenVPN]]