LINUX.ORG.RU
Форум — Admin  

Message parser reports malformed message packet при попытке порезолвить любой домен

 , , ,


0

1

Есть две машины, у которых вот такая сетевая конфигурация

Windows desktop -> Outline -> Linux server -> OpenVPN

То есть сервер используется в качестве шлюза для openvpn. Если его выключить, то сеть работает отлично, днс тоже. Если же включить, то на виндоузе-клиенте происходит следующее (да, я установил cygwin):

> dig ya.ru
;; Warning: Message parser reports malformed message packet.
;; Truncated, retrying in TCP mode.
;; communications error to 8.8.8.8#53: end of file
;; communications error to 8.8.8.8#53: end of file

Вот так выглядят правила файрволла

-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURN
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-forward -i tun0 -o eth0 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 51820 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 22 -m comment --comment "\'dapp_OpenSSH\'" -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 443 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 8080 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 20057 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 62722 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 62722 -j ACCEPT
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
-A ufw-user-output -o tun0 -j ACCEPT

Конфиг openvpn


client
dev tun
proto udp
remote xxx nnn
auth-user-pass /etc/openvpn/login.conf
remote-cert-tls server
nobind
redirect-gateway def1
<ca>
-----BEGIN CERTIFICATE-----
xxx
-----END CERTIFICATE-----
</ca>

Что я делаю не так?

← journald. Запись на диск только критически важной информации
«Could not get status from wpa_supplicant» →

Судя по вашему описанию и конфигурациям, проблема может быть связана с тем, как маршруты и DNS-запросы обрабатываются при подключении OpenVPN. Когда OpenVPN включен, Windows перестает правильно разрешать DNS-запросы, что может быть связано с неправильной конфигурацией маршрутов или брандмауэра на сервере.

Возможные причины и решения:

  1. Маршрутизация DNS-запросов через OpenVPN:

    • Проблема: Ваша конфигурация OpenVPN включает опцию redirect-gateway def1, которая перенаправляет весь трафик через VPN. Если DNS-сервер, указанный на клиенте, не доступен через VPN, это может вызвать ошибки DNS-запросов.
    • Решение: Проверьте, какой DNS-сервер используется на клиенте (Windows). Если это публичный DNS (например, 8.8.8.8), попробуйте заменить его на DNS-сервер, доступный через VPN (например, локальный DNS-сервер в сети OpenVPN).

    Для этого можно добавить в конфигурацию OpenVPN следующие строки:

    dhcp-option DNS <IP-адрес вашего DNS-сервера через VPN>

  2. MTU (Maximum Transmission Unit):

    • Проблема: Неправильное значение MTU может приводить к фрагментации пакетов, что вызывает проблемы при передаче DNS-запросов (особенно UDP).
    • Решение: Попробуйте настроить MTU на клиенте OpenVPN, добавив в конфигурацию клиента следующие строки:
    tun-mtu 1400
mssfix 1360

  3. UFW (Uncomplicated Firewall) на сервере:

    • Проблема: Возможна блокировка исходящих UDP-пакетов через OpenVPN-интерфейс tun0.
    • Решение: Проверьте настройки UFW и убедитесь, что трафик DNS разрешен через интерфейс tun0. Можно добавить правило для разрешения всех исходящих пакетов через tun0:
    sudo ufw allow out on tun0
sudo ufw allow in on tun0

  4. OpenVPN nobind опция:

    • Проблема: Опция nobind может иногда вызывать проблемы с привязкой сокетов на клиентской машине.
    • Решение: Попробуйте убрать эту опцию из конфигурации клиента, чтобы OpenVPN использовал стандартный порт для исходящих соединений.

  5. Проверка DNS через TCP:

    • Проблема: Если DNS-запросы через UDP блокируются или не проходят, dig автоматически переходит на TCP. Если на сервере или между клиентом и сервером блокируется DNS-трафик по TCP, это также может вызвать проблемы.
    • Решение: Проверьте, не блокируется ли DNS-трафик по TCP на брандмауэре. Для этого добавьте правило на сервере, разрешающее трафик на TCP-порт 53.

  6. Диагностика:

    • Запустите tcpdump на сервере, чтобы проверить, проходят ли DNS-запросы и ответы через tun0.
    sudo tcpdump -i tun0 port 53

Если проблема не решится после применения данных рекомендаций, можно попробовать отключить UFW на сервере временно и протестировать подключение, чтобы точно локализовать проблему.

unclestephen
()
← journald. Запись на диск только критически важной информации
Admin
«Could not get status from wpa_supplicant» →