Cara menggunakan meninju lubang UDP untuk terowongan / sesi SSH

Saya ingin menggunakan Raspberry Pi di pondok akhir pekan saya. Raspberry Pi ada di sana untuk mencatat suhu dan mengirimkannya ke server jauh yang memiliki ip tetap, menyimpan data, dan menampilkannya di situs web sederhana.

Namun situasi mungkin muncul bahwa saya ingin mengubah sesuatu pada Raspberry Pi. Misalnya pembaruan sistem atau perubahan pada program yang mengirimkan data ke server atau apa pun.

Dengan pengaturan yang disarankan, saya tidak akan dapat terhubung ke Raspberry Pi dari luar LAN-nya.

CATATAN: Saya tidak ingin mengubah jaringan, dan router yang ada tidak memiliki kemampuan untuk penerusan port, dynDNS atau VPN.

Saya baru-baru ini membaca tentang lubang meninju UDP. Ide dasarnya adalah, bahwa klien mengirim Paket UDP ke alamat server yang dikenal (yaitu dengan IP publik atau dinDNS diaktifkan). Klien B yang ingin terhubung ke klien A meminta server untuk IP publik dan nomor Port klien A.

Kemudian dapat terhubung ke klien A secara langsung pada IP publik dan porta yang dinamis. Karena klien A pertama terhubung ke server pada port yang sekarang digunakan, NAT akan meneruskan paket ke klien A.

Saya harap saya merangkum ide dengan benar, lebih atau kurang ...

Ini kedengarannya bagus, tetapi masalahnya adalah, ini tidak dijamin untuk bekerja dengan koneksi TCP, karena router dapat "memahami" jabat tangan koneksi TCP dan jika tidak dibangun dengan benar, itu tidak akan meneruskan paket.

Jadi, bagaimana saya bisa membuka Sesi SSH dari klien B ke klien A, tanpa klien A duduk di belakang router dengan dynDNS, memperbaiki IP publik atau kemampuan untuk penerusan porta? Penggunaan server pusat dengan publik, memperbaiki IP atau nama domain mungkin sulit.

— Kristen
sumber

Anda memiliki perangkat internet yang mampu meninju lubang UDP tetapi tidak TCP? Dapatkan perangkat NAT yang lebih baik.

— cpt_fink

Saya tidak melakukan ssh dengan udp tetapi di sini ada tautannya zarb.org/~gc/html/udp-in-ssh-tunneling.html

— barlop

Saya tidak tahu tetapi saya bertanya kepada seorang guru ssh, mereka berkata ssh dapat meneruskan udp, tetapi hanya jika itu bertindak seperti vpn, dan ada saklar untuk itu, dia mengatakan itu -wtetapi dia mengatakan udp lebih dari tcp (mungkin dengan itu dia termasuk segala upaya untuk meneruskan udp dengan ssh), melibatkan masalah seperti latensi tinggi, dan pengiriman ulang barang yang tidak Anda inginkan lagi. Saya kira ini masih merupakan hal yang menarik untuk dicoba. Saya melihat vpn ini melalui ssh dan -w yang disebutkan di sini juga wiki.archlinux.org/index.php/VPN_over_SSH

— barlop

Saya ingin tahu mengapa Anda tidak ingin membuka port inbound? - ini tidak terdengar seperti skenario yang membutuhkan keamanan yang sangat luar biasa ... Atau, Anda bisa meminta klien A mempertahankan koneksi SSH keluar dengan port terbalik yang mengikat ke server yang dapat diakses oleh klien B. Dengan begitu Anda dapat terhubung melalui server perantara. Namun, pengaturan semacam ini rentan terhadap kegagalan sehingga sangat tidak diinginkan mengingat akses fisik yang terbatas untuk menyelesaikannya ketika terjadi kesalahan.

— kabadisha

Jawaban:

`pwnat`

"..Itu tidak sepele untuk memulai koneksi ke rekan di belakang NAT. "

"..almost semua implementasi NAT menolak untuk meneruskan lalu lintas masuk yang tidak sesuai dengan permintaan keluar yang cocok baru - baru ini. "

"..Perangkat pwnatini adalah implementasi GNU / Linux-only, implementasi mandiri dari NAT traversal otonom. Setelah menghubungi server di belakang NAT, ia membuat saluran dengan semantik TCP, menggunakan paket UDP. Mendukung kedua klien dan server di belakang NAT (jika salah satu NAT memungkinkan pesan ICMP [custom] palsu dikirim). Implementasi ini menargetkan pengguna akhir. "

  
penggunaan: ./pwnat <-s | -c> <args>

  -c mode klien
    <args>: [ip lokal] <port lokal> <proxy host> [proxy port (def: 2222)] <remote host> <port remote>

  -s mode server
    <args>: [ip lokal] [port proxy (def: 2222)] [[host yang diizinkan]: [port yang diizinkan] ...]

  -6 gunakan IPv6  
  -v tampilkan output debug (hingga 2)  
  -h tunjukkan bantuan dan keluar  

