Server atau klien: unit OpenVPN mana pada Pi dengan dua peran

Dua proses OpenVPN berjalan di sebuah Pi yang sekaligus menerima pengguna roaming dan menjangkau penyedia hulu, dan keduanya hampir tidak berbagi apa pun selain perangkat keras. Yang satu mendengarkan terowongan masuk sementara yang lain menghubungi keluar. Masing-masing membaca direktorinya sendiri, dan masing-masing punya mode kegagalannya sendiri. Memulai ulang unit yang salah adalah cara paling umum sebuah perbaikan klien justru mengguncang pendengar.

Cocokkan nama unit dengan direktori yang dimuatnya

Upstream 2.6 menyediakan dua unit templat, [email protected] dan [email protected]. Templat server dimulai di /etc/openvpn/server dan memuat %i.conf dari sana. Templat klien dimulai di /etc/openvpn/client. Instans bernama roaming dapat ada di kedua tempat sekaligus, sebagai server dan sebagai klien, dengan dua konfigurasi yang tidak saling terkait dan tanpa kaitan di antara keduanya selain string.

Tanyakan systemd alih-alih sistem berkas, karena pembuat paket menambahkan berkas tambahan yang dapat mengubah direktori kerja atau argumen yang diterima biner.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

Perintah pertama mencantumkan setiap unit yang dibuat, termasuk yang gagal dan tetap termuat. Perintah kedua mencetak berkas unit bersama setiap penimpaan. Perintah ketiga adalah cara tercepat melihat dua fakta yang menentukan pertanyaan: direktori tempat proses dimulai, dan jalur konfigurasi yang diberikan kepadanya.

Putuskan berdasarkan arah paket, bukan nama antarmuka

Instans server memiliki soket pendengar dan menerima koneksi. Transport terenkripsinya adalah masukan lokal dan keluaran lokal di Pi, sedangkan lalu lintas yang diteruskannya untuk pengguna mengikuti jalur penerusan dan menaati kumpulan aturan yang berbeda. Instans klien tidak memiliki pendengar dalam arti itu: ia menghubungi rekan, jadi transport terenkripsinya adalah keluaran lokal menuju lapisan bawah.

Perbedaan itu memberi tahu Anda ke mana sebuah aturan harus diletakkan. Aturan yang cocok dengan antarmuka di dalam rantai penerusan hanya mengizinkan lalu lintas yang sudah dipilih oleh perutean; aturan itu tidak pernah memilih rute. Ketika paket pengguna roaming keluar melalui jalur yang salah, rantai yang harus diperiksa adalah forward, bukan output.

Lihat soket sebelum berteori. Server yang terikat ke udp/1194 menunjukkan soket pendengar. Klien menunjukkan asosiasi ke alamat penyedia dan tidak ada yang mendengarkan sama sekali.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Rute default satu instans dapat menangkap balasan instans lain

redirect-gateway yang didorong oleh klien hulu memasang rute default yang bersaing dengan semua hal lain di mesin, termasuk balasan yang dikirim server kepada pengguna roaming. OpenVPN membuat pengecualian untuk alamat rekannya sendiri agar terowongan tetap terjangkau, tetapi pengecualian itu tidak mengatakan apa pun tentang ponsel di jaringan hotel.

Gejalanya biasanya asimetris. Jabat tangan selesai, klien melaporkan terhubung, dan lalu lintas mati setelah paket balasan pertama. Perutean kebijakan berbasis sumber, atau tanda paket yang dipasang pada instans server dengan --mark, menjaga kedua aliran tetap terpisah; tidak satu pun merupakan kumpulan aturan yang lengkap dengan sendirinya, dan keduanya memerlukan rute yang valid di tabel mana pun yang mereka pilih.

Uji keputusan lokal alih-alih keadaan terowongan, karena kernel memilih sumber dan antarmuka sebelum OpenVPN melihat paket.

ip route get 203.0.113.44
ip rule show

Mulai ulang satu peran dan buktikan yang lain selamat

Urutan penting ketika kedua peran bergantung pada lapisan bawah yang sama. Mulai ulang klien lebih dulu jika rute hulu harus ada sebelum lalu lintas pengguna dapat diteruskan, dan mulai ulang server lebih dulu ketika Anda hanya mengubah pendengarnya atau kolamnya. Bagaimanapun, konfirmasikan kedua unit sesudahnya, karena mulai ulang yang gagal dapat meninggalkan peran lain berjalan dengan keadaan basi.

Tuliskan kondisi berhenti sebelum perubahan: apakah hilangnya terowongan hulu memblokir pengguna roaming, atau kembali ke tautan atas milik Pi sendiri? DNS dan IPv6 juga memerlukan jawaban eksplisit, karena resolver yang didorong sering hidup lebih lama daripada rute yang membuatnya berguna.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Terima perubahan hanya ketika tiga hal berlaku sekaligus: koneksi masuk baru selesai, aplikasi yang diteruskan mencapai tujuannya melalui jalan keluar yang dimaksud, dan kedua proses masih melaporkan rekannya yang diharapkan. Jika salah satu dari tiga gagal, Anda mengubah instans yang salah atau rute yang salah, dan langkah berikutnya adalah membaca ulang unit alih-alih memulai ulang hal lain.