Sambungkan kembali terowongan TCP secara otomatis

9

Saya memiliki koneksi jaringan yang tidak dapat diandalkan antara dua mesin: kadang-kadang koneksi TCP aktif turun karena alasan di luar kendali saya. Saya ingin membuat koneksi TCP yang andal antara kedua mesin.

Jika jaringan itu dapat diandalkan, saya hanya akan berjalan ssh -L 1234:localhost:1234 remotehost, dengan server mendengarkan pada port 1234 remotehost, dan mengarahkan klien di localhost:1234. Tetapi jika koneksi ssh mati, maka koneksi akan diteruskan. Bagaimana saya dapat mengatur untuk secara otomatis memulihkan koneksi antara klien dan server?

Non-solusi:

Ini bukan untuk aplikasi interaktif, jadi layar tidak berlaku.
Ini bukan hanya tentang menghubungkan kembali terowongan SSH secara otomatis, " autossh . Saya ingin terus menggunakan koneksi TCP tunneled yang sama, bukan memulai yang baru.
Pada prinsipnya, VPN akan melakukan trik. Tetapi tampaknya berlebihan ketika saya hanya ingin satu koneksi TCP, dan saya ingin solusi yang berfungsi bahkan jika saya tidak memiliki izin root di kedua sisi.

Saya memiliki memori yang redup dari sebuah program yang disebut rocksmelakukan hal itu, tetapi tampaknya telah jatuh dari permukaan web. Saya sebagian besar tertarik pada Linux di kedua sisi (meskipun saya berharap sebuah program pada tingkat ini akan portabel untuk kesatuan lainnya), tetapi jika Anda mengetahui sebuah program yang bekerja antara QNX dan VMS, semuanya lebih baik.

— Gilles 'SANGAT berhenti menjadi jahat'
sumber

Gilles, apakah Anda menggunakan tcp keepalives dengan koneksi ssh Anda? Jika tidak, coba ini dulu ... beberapa implementasi waktu koneksi NAT keluar dengan cepat

— Mike Pennington

@ Mike: Terima kasih atas tipnya. Saya tidak memiliki kebutuhan mendesak, tetapi saya telah menghadapi kedua situasi di mana beberapa rute perantara datang dan pergi (jadi TCP keepalives lebih berbahaya daripada yang baik) dan situasi di mana NAT kelebihan beban dan menjatuhkan saya (sehingga TCP keepalives mungkin membantu). TCP keepalives tidak masalah untuk aliran kontinu (mis. Scp), bukan? Dalam hal apa pun saya ingin menjaga hal ini tetap umum: lain kali saya dihadapkan dengan jaringan yang rapuh dengan rasa apa pun, apa yang bisa saya lakukan?

— Gilles 'SANGAT berhenti menjadi jahat'

Gilles, solusinya berbeda untuk aliran konstan seperti scp. Saya merespons dengan keepalives berdasarkan contoh port-forwarding Anda. Re: downstream hop yang rapuh, tidak banyak yang dapat Anda lakukan, selain membuat sesi ssh dengan keepalives yang lebih toleran (yaitu membiarkan lebih banyak drop keepalives dengan ServerAliveInterval > 0dan ServerAliveCountMax > 3). NAT membutuhkan interval keepalives yang lebih rendah. Masalah utama adalah untuk mengidentifikasi apa masalahnya dan menyesuaikannya. Masukkan opsi .ssh/configsehingga mereka selalu ada untuk Anda

— Mike Pennington

@ Mike: Salah satu kasus penggunaan saya termasuk klien mendapatkan IP-nya dari NAT yang kelebihan beban daripada menjatuhkan koneksi aktif secara acak (pikirkan lebih banyak P2P daripada yang seharusnya). Setelah beberapa detik, klien berhasil menyambung kembali tetapi mungkin mendapatkan alamat IP yang berbeda. Tidak ada cara koneksi TCP akan bertahan dalam kasus itu. Rocks berupaya, tetapi saya lebih suka sesuatu yang dikompilasi di luar kotak pada sistem saat ini.

— Gilles 'SANGAT berhenti menjadi jahat'

dalam hal NAT memberi Anda IP baru, tidak banyak yang dapat Anda lakukan selain memperbaiki NAT atau berharap untuk rocksimplementasi lain ... meskipun ini jelas merupakan kludge nyata

— Mike Pennington

5

Apakah Sockets ( Rocks ) tua yang tidak terawat itu yang Anda cari?

— Hangin dengan putus asa
sumber

1

Terima kasih, Rocks memang yang saya ingat. Tentu saja saya lebih suka sesuatu yang dipertahankan.

— Gilles 'SANGAT berhenti menjadi jahat'

@ Gilles'SO-stopbeingevil 'Tidak hanya itu tidak terawat, tetapi tampaknya telah menjatuhkan wajah internet sepenuhnya!

— Michael

1

Satu-satunya protokol standar yang saya ketahui dengan kemampuan ini adalah MPTCP . Ini transparan untuk lapisan aplikasi, jadi SSH di atas MPTCP seharusnya berfungsi. Itu dapat menjalankan koneksi TCP yang mendasari melalui jalur yang berbeda dengan IP yang berbeda, jadi pada prinsipnya itu dapat digunakan untuk memigrasi koneksi SSH Anda masuk dan keluar dari koneksi VPN tergantung pada apakah koneksi VPN aktif.

Saya tidak tahu banyak tentang kematangan implementasi MPTCP, tetapi desain protokol terlihat cukup kuat.

Seharusnya melindungi koneksi SSH Anda agar tidak hilang karena konektivitas jaringan yang rapuh. Itu tidak akan melindungi Anda dari mitm yang ingin memutuskan koneksi SSH Anda. Sebuah mitm masih dapat menyuntikkan data yang rusak, yang SSH akan mendeteksi dan memutuskan koneksi.

MPTCP seperti metode menghubungkan kembali dibangun ke dalam protokol SSH akan menjadi metode yang saya bayangkan menjaga koneksi tetap hidup untuk waktu yang paling lama mungkin. Tapi saya tidak berpikir fitur seperti itu telah dirancang untuk protokol SSH.

— kasperd
sumber

0

Anda dapat menggunakan daemontoolsuntuk menjaga port ssh maju; itu tidak akan membuat program tergantung pada koneksi yang hidup saat sedang down (mungkin karena ssh memutuskan port lokal akan mulai menolak koneksi mereka), tetapi ini adalah permulaan.

Saya menduga ada beberapa iptablestrik, seperti menyebabkan port ke paket DROP segera setelah ssh forward hilang, sehingga program yang terhubung hanya tahu bahwa paket-paket menghilang, tidak ditolak. Saya baru belajar daemontoolssendiri (lagi) jadi saya tidak yakin apakah Anda dapat menjalankan skrip khusus ketika layanan mati, tetapi saya menduga Anda bisa.

— Gordon Morehouse
sumber

-2

TCP melakukan ini secara otomatis. Anda hanya perlu menonaktifkan atau melemahkan hacking pembersihan praktis yang biasa digunakan untuk membunuh koneksi TCP yang hampir mati. Nonaktifkan TCP keepalive untuk koneksi Anda, dan sangat meningkatkan batas untuk transmisi ulang berlebihan. Di Linux, misalnya, tulis sejumlah besar /proc/sys/net/ipv4/tcp_retries2.

Namun, dalam jaringan modern firewall inspeksi paket stateful cenderung melupakan koneksi TCP yang gagal bertukar paket secara teratur, sehingga mungkin hujan di parade Anda.

— aecolley
sumber

1

Memang benar bahwa TCP dapat menangani situasi, selama setiap titik akhir memiliki alamat IP statis dan tidak ada middlebox stateful. Pertanyaannya menyebutkan reasons beyond my control, yang saya baca sebagai IP dinamis atau middlebox stateful. Dalam skenario seperti itu TCP keepalive dapat membantu sedikit. Tetapi tidak masalah bagaimana Anda mengkonfigurasi TCP keepalive, itu tidak akan cukup untuk menjaga koneksi tetap hidup ketika middlebox kehilangan status karena sedang direstart.

— kasperd

@kasperd saya setuju. Namun, sia-sia untuk mencoba membuat koneksi TCP tetap terbuka dalam kasus tersebut. Karena itu, saya berasumsi si penanya tidak menghadapi tantangan-tantangan khusus itu.

— aecolley

Tidak sia-sia jika Anda mengontrol kedua titik akhir dan dapat memutakhirkannya ke tumpukan dengan dukungan MPTCP. Selain itu solusi lapisan aplikasi dapat diimplementasikan di atas TCP tanpa memerlukan MPTCP.

— kasperd