Mari pertimbangkan skenario berikut:
- VPS Anda memiliki antarmuka ethernet tunggal, yang dikonfigurasi dengan alamat IP 4.3.2.1/24;
- VPS Anda dapat mengakses Internet melalui gateway default 4.3.2.254
- VPS Anda telah tidak belum diaktifkan koneksi OpenVPN; karenanya tidak ada antarmuka tun aktif
Dalam skenario seperti itu, dari mesin Anda (misalkan mesin Anda 9.8.7.6/24 dengan def-gw 9.8.7.254), Anda dapat berhasil membuat koneksi SSH ke 4.3.2.1. Oleh karena itu kedua host 4.3.2.1 dan 9.8.7.6 dapat berhasil mencapai satu sama lain.
Sekarang, dengan koneksi SSH dibuat, mari kita anggap:
- Anda meluncurkan koneksi OpenVPN dari VPS 4.3.2.1 Anda;
- dengan demikian, antarmuka tun0 baru akan dikonfigurasikan secara dinamis (misalkan akan diberi IP 10.10.10.2, dengan PTP 10.10.10.1).
Di panggung ini:
JIKA tidak ada rute yang akan didorong dari server OpenVPN jauh ke VPS lokal Anda, maka tidak ada yang akan berubah dalam hal perutean, dan koneksi SSH Anda akan bertahan tanpa masalah sama sekali. Dalam hal ini, satu-satunya lalu lintas yang melintasi VPN adalah yang diarahkan ke OpenVPN Server jarak jauh (10.10.10.1);
JIKA server OpenVPN jarak jauh akan mendorong kembali beberapa rute, dan terutama jika VPS default-gateway akan diganti dengan 10.10.10.1 (titik akhir OpenVPN jarak jauh), MAKA Anda mengalami masalah. Dalam hal ini Anda melakukan tunneling SEMUA lalu lintas IP keluar (dengan pengecualian OpenVPN sendiri) di dalam VPN.
Dalam kasus kedua ini (mengganti def-gw tepat setelah membuat koneksi VPN), koneksi SSH Anda sebelumnya akan "hang", karena perutean asimetris:
- Lalu lintas dari mesin Anda (9.8.7.6) ke VPS (4.3.2.1) akan mengalir melalui jalur yang sebelumnya, tidak pernah diubah;
- Lalu lintas dari VPS (4.3.2.1) ke mesin Anda (9.8.7.6):
- tanpa VPN (karenanya, pada awalnya) dialihkan melalui gateway 4.3.2.254;
- setelah pembentukan tautan VPN, dengan penggantian def-gw terkait, dialihkan melalui VPN (10.10.10.1).
Dengan kata lain: segera setelah tautan VPN dibuat, rute kembali Anda dari VPS ke mesin Anda akan berubah dan ... ini bukan hal yang baik (beberapa perangkat jaringan, di sepanjang jalur pengembalian, mungkin mengenali asimetris seperti itu) path dan cukup jatuhkan paket).
Selain itu, kemungkinan besar bahwa server OpenVPN remote Anda bertindak sebagai kotak-NAT: semua lalu lintas yang berasal dari VPN akan disatukan dengan alamat IP publik Server OpenVPN jarak jauh. Jika ini benar, maka tidak ada lagi ... "tidak baik", tapi pasti "buruk", seperti untuk koneksi SSH Anda: kembalikan lalu lintas, selain untuk kembali ke rute yang berbeda, akan kembali ke mesin Anda dengan IP sumber yang berbeda (salah satu antarmuka publik dari server VPN).
Bagaimana cara mengatasi masalah ini?
Cukup mudah, memang.
Cukup menginstruksikan server VPS Anda untuk tidak merutekan lalu lintas ke mesin Anda di sepanjang VPN, tetapi, sebaliknya, mengandalkan rute sebelumnya . Seharusnya semudah menambahkan, sebelum memulai OpenVPN:
route add -host 9.8.7.6 gw 4.3.2.254
dimana:
- 9.8.7.6 adalah alamat IP publik mesin Anda
- 4.3.2.254 adalah gateway default asli VPS Anda.
PS: dengan memberikan pertanyaan yang jauh lebih detail, Anda akan mendapat jawaban yang jauh lebih cepat :-)