Верно ли, что торрент загружается через enp3s0 (eth0), даже если исходящий трафик ограничен VPN на tun0?
я изменил свои iptables в соответствии с ответом Musclehead здесь , чтобы мой трансмиссионный демон мог просто отправьте исходящий трафик на tun0 (который является VPN).
(Подсказка: мой eth0 называется enp3s0 .)
Теперь, если Я добавляю торрент в download и наблюдаю за трафиком с помощью sudo iptables -L -v , единственное увеличение числа связано с цепочкой INPUT с enp3s0 (это мой порт Ethernet). Цифры складываются со статусом, который я получаю от VPN.
Означает ли это, что я загружаю на свой исходный адрес WAN, а не через туннель?
Я думаю, что когда я добавлю торрент, информация о его загрузке будет быть отправлено с tun0 , и поэтому ответ должен вернуться в этом диапазоне IP.
Как вы можете видеть здесь, с двумя выходами, которые я сгенерировал с интервалом в несколько секунд, трафик увеличивается с 1356M до 2201M на устройстве enp3s0 .
$ sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
2417 172K f2b-sshd tcp -- any any anywhere anywhere multiport dports ssh
170K 17M ACCEPT all -- tun0 any anywhere anywhere
330K 1356M ACCEPT all -- enp3s0 any anywhere --THIS LINE anywhere
942 134K ACCEPT all -- lo any anywhere anywhere
...
Chain OUTPUT (policy ACCEPT 483K packets, 269M bytes)
pkts bytes target prot opt in out source destination
19 6545 ACCEPT tcp -- any enp3s0 anywhere 192.168.100.0/24 tcp spt:9091 owner GID match debian-transmission
0 0 ACCEPT udp -- any enp3s0 anywhere 192.168.100.0/24 udp spt:9091 owner GID match debian-transmission
229K 210M ACCEPT all -- any tun0 anywhere anywhere owner GID match debian-transmission
221 57168 ACCEPT all -- any lo anywhere anywhere owner GID match debian-transmission
92 5372 REJECT all -- any any anywhere anywhere owner GID match debian-transmission reject-with icmp-port-unreachable
...
Второй выход через несколько секунд:
$ sudo iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
2431 173K f2b-sshd tcp -- any any anywhere anywhere multiport dports ssh
170K 17M ACCEPT all -- tun0 any anywhere anywhere
384K 2201M ACCEPT all -- enp3s0 any anywhere --THIS LINE anywhere
942 134K ACCEPT all -- lo any anywhere anywhere
...
Chain OUTPUT (policy ACCEPT 536K packets, 272M bytes)
pkts bytes target prot opt in out source destination
19 6545 ACCEPT tcp -- any enp3s0 anywhere 192.168.100.0/24 tcp spt:9091 owner GID match debian-transmission
0 0 ACCEPT udp -- any enp3s0 anywhere 192.168.100.0/24 udp spt:9091 owner GID match debian-transmission
229K 210M ACCEPT all -- any tun0 anywhere anywhere owner GID match debian-transmission
221 57168 ACCEPT all -- any lo anywhere anywhere owner GID match debian-transmission
92 5372 REJECT all -- any any anywhere anywhere owner GID match debian-transmission reject-with icmp-port-unreachable
...
Я также добавлю свои выходные данные таблицы маршрутизации для лучшего понимания:
$ ip route show table local
broadcast 10.8.8.0 dev tun0 proto kernel scope link src 10.8.8.5
local 10.8.8.5 dev tun0 proto kernel scope host src 10.8.8.5
broadcast 10.8.8.255 dev tun0 proto kernel scope link src 10.8.8.5
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 192.168.100.0 dev enp3s0 proto kernel scope link src 192.168.100.91
local 192.168.100.91 dev enp3s0 proto kernel scope host src 192.168.100.91
broadcast 192.168.100.255 dev enp3s0 proto kernel scope link src 192.168.100.91
1 ответ
Я связался с ребятами из компании VPN, и они проанализировали следующий вывод. Они сказали, что оба IP-адреса (я их изменил) являются IP-адресами VPN, поэтому мой VPN не протекает, но подключен правильно. И он также передает некоторый трафик ssh, потому что я вошел в компьютер с ним.
Но они сочли странным, что этот трафик на tun0 не виден в цепочке iptable, которую я указал в своем вопросе. Увидеть ниже.
Что касается того факта, что трафик идет через enp3s0, это правильно, потому что трафик от tun0 перенаправляется (зашифровывается) на порт Ethernet.
$ sudo tcpdump -i enp3s0 not src 84.17.47.59
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:35:14.533573 IP 192.168.100.91.ssh > 192.168.100.210.59004: Flags [P.], seq 835793677:835793865, ack 3278619125, win 318, options [nop,nop,TS val 19307620 ecr 4023390051], length 188
10:35:14.534084 IP 192.168.100.91.47524 > 203.179.83.129.openvpn: UDP, length 164
10:35:14.534399 IP 206.189.83.129.openvpn > 192.168.100.91.47524: UDP, length 468
Кроме того, правила моего брандмауэра из ufw отсутствуют в цепочках INPUT, FORWARD и OUTPUT, а также в других ufw- конкретные цепочки. Например:
199 13931 ufw-after-output all -- any any anywhere anywhere
199 13931 ufw-after-logging-output all -- any any anywhere anywhere
199 13931 ufw-reject-output all -- any any anywhere anywhere
199 13931 ufw-track-output all -- any any anywhere anywhere
После того, как я удалил пакет и настройки, очистил все определенные цепочки из iptables, а затем настроил все с нуля, все заработало. Входящий трафик на tun0 теперь также виден.
Чтобы ответить на вопрос: Да, исходящий трафик в конечном итоге будет передан на eth после туннелирования в tun0. Оба значения должны суммироваться.