Это известная проблема в Debian и даже не характерная для Pi. Проблема восходит к тому времени, когда Debian перешел с системы init
на systemd
.
Зависимости между nfs-kernel-server и rpcbind определены неправильно. Debian/Raspbian по-прежнему запускает старые сценарии init.d.
Самым простым выходом для меня было вставить
start)
sleep 30 # this line is to be inserted!
export_files="/etc/export"
в /etc/init.d/nfs-kernel-server
. Это было в строке № 63 в моей системе.
Подсказка исходила от https://discourse.osmc.tv/t/nfs-kernel-server-wont-start-on-boot/5936/7.
У меня была проблема с Beagleboneblack, и оператор сна решил ее для меня.
У меня работает. Обратите внимание, что шифрование и дешифрование связаны на том основании, что отправка шифрует, а получение расшифровывает. (Вы не можете использовать cryptcat
для отправки зашифрованного файла с целью его расшифровки.)
Вы можете проверить, что ваш зашифрованный исходный файл содержит правдоподобные данные (, т. е. не -нулевую длину ), и с помощью tshark
или эквивалентной проверки, что данные действительно передаются по сети.
Сначала создайте зашифрованный файл
Мы начинаем прослушивание в Системе 2 до того, как передаем сообщение в Систему 1.
Система 2
nc -vv -l -p 1337 >message.enc
hex message.enc
0000 14 fd 25 da c3 5e 36 81 b2 7b e7 b0 13 4b b5 8b ..%..^6..{...K..
0010 cc 13 4c 60 bd 54 1e e2 5b 01 7f ac bc 93 27 6b ..L`.T.. [.....'k
0020 c3 a3 90 30 44 76 e1 61 f5 42 2d 04 f2 13 eb d4 ...0Dv.a.B-.....
0030 9c d9 9c 75 95 10 b2 55 42 bf 0d cb cb ...u...U B....
Система 1
date | cryptcat -vv -k p@ssword -w 1 system2 1337
Теперь повторно отправьте зашифрованный файл
Как и прежде, мы начинаем слушать приемник перед передачей сообщения
Система 1
cryptcat -vv -k p@ssword -l -p 1337 # → Thu 25 Oct 15:07:24 BST 2018
Система 2
nc -vv -w 1 system1 1337 <message.enc
Альтернативная рекомендация
В общих чертах, первоначальный автор netcat
заявил, что они предпочитают использовать его исключительно как сетевой инструмент, а шифрование будет добавляться с использованием внешних инструментов.При таком подходе можно было бы использовать mcrypt
и построить пару подобных цепочек инструментов:
generate_data | mcrypt -z | nc...
... nc -l | mcrypt -d -z | produce_data
Преимущество здесь в том, что возможна автономная расшифровка и не требуется использование nc
... cryptcat -l
между двумя серверами. Это также отделяет направление передачи от подразумеваемого шифрования или дешифрования сообщения.