Вопросы Теги

Почему исходный IP-адрес не такой, как я думаю?

Я заметил при настройке VPN на моем сервере, что исходный IP-адрес всех исходящих пакетов всегда является публичным IP-адресом сервера. Но, согласно моему пониманию таблицы маршрутизации, это должен быть IP-адрес VPN. Также, если я использую ping -I 10.8.0.1 10.8.0.42 , это снова публичный IP-адрес моего сервера. Что мне здесь не хватает?

Это результат выполнения команды tcpdump -n -i enp3s0 dst 213.225.3.191 при выполнении проверки связи с ping -I 10.8.0.1 213.225.3.191 

17:34:36.285695 IP 5.9.142.112 > 213.225.3.191: ICMP echo request, id 10747, seq 34, length 64

Это результат tcpdump -n -i tun0 при выполнении проверки связи с ping -I 10.8.0.1 10.8.0.42 

17:43:45.152792 IP 5.9.142.112 > 10.8.0.42: ICMP echo request, id 10834, seq 1, length 64

Вывод ip route 

default via 5.9.142.97 dev enp3s0 proto static 
5.9.142.97 dev enp3s0 proto kernel scope link src 5.9.142.112 
10.8.0.0/30 via 10.8.0.2 dev tun0 
10.8.0.0/24 via 10.8.0.2 dev tun0 
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1

Вывод route 

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         static.97.142.9 0.0.0.0         UG    0      0        0 enp3s0
static.97.142.9 0.0.0.0         255.255.255.255 UH    0      0        0 enp3s0
10.8.0.0        10.8.0.2        255.255.255.252 UG    0      0        0 tun0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0

Вывод iptables -L -v -n -t nat 

Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 584K packets, 39M bytes)
 pkts bytes target     prot opt in     out     source               destination         
    4   336 MASQUERADE  all  --  *      enp3s0  10.0.0.0/8           0.0.0.0/0           
    0     0 MASQUERADE  all  --  *      enp3s0  10.0.0.0/8           0.0.0.0/0           
  285 18732 SNAT       all  --  *      *       10.0.0.0/8           0.0.0.0/0            to:5.9.142.112
    0     0 MASQUERADE  all  --  *      enp3s0  10.0.0.0/8           0.0.0.0/0           
    0     0 MASQUERADE  all  --  *      tun0    0.0.0.0/0            0.0.0.0/0           
    0     0 MASQUERADE  all  --  *      tun0    10.0.0.0/8           0.0.0.0/0           
    0     0 MASQUERADE  all  --  *      tun0    0.0.0.0/0            0.0.0.0/0           
    0     0 SNAT       all  --  *      *       0.0.0.0/0            10.8.0.42            to:10.8.0.1

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
0
задан 3 October 2019 в 20:13
1 ответ

Чтобы полностью понять поток пакетов в Linux iptables , вам понадобится эта диаграмма или что-то подобное для справки. На диаграмме ping находится в блоке «локальный процесс» на уровне приложения.

С вашей текущей таблицей маршрутизации система будет «думать» только о трафике, адресованном 10.8.0.0/24. маршрутизируется на интерфейс туннеля VPN; все остальное должно выходить через enp3s0 без прохождения через VPN-туннель.

Когда вы запускаете ping -I 10.8.0.1 213.225.3.191 , IP-адрес назначения не входит в число 10.8 .0.0 / 24, поэтому будет использоваться enp3s0 . Но исходящий маршрут проходит через шлюз 5.9.142.97, и запись маршрута, используемая для достижения этого шлюза, включает src 5.9.142.112 , определяя адрес источника, который будет использоваться.

И если это не изменит исходный IP-адрес, то первое правило MASQUERADE в таблице постмаршрутизации iptables изменится. 

4    336 MASQUERADE  all  --  *      enp3s0  10.0.0.0/8           0.0.0.0/0

