OpenVPN: alamat lokal versus alamat tunnel — dua soket berbeda

Klien menolak mulai dan mengeluh tidak dapat mengikat alamat lokal, dan perbaikan yang tampak jelas adalah mengarahkannya ke alamat tunnel yang diharapkannya. Itu tidak mungkin berhasil, dan alasannya perlu dipahami: sebelum tunnel ada tidak ada alamat di dalam, dan soket yang menghubungi server harus ada lebih dulu. Ada dua alamat berbeda yang terlibat, dan hanya satu di antaranya dapat dipilih secara lokal.

Kesalahan bind menyebut alamat lokal

Ketika OpenVPN melaporkan tidak dapat mengikat alamat lokal, yang dimaksud adalah soket transport: titik akhir UDP atau TCP yang membawa koneksi terenkripsi ke peer.

Direktif local yang eksplisit meminta daemon mengikat soket itu ke alamat lokal tertentu. Alamat itu harus ada di ruang nama jaringan tempat proses berjalan, dan harus dapat dialokasikan pada saat klien mulai.

Alamat publik yang diterjemahkan di router atau di tepi cloud bukanlah alamat lokal yang dapat diikat daemon, walaupun itulah alamat yang dilihat server. Perbedaan itu menjelaskan mengapa satu profil bekerja di rumah dan gagal pada instans cloud. Ini juga menjelaskan mengapa menambahkan alamat publik ke antarmuka loopback tidak membantu, karena transport akan berasal dari alamat yang tidak dapat dikirimi balasan oleh jaringan. Baca daftar antarmuka sebelum menyunting profil.

Apa yang sebenarnya dipilih local dan remote

remote menyebut peer yang akan dihubungi. local mengikat ujung dekat soket yang sama. nobind membiarkan sistem operasi memilih alamat lokal dan porta sekaligus, karena itulah klien di belakang router rumah biasanya berjalan tanpa kedua direktif itu.

Tidak ada satu pun dari kedua direktif itu yang berhubungan dengan alamat di dalam tunnel.

Di dalam kontainer atau ruang nama jaringan, aturan yang sama berlaku dengan batas yang lebih sempit: alamat host tidak ada di dalam, jadi baris local yang disalin dari konfigurasi host gagal karena alasan yang sama sekali berbeda dari alamat yang salah.

ip -brief address show
ip route get 203.0.113.10

Alamat dalam berasal dari server

Alamat di dalam tunnel dinegosiasikan atau ditetapkan setelah kanal kendali terbentuk. Dengan kumpulan dinamis server memutuskannya saat terhubung, dan dengan konfigurasi khusus klien alamat itu bisa tetap per identitas.

Menulis local dengan alamat dalam tidak meminta server mengalokasikan alamat itu. Dalam kasus terbaik bind gagal; dalam kasus terburuk klien menemukan alamat host tak terkait dengan nilai yang sama dan mulai memakainya untuk transport.

Antarmuka yang perlu dibaca juga berbeda. Parameter ifconfig dan konfigurasi kumpulan menjelaskan bagian dalam, sedangkan remote, local, proto, dan nobind menjelaskan bagian luar. Memisahkan kedua daftar menjelaskan hampir setiap contoh membingungkan yang akan Anda temukan di forum. Panduan OpenVPN 2.6 mendokumentasikannya di bagian terpisah justru karena alasan itu.

Jebakan: tunnel penuh yang menangkap transportnya sendiri

Setelah tunnel naik dan membawa rute default, paket yang menopangnya tidak boleh dirutekan ke dalamnya. Ini masalah perutekan, bukan pengalamatan, dan daemon menanganinya dengan memasang rute yang lebih spesifik ke alamat server sendiri melalui gateway semula.

Jika Anda memakukan transport ke alamat lokal tertentu lalu mengubah jalur yang dipakai alamat itu, koneksi luar bisa tersesat sementara bagian dalam tetap terkonfigurasi. Tunnel terus melaporkan terhubung karena bagian dalam baik-baik saja. Hanya transport yang rusak, dan itulah sebabnya log terbaca sebagai pertentangan.

Gejalanya lalu tampak seperti tunnel yang terhubung lalu membeku, atau yang menyambung ulang dalam lingkaran tanpa galat yang berguna. Periksa rute ke alamat peer sebelum memeriksa apa pun di dalam tunnel, dan pastikan alamat lokal yang Anda ikat masih milik antarmuka yang Anda harapkan.

Kebiasaan yang mencegah kebingungan

Baca setiap alamat dalam profil dan putuskan lapisan mana yang dimilikinya sebelum menyuntingnya.

Jika alamat itu menyebut ujung jauh transport atau mengikat ujung dekatnya, itu alamat luar dan harus ada sebelum mulai. Jika alamat itu menjelaskan apa yang terjadi di dalam tunnel, ia berasal dari server atau dari topologi, dan tidak ada direktif lokal yang dapat menggantikannya.

Tuliskan kedua daftar itu di catatan penyebaran di samping profil. Sesi pemecahan masalah berikutnya akan dimulai dari lapisan, bukan dari dugaan.