Назад | Перейти на главную страницу

Маршрутизация интернет-трафика через VPN-туннель

Я относительно новичок в этой теме, поэтому не возражайте, если я задам простые (или глупые) вопросы. У меня есть Raspberry Pi 3B, я установил и настроил на нем сервер OpenVPN. Поэтому я следовал этому руководству сообщества openvpn: https://openvpn.net/community-resources/how-to/ Я использую компьютер Windows для подключения к этому серверу, который отлично работает. Я попытался настроить сервер так, чтобы мой интернет-трафик IPv4 проходил через туннель. Проблема в том, что во время установления соединения с VPN-сервером веб-сайты IPv4 вообще не загружаются. Кроме того, трафик IPv6 по-прежнему проходит, так что веб-сайты IPv6 загружаются как обычно. Пожалуйста, найдите конфигурацию сервера, конфигурацию клиента, наборы правил iptables и таблицу IP-маршрутизации. В дополнение к этому я настроил NAT в соответствии с руководством сообщества с помощью команды

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Так что проблема в конечном итоге заключается в правильной маршрутизации. Заранее всем спасибо за помощь!

Привет, Патрик

P.S .: 192.168.2.1 - это IP-адрес маршрутизатора W-Lan, к которому мой Pi подключен через Ethernet.

Конфигурация сервера

port 1194
proto udp
dev tun
ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/server.crt
key /etc/openvpn/server/server.key
dh /etc/openvpn/server/dh.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt
keepalive 10 120
tls-auth /etc/openvpn/server/ta.key 0 
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 3
push "redirect-gateway local def1"
push "dhcp-options DNS 10.8.0.1"

Конфигурация клиента

client
dev tun
proto udp
remote 192.168.2.129 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
verb 3
redirect-gateway local def1

Правила IPv4

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -s 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p icmp -m state --state NEW -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth0 -p udp -m state --state NEW,ESTABLISHED -m udp --dport 1194 -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 1194 -j ACCEPT
-A INPUT -i eth0 -p udp -m state --state ESTABLISHED -m udp --sport 53 -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED -m tcp --sport 80 -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED -m tcp --sport 443 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -m limit --limit 3/min -j LOG --log-prefix "iptables_INPUT_denied: "
-A INPUT -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m limit --limit 3/min -j LOG --log-prefix "iptables_FORWARD_denied: "
-A FORWARD -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state ESTABLISHED -m tcp --sport 22 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m state --state ESTABLISHED -m udp --sport 1194 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state ESTABLISHED -m tcp --sport 1194 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m state --state NEW,ESTABLISHED -m udp --dport 53 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 80 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 443 -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT
-A OUTPUT -m limit --limit 3/min -j LOG --log-prefix "iptables_OUTPUT_denied: "
-A OUTPUT -j REJECT --reject-with icmp-port-unreachable
COMMIT

Правила IPv6

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -j REJECT --reject-with icmp6-port-unreachable
-A FORWARD -j REJECT --reject-with icmp6-port-unreachable
-A OUTPUT -j REJECT --reject-with icmp6-port-unreachable
COMMIT

Таблица IP-маршрутизации

Target       Router            Genmask             Flags     MSS Window irtt Iface
0.0.0.0      192.168.2.1       0.0.0.0             UG          0 0            0   eth0
10.8.0.0     10.8.0.2          255.255.255.0       UG          0 0            0   tun0
10.8.0.0.2    0.0.0.0          255.255.255.225     UH          0 0            0   tun0
192.168.2.1   0.0.0.0          255.255.255.0       U           0 0            0   eth0

Похоже, что конфигурация push-маршрутизатора подходит для клиента, и ваша машина с Windows знает об этом и может найти VPN-сервер на 10.8.0.1 в качестве маршрутизатора.

И что ваш пинг достигает google.com и 8.8.8.8, но вопрос в том, почему он не возвращается?

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max 
-1 10.8.0.1 3.431ms 3.021ms 6.034ms 
-2 * * * 
......
-7 8.8.8.8 14.281ms 15.043ms 13.892ms

Я предполагаю, что основная причина заключается в том, что маскарад в iptables маскирует исходный IPv6 с вашего компьютера Windows с помощью IPv6 вашего Rasberry Pi, и эти веб-сайты отказываются отвечать на любой адрес IPv6.

Дальнейшая диагностика пакета, отправленного с вашей машины Pi, полезна, вы можете использовать ip addr или ifconfig чтобы проверить [имя сетевой карты], начинающееся с «eth» и адрес после «inet» (ipv4) и раздела «inet6» (ipv6). И вы можете проверить реальный трафик с вашего Pi, пока вы пингуетесь от клиента Windows.

tcpdump icmp -nn -i [netcard's name] -v

И если вы обнаружите, что исходящий трафик получает адрес источника ipv6 вашего Pi, действительно, это причина. Чтобы исправить это, вы должны заменить предложение маскарада (удалить его), явно указав SNAT (изменение IP-адреса источника) на его адрес ipv4:

iptables -t nat -A POSTROUTING -j SNAT -to [Pi's ipv4 address]

Проблема может быть в клиенте Windows 10. По умолчанию метрика интерфейса как для физического сетевого адаптера, так и для виртуального сетевого адаптера VPN имеет значение «Автоматически». Вам необходимо снять флажок «Автоматически» и ввести значение 50 для физического адаптера и 25 для виртуального адаптера VPN. Затем откройте командную строку с помощью «Запуск от имени администратора» и введите команду ipconfig /flushdns.

Вы безоговорочно отклоняете трафик в прямой цепочке ваших iptables.

Если это действительно то, что вы хотите, вероятно, следует сделать следующее:

-N WHATEVER
-A WHATEVER -j LOG --log-prefix "iptables_FORWARD_denied: "
-A WHATEVER -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -m limit --limit 3/min -g WHATEVER

Чтобы вы не отвергали безоговорочно. Я понятия не имею, разумный ли предел / что вы намереваетесь.

Также обратите внимание, что даже если это не то, что вы хотите, и вы отказались от всего этого, вам необходимо убедиться, что переадресация IP не только разрешена (в iptables) включена (с sysctl).

P.S. Не уверен, как избежать «утечки IPv6». Однако это может быть системной проблемой (т. Е. Не проблемой OpenVPN).

Таблица IP-маршрутизации с вашего компьютера с Windows для клиента? Я прекрасно понимаю, почему они рекомендуют "def1". Для меня ваш вопрос довольно прост, ваш клиент Windows и ваш VPN-сервер находятся на 192.168.2.0/24 gw 192.168.2.1, и вам было бы лучше установить gw по умолчанию в качестве виртуального IP-адреса вашего vpn-сервера внутри туннеля, проверьте

ip addr

или просто добавьте журнал /var/ovpn.log в свою конфигурацию и проверьте его настоящий IP. и, во-вторых, установите 192.168.2.1 в качестве gw для сети 192.168.2.0/24. Как только вы настроите эту таблицу маршрутизации, ваш компьютер Windows обнаружит, что 192.168.2.1 для доступа к вашему VPN-серверу, а также любой другой трафик за пределами 192.168.2.0/ 24 переходит на виртуальный IP-адрес этого сервера для маршрутизации.