Правило соответствует для всех пакетов, исходящих из интерфейса enp3s0 (в соответствии с решением о маршрутизации) с исходным IP-адресом в диапазоне 10.0.0.0/8, а 10.8.0.1 соответствует этому диапазону. И поскольку это правило MASQUERADE, оно меняет исходный IP-адрес исходящего пакета ...на IP-адрес сетевого интерфейса, из которого исходит пакет. Первое совпадение побеждает, поэтому этот пакет выполняется с таблицей постмаршрутизации и выходит из системы через enp3s0 .

Результат будет точно соответствовать тому, что вы видите: 

17:34:36.285695 IP 5.9.142.112 > 213.225.3.191: ICMP echo request, id 10747, seq 34, length 64

При запуске ping -I 10.8.0.1 10.8.0.42 , это действительный пункт назначения для tun0 , и адрес источника также действителен для него. Решение о маршрутизации выполнено.

В таблице постмаршрутизации NAT iptables / netfilter первые два правила ограничены совпадением для трафика, исходящего через enp3s0 , поэтому они не будут применяться. Но затем исходящий пакет попадает под это правило SNAT: 

285 18732 SNAT       all  --  *      *       10.0.0.0/8           0.0.0.0/0            to:5.9.142.112

Любой протокол, проверьте. В правиле не указан интерфейс, поэтому оно применяется к tun0 . Проверьте. Исходный адрес в пределах 10.0.0.0/8, проверьте. Адрес назначения что-нибудь, проверьте. Это матч. Это правило SNAT, поэтому оно изменяет IP-адрес S ource. И он меняет исходный IP на 5.9.142.112 . Возможно, это не то, что вы хотели, но это то, что гласит правило.

Первое совпадение побеждает, поэтому пакет теперь выполнен с таблицей постмаршрутизации: дальнейшие записи не будут обрабатываться для этого пакета. А поскольку таблица постмаршрутизации NAT является последней таблицей на исходящем пути, пакет выйдет из системы, как и сейчас.

Результат точно соответствует этому исходящему пакету на tun0 : 

17:43:45.152792 IP 5.9.142.112 > 10.8.0.42: ICMP echo request, id 10834, seq 1, length 64

Если вы Если вы планируете пропускать весь ваш интернет-трафик через VPN, ваша таблица маршрутизации должна иметь:

  • a 5.9.142.97 dev enp3s0 proto kernel scope link src 5.9.142.112 маршрут для вашего физического сетевого интерфейса. Он у вас уже есть, так как он будет сгенерирован автоматически при настройке физического сетевого интерфейса.
  • a / 32 (или genmask 255.255.255.255) запись через ваш enp3s0 шлюз 5.9.142.97 на общедоступный IP-адрес удаленной конечной точки VPN-туннеля (который не является 10.8.0.2). Это позволяет пакетам, инкапсулированным в VPN, проходить через ваш реальный сетевой интерфейс и достигать удаленной конечной точки VPN, даже если вы указываете маршрут шлюза по умолчанию через интерфейс VPN. В противном случае исходящий трафик VPN будет повторно инкапсулироваться снова и снова, создавая петлю маршрутизации, которая не позволяет трафику VPN фактически попасть в удаленную конечную точку VPN.
  • запись для самого туннеля VPN: 10.8.0.2 dev Ссылка на область видимости ядра tun0 proto src 10.8.0.1 . Это, вероятно, также будет автоматически сгенерировано при настройке интерфейса tun0 .
  • запись шлюза по умолчанию через 10.8.0.2, указывающая на любой трафик, для которого не определена конкретная маршрутизация (то есть в основном все, что еще не является VPN -инкапсулированный трафик, идущий к удаленной конечной точке VPN) в туннель VPN.
  • и ничего больше. Запись шлюза по умолчанию будет выполнять работу 10.8.0.0/30 через записи 10.8.0.2 и 10.8.0.0/24 через записи 10.8.0.2 .

Если ваша система не является выступая в качестве VPN-шлюза для других систем, вам могут вообще не понадобиться записи в таблице NAT POSTROUTING.

1
ответ дан 4 December 2019 в 15:36

Теги

Похожие вопросы