Проблема передачи файлов Netcat

1944
squircle

У меня есть два пользовательских сценария, которые я только что написал, чтобы облегчить передачу файлов между моим VPS и моим домашним сервером. Они оба написаны в Баше (короткий и сладкий): Для того,

чтобы отправить:

#!/bin/bash  SENDFILE=$1 PORT=$2 HOST='<my house>' HOSTIP=`host $HOST | grep "has address" | cut --delimiter=" " -f 4`  echo Transferring file \"$SENDFILE\" to $HOST \($HOSTIP\).  tar -c "$SENDFILE" | pv -c -N tar -i 0.5 | lzma -z -c -6 | pv -c -N lzma -i 0.5 | nc -q 1 $HOSTIP $PORT  echo Done. 


Получить:

#!/bin/bash  SERVER='<myserver>' SERVERIP=`host $SERVER | grep "has address" | cut --delimiter=" " -f 4` PORT=$1  echo Receiving file from $SERVER \($SERVERIP\) on port $PORT.  nc -l $PORT | pv -c -N netcat -i 0.5 | lzma -d -c | pv -c -N lzma -i 0.5 | tar -xf -  echo Done. 

Проблема в том, что в течение очень быстрой секунды я вижу, что что-то вспыхивает по линиям "Connection Refused"(прежде чем pvперезаписывает это), и ни один файл никогда не передается. Порт пересылается через мой маршрутизатор, и Nmap подтверждает это:

~$ sudo nmap -sU -PN -p55515 -v <my house>  Starting Nmap 5.00 ( http://nmap.org ) at 2010-04-21 18:10 EDT NSE: Loaded 0 scripts for scanning. Initiating Parallel DNS resolution of 1 host. at 18:10 Completed Parallel DNS resolution of 1 host. at 18:10, 0.00s elapsed Initiating UDP Scan at 18:10 Scanning 74.13.25.94 [1 port] Completed UDP Scan at 18:10, 2.02s elapsed (1 total ports) Host 74.13.25.94 is up. Interesting ports on 74.13.25.94: PORT STATE SERVICE 55515/udp open|filtered unknown  Read data files from: /usr/share/nmap Nmap done: 1 IP address (1 host up) scanned in 2.08 seconds Raw packets sent: 2 (56B) | Rcvd: 5 (260B) 

Кроме того, запуск netcat обычно тоже не работает:

squircle@summit:~$ netcat <my house> 55515 <my house> [<my IP>] 55515 (?) : Connection refused 

Обе коробки - Ubuntu Karmic (9.10). Получатель не имеет брандмауэра, и исходящий трафик через этот порт разрешен отправителю. Я понятия не имею, что решать дальше. Есть идеи?

PS: не стесняйтесь переместить это в SO / SF, если вы чувствуете, что это будет соответствовать лучше там.

1

1 ответ на вопрос

1
user23307
HOSTIP=`host $HOST | grep "has address" | cut --delimiter=" " -f 4` SERVERIP=`host $SERVER | grep "has address" | cut --delimiter=" " -f 4` 

Я понятия не имею, что вы думаете, что это делает, но вы должны удалить эти строки и просто использовать $ HOST и $ SERVER напрямую.

Проблема в том, что в течение очень короткой секунды я вижу что-то вспыхивающее по линии «Соединение отказано» (до того как pv перезаписывает его), и ни один файл никогда не передается. Порт пересылается через мой маршрутизатор, и nmap подтверждает это: ~ $ sudo nmap -sU -PN -p55515 -v ​​[...] СЕРВИС ПОРТОВ СОСТОЯНИЯ 55515 / udp открыт | отфильтрован неизвестно

Вы сказали это сделать сканирование UDP. Почему ты это сделал? Вы не используете netcat в режиме udp, и это даже не имеет смысла для передачи файлов.

Кроме того, запуск netcat обычно тоже не работает: squircle @ summit: ~ $ netcat 55515 [] 55515 (?): Соединение отказано

Вы неправильно перенаправляете порт.

Во всяком случае, весь этот сценарий несовершенен с самого начала. Просто используйте scp или rsync. Если вы настаиваете на использовании lzma, передайте tar + lzma через ssh. Использование netcat в этой ситуации абсолютно ничего не покупает.

Agreed... why make things more complicated than they already are. SCP, rsync or plain 'ole FTP are all better solutions than netcat in this situation. heavyd 14 лет назад 0
@justin: спасибо за отзыв; для меня у SCP было слишком много накладных расходов (учитывая то, что я запускаю это на VPS, а шифрование замедляет весь процесс), а наличие постоянно работающего демона FTPD - боль (на любой машине). squircle 14 лет назад 0
@justin: You're correct. My DD-WRT install wasn't forwarding TCP properly and was instead forwarding only UDP. The scripts work now. The `host $SERVER | grep "has address" | cut --delimiter=" " -f 4` just retrieves the IP of the host/server (quick & dirty) so netcat doesn't complain about a DNS name mismatch. Thanks for the suggestion. squircle 14 лет назад 0
scp may have been slow, but it most definitely had nothing to do with the encryption, and everything to do with the scp protocol being horrible inefficient. Again, netcat is buying you absolutely nothing other than being more complicated and less secure. Just use tar over ssh. user23307 14 лет назад 0