Contoh:  

    Sisi server memungkinkan siapa saja untuk mem-proxy:
      ./pwnat -s

    Klien yang ingin terhubung ke google.com:80:
      ./pwnat -c 8000 <pwnat.server.com> google.com 80
    Kemudian, ramban ke http: // localhost: 8000 untuk mengunjungi google!

"Ide kunci untuk memungkinkan server yang untuk belajar alamat IP klien adalah untuk server yang untuk secara berkala mengirim pesan ke, alamat IP yang dikenal tetap. Pendekatan paling sederhana menggunakan pesan REQUEST ICMP ECHO ke alamat IP yang tidak terisi, seperti 1.2.3.4 Karena 1.2.3.4 tidak dialokasikan, PERMINTAAN ICMP tidak akan dirutekan oleh router tanpa rute default. "

"Sebagai hasil dari pesan yang dikirim ke 1.2.3.4, NAT akan memungkinkan perutean balasan, sebagai tanggapan atas permintaan ini. Klien yang terhubung kemudian akan memalsukan balasan semacam itu. Secara khusus, klien akan mengirimkan pesan ICMP yang mengindikasikan TTL_EXPIRED. pesan dapat secara sah dikirimkan oleh router Internet mana pun dan alamat pengirim tidak diharapkan cocok dengan IP target server. "

" Server mendengarkan balasan ICMP (palsu) dan setelah diterima, memulai koneksi ke IP pengirim yang ditentukan dalam balasan ICMP. Jika klien menggunakan alamat IP yang dapat dialihkan secara global, ini sepenuhnya tidak bermasalah dan TCP atau UDP dapat digunakan untuk membuat koneksi dua arah jika klien mendengarkan pada port yang disepakati sebelumnya. "

"(Dalam kasus di mana tidak ada pelabuhan yang disepakati sebelumnya, nomor port dalam banyak kasus dapat dikomunikasikan sebagai bagian dari muatan ICMP ECHO RESPONSE)."

Sumber: http://samy.pl/pwnat.pdf
https://github.com/samyk/pwnat

— suara-suara
sumber

pwnat hampir tidak berfungsi untuk koneksi localhost ke localhost. Saya dapat mengirim dan menerima beberapa paket, tetapi untuk membangun koneksi yang kuat itu tidak terlalu berguna.

— Scott

@ Esc Yah, ini hack yang menarik, tapi itu benar-benar hanya bukti konsep berdasarkan penyalahgunaan dan penyalahgunaan protokol jaringan seperti ICMP. Saya tidak akan bergantung pada itu. Ini sudah tua dan tidak terawat dan saya tidak akan merekomendasikan menggunakannya. Saya bahkan tidak akan menyebutkannya jika pertanyaannya tidak secara spesifik menetapkan holepunching UDP. Jika Anda ingin dapat diandalkan, sambungkan terowongan VPN.

— Suara

Saya tidak mengeluh, tetapi saya berpikir bahwa "solusi ini bukan untuk digunakan dalam lingkungan produksi" adalah informasi yang berguna bagi siapa pun yang datang ke sini mencari solusi yang berpotensi stabil.

— Scott

@ Esc Bukan, tidak untuk digunakan dalam lingkungan ini dan itu. Banyak produk eksklusif menggunakan teknik ini. Lagi pula, ada cukup informasi di sini bagi orang untuk membuat keputusan sendiri. Saya tidak merekomendasikannya. Tapi saya menggunakan terowongan VPN. Di sisi lain, beberapa jaringan menyaring lalu lintas VPN, jadi Anda harus mengambil beberapa kasus berdasarkan kasus. Apakah Anda memerlukan bantuan untuk melewati router NAT?

— Suara

Saya punya solusi yang saat ini bisa diterapkan menggunakan terowongan ssh terbalik untuk menghubungkan dua mesin NAT'd. Namun, ini membutuhkan mesin "perantara" yang memiliki IP statis atau untuk siapa saya dapat mengkonfigurasi port forwarding pada router. Ini akan memungkinkan saya untuk memotong perantara itu. Baiklah.

— Scott

Berikut adalah beberapa solusi:

Anda dapat mengatur Raspberry Pi Anda untuk terhubung kembali ke server OpenVPN dan Anda akan memiliki akses ke sana sepanjang waktu.

Anda dapat melihat PageKite. Periksa https://pagekite.net/wiki/Howto/SshOverPageKite/

— Obay
sumber

Bagaimana ini berhubungan dengan "meninju lubang UDP" ?

— Suara

Ini adalah solusi yang agak kotor tapi mudah, tetapi bagaimana dengan menggunakan netcat? Pada Raspberry Pi Anda dapat membuat skrip yang mengulang perintah:

nc <public_ip> <port1> | sh | nc <public_ip> <port2>

Di host lokal Anda, lakukan:

nc -l <port1>

Dan:

nc -l <port2>

Anda bisa mengetikkan perintah di instance pertama dan melihat respons di yang kedua.

— Paul
sumber

Bagaimana ini berhubungan dengan "meninju lubang UDP" ?

— Suara

"Bagaimana ini melintasi NAT?"

— ZEE