Я отлаживаю соединение OpenVPN site-to-site с использованием UDP в netcat.
Я могу заставить пакеты течь в одном направлении (хост A-> хост B), но не в обратном.
root@hosta:~# nc 10.0.3.2 1234 -u
root@hostb:~# nc -l 1234 -u
Странно то, что при запуске tcpdump на хосте A я действительно вижу UDP-пакет, поступающий с хоста B:
root@hosta:~# tcpdump port 1234
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:36:04.695423 IP hosta.46603 > 10.0.3.2.1234: UDP, length 4
17:36:06.484233 IP 10.0.3.2.1234 > hosta.46603: UDP, length 4
Однако netcat вообще ничего не выводит. я пробовал strace на nc, а из розетки даже ничего не получается.
Что еще я могу сделать, чтобы это диагностировать?
Если бы были даны только команды, это было бы легко! Netcat по умолчанию использует TCP без -u для UDP. Пока nc -lp 1234 -u слушает UDP-соединения на порту 1234, nc 10.0.3.2 1234 вместо этого пытается открыть TCP-соединение.
Предлагаю добавить -v -v к вашему Netcat на обоих концах, так как в конце вы получите статистику по отправке / rcvd. Добавьте эту информацию, а также исправьте команды, которые вы использовали, чтобы мы могли знать, что вы правильно выполнили условия отладки.
Также используйте tcpdump port 1234 -XX чтобы увидеть, что внутри этих пакетов в HEX и ASCII.
Однако на основе вывода tcpdump port 1234 у вас, вероятно, все еще были правильные команды, но давайте немного поиграем с этой ошибкой, чтобы увидеть, как мы можем это узнать:
Поскольку у вас есть UDP-пакеты
IP hosta.46603 > 10.0.3.2.1234: UDP, length 4
IP 10.0.3.2.1234 > hosta.46603: UDP, length 4
вместо TCP-пакетов вроде
IP hosta.46603 > 10.0.3.2.1234: Flags [S], seq 1384271454, win 14600, options [mss 1460,sackOK,TS val 1969077197 ecr 0,nop,wscale 3], length 0
IP 10.0.3.2.1234 > hosta.46603: Flags [R.], seq 0, ack 1384271455, win 0, length 0
Допустим, у вас было наоборот:
root@hosta:~# nc 10.0.3.2 1234 -u
root@hostb:~# nc -lp 1234
Но в этом случае вы бы увидели только первое
IP hosta.46603 > 10.0.3.2.1234: UDP, length 4
и в другую сторону не было бы UDP-пакетов!
Затем, если вы случайно использовали такой же nc <IP> 1234 -u на обоих концах у вас были бы обе линии, но порты не были бы одинаковыми, а что-то вроде:
IP hosta.46603 > 10.0.3.2.1234: UDP, length 4
IP 10.0.3.2.73644 > hosta.1234: UDP, length 4
Кроме того, в моем жестко запрограммированном заголовке IPv4 я ошибся контрольной суммой, поэтому на принимающей стороне netcat проигнорировал пакет UDP, хотя tpcdump и wirehark сообщили об этом. tcpdump отметил неправильную контрольную сумму, wirehark проигнорировал ее
Ответ может быть похож на ответ на этот вопрос: Переадресованные пакеты видны tcpdump, но не принимаются приложением
HostA находится в другой сети, чем hostB? Возвращается ли hostB к hostA (есть ли у него маршрут к hostA? Если нет, net.ipv4.conf.*.rp_filter отключен?
Решение, если hostB не имеет маршрута к hostA, - добавить маршрут или отключить rp_filter (фильтр обратного пути).