Tunnel penuh OpenVPN memutus sesi SSH Anda: perbaiki jalur balasan

Mengaktifkan klien OpenVPN tunnel penuh di mesin yang Anda jangkau lewat SSH dapat memutus sesi dalam satu detik, dan mesin itu tidak melakukan kesalahan apa pun. Tunnel tidak mengubah bagaimana paket mencapai server; tunnel mengubah bagaimana balasan keluar. Begitu rute default menunjuk ke tun0, balasan ke klien SSH Anda masuk ke jaringan penyedia, yang tidak punya rute kembali ke alamat Anda. Koneksi menggantung, percobaan berikutnya habis waktu, dan daemon tetap mendengarkan di port 22 sepanjang waktu.

Baca tabel routing sebelum Anda membaca log VPN. Log akan mengatakan tunnel sudah naik, dan itu benar. Pertanyaannya adalah antarmuka mana yang menerima setiap balasan, dan itu pencarian per paket pada tabel yang baru saja ditulis ulang oleh tunnel.

Mengapa balasan keluar lewat pintu yang salah

Paket masuk tetap tiba di antarmuka fisik, karena klien VPN tidak dapat mengubah bagaimana internet mencapai alamat publik server Anda. Balasan adalah keputusan terpisah: untuk setiap paket, kernel mencari tujuan, dan setelah --redirect-gateway entri default berkata tunnel. Exit penyedia melihat tujuan yang tidak dilayaninya dan menjatuhkan paket itu.

Perlindungan OpenVPN sendiri menutupi tepat satu tujuan. Panduan 2.6 menjelaskan --redirect-gateway sebagai rangkaian: ia menambahkan rute host untuk peer VPN melalui gateway yang dipakai sebelum tunnel, supaya lalu lintas terenkripsi tidak bisa berputar kembali ke dirinya sendiri, lalu menggantikan rute default. Rute host itu hanya untuk peer. Klien SSH Anda hanyalah alamat internet lain dan tidak mendapat pengecualian.

Satu kesalahan prefiks layak disingkirkan lebih awal. ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 tanpa panjang cocok dengan alamat tunggal 0.0.0.0, bukan internet; harus 0.0.0.0/0. Dan jika pengambilan rute default memutus transport tunnel itu sendiri, tambahkan titik akhir sebagai rute host melalui antarmuka fisik, dengan alamat asli penyedia.

Sematkan alamat klien SSH Anda untuk perbaikan segera

Perbaikan tercepat adalah rute host untuk alamat klien Anda melalui gateway yang dipakai server sebelum tunnel ada. Dari sisi Anda, temukan alamat yang akan dilihat server, lalu baca tabel server agar tahu gateway lama:

curl -s https://ifconfig.co
ip route

Di server, tambahkan pengecualian sebelum klien mulai. Alamat di sini adalah placeholder; bentuknya yang penting:

sudo ip route add 80.128.240.55 via 192.168.178.1

Ini perbaikan yang dipakai pada kasus yang dilaporkan, dan langsung bekerja. Ini juga rapuh dalam dua cara yang bisa diprediksi: rute hilang saat reboot, dan menjadi salah begitu ISP memberi Anda alamat lain. Perlakukan sebagai tindakan darurat dan jadikan tahan lama dengan sengaja, lewat unit jaringan atau kait dispatcher, atau terima bahwa ini sementara dan catat jalur pemulihannya.

Cegah klien mengambil rute default

Opsi yang lebih bersih adalah mencegah tunnel mengganti rute default sama sekali. route-nopull, dipakai dengan --client atau --pull, menerima opsi yang didorong kecuali rute, block-outside-dns, dan opsi bergaya DHCP seperti server DNS, jadi Anda hanya menambahkan prefiks yang diperlukan. Alat yang lebih sempit adalah filter tarik, yang membuang satu direktif bermasalah dan menyisakan sisanya:

route-nopull
pull-filter ignore "redirect-gateway"

Gunakan salah satu, bukan keduanya, dan pahami apa yang berubah. Tanpa rute default melalui tunnel, server tidak lagi menjelajah internet lewat penyedia; ia hanya mencapai apa yang Anda rutekan secara eksplisit. Jika tunnel penuh adalah seluruh maksud pengaturan ini, ini tombol yang salah dan rute host di atas adalah yang benar.

Bagi jalur balik menurut sumber atau koneksi

Ketika alamat masuk stabil, aturan sumber menjaga balasan tetap lokal tanpa menyentuh rute tunnel itu sendiri. Beri alamat antarmuka fisik tabelnya sendiri berisi prefiks LAN dan default fisik, lalu pilih tabel itu untuk lalu lintas yang berasal darinya:

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

Ini bekerja karena balasan untuk koneksi SSH masuk berasal dari alamat tempat klien terhubung. Kasus yang dilaporkan di mana setiap layanan masuk harus tetap bekerja memakai bentuk yang persis ini. Ketika alamat masuk berubah-ubah atau jalurnya dinamis, tandai koneksinya: pasang tanda conntrack pada paket pertama yang datang dari antarmuka fisik, salin ke paket balasan di OUTPUT, dan rutekan paket bertanda melalui tabel yang menunjuk ke gateway fisik.

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

Jaga tanda koneksi, tanda firewall, dan nomor tabel tetap berbeda saat menguji. Memakai ulang satu nomor untuk dua peran menghasilkan aturan yang tampak benar dan mengenai paket yang salah. Entri default tabel juga membutuhkan via bersama gateway LAN pada tautan Ethernet biasa; dev eth0 telanjang hanya bekerja bila antarmuka titik-ke-titik atau lompatan berikutnya diselesaikan dengan cara lain. Host Jessie yang dilaporkan kebetulan berada di tautan tempat bentuk telanjang bekerja, dan itu bukan aturan distribusi untuk disalin.

Verifikasi tanpa mengunci diri Anda keluar

Jangan menguji dengan memutus koneksi. Biarkan sesi pertama terbuka, bawa tunnel naik, dan tanyakan kepada kernel jalur mana yang akan diambil alamat Anda sendiri:

ip route get 80.128.240.55

Jawabannya harus menyebut antarmuka fisik dan gateway lama, bukan tunnel. Lalu buka koneksi SSH kedua; itulah uji yang sebenarnya, karena sesi lama bisa bertahan pada status yang tidak dapat direproduksi koneksi baru. Jika yang kedua menggantung sementara yang pertama masih menjawab, aturan itu tidak pernah cocok dengan lalu lintas yang penting, dan tanda atau alamat sumber adalah tempat mencarinya.

Sediakan konsol out-of-band sepanjang latihan. Server yang satu-satunya jalur akses adalah tunnel yang baru saja Anda rusak tidak bisa diperbaiki lewat tunnel itu, dan pengembalian lebih mudah bila Anda sudah mencatat nomor tabel dan prefiks yang Anda tambahkan.