Difference between revisions of "OpenVPN: IPv4 routed LAN"
Onnowpurbo (talk | contribs) |
Onnowpurbo (talk | contribs) (→Teori) |
||
(2 intermediate revisions by the same user not shown) | |||
Line 59: | Line 59: | ||
− | + | Berikut ini, sedikit teori / latar belakang bagaimana OpenVPN bekerja. | |
− | |||
− | + | 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. | |
− | + | 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). | |
− | + | 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. | |
− | + | 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 | ||
− | + | 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 | ||
+ | |||
+ | Dalam contoh ini, diletakan dalam file2 di bawah folder | ||
+ | /etc/openvpn/ccd/ | ||
==Referensi== | ==Referensi== |
Latest revision as of 10:31, 31 March 2020
Sumber: https://backreference.org/2009/11/15/openvpn-and-iroute/
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" iroute 192.168.2.0 255.255.255.0
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" iroute 192.168.3.0 255.255.255.0
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
Berikut ini, sedikit teori / latar belakang bagaimana OpenVPN bekerja.
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.
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).
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.
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
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
Dalam contoh ini, diletakan dalam file2 di bawah folder
/etc/openvpn/ccd/
Referensi
Pranala Menarik
- 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