Почему просачиваются локальные IP адреса на внешний интерфейс через NAT в Linux с KVM?

Question

[Dango]

Не могу побороть проблему – просачиваются локальные IP адреса через NAT на внешний интерфейс за что время от времени ловлю бан внешнего IP адреса от провайдера (Hetzner) использую Debian + Proxmox и виртуализацию KVM

Просачиваются пакеты с флагом FIN и RST лог tcpdump от провайдера.

tcpdump, присланный провайдером:

09:42:16.976198 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.2312 > 192.198.93.78.80: Flags [F.], seq 
3579355710, ack 2348566885, win 65101, length 0
09:42:17.076330 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.2271 > 65.75.156.119.80: Flags [F.], seq 
3329167346, ack 2138564996, win 65408, length 0
09:42:17.177311 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.2096 > 149.47.143.131.80: Flags [F.], seq 
833600034, ack 1463451994, win 65205, length 0
09:42:17.378092 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.2160 > 193.234.222.240.80: Flags [F.], seq 
380954537, ack 1918089133, win 65530, length 0
09:42:17.478724 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.2522 > 199.231.188.243.80: Flags [F.], seq 
2524482819, ack 2992113059, win 64726, length 0
09:42:17.482664 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.2376 > 118.139.177.199.80: Flags [F.], seq 
3912490494, ack 3173571000, win 65464, length 0
09:42:17.512824 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.3493 > 192.126.137.25.8800: Flags [R], seq 
714854646, win 0, length 0
09:42:17.512847 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.3493 > 192.126.137.25.8800: Flags [R], seq 
714854646, win 0, length 0

в sysctl.conf включено только
net.ipv4.ip_forward=1

Настройка сети:

# Loopback device:
auto lo
iface lo inet loopback


# device: eth0
auto  eth0
iface eth0 inet static
  address   xx.xx.xx.42
  broadcast xx.xx.xx.63
  netmask   255.255.255.224
  gateway   xx.xx.xx.33
  # default route to access subnet
  up route add -net xx.xx.xx.32 netmask 255.255.255.224 gw xx.xx.xx.33 eth0


auto vmbr0
iface vmbr0 inet static
    address  10.0.0.254
    netmask  255.255.255.0
    bridge_ports none
    bridge_stp off
    bridge_fd 0

Правило ната:

iptables -t nat -A POSTROUTING -s '10.0.0.0/24' -j SNAT --to-source xx.xx.xx.42

пробовал и макарадинг - проблема не ушла :(

Версии софта:

cat /etc/debian_version
7.2

uname -a
Linux 1.server.com 2.6.32-25-pve #1 SMP Tue Oct 1 09:17:16 CEST 2013 x86_64 GNU/Linux

pveversion -v
proxmox-ve-2.6.32: 3.1-113 (running kernel: 2.6.32-25-pve)
pve-manager: 3.1-17 (running version: 3.1-17/eb90521d)
pve-kernel-2.6.32-25-pve: 2.6.32-113
lvm2: 2.02.98-pve4
clvm: 2.02.98-pve4
corosync-pve: 1.4.5-1
openais-pve: 1.1.4-3
libqb0: 0.11.1-2
redhat-cluster-pve: 3.2.0-2
resource-agents-pve: 3.9.2-4
fence-agents-pve: 4.0.0-2
pve-cluster: 3.0-7
qemu-server: 3.1-5
pve-firmware: 1.0-23
libpve-common-perl: 3.0-6
libpve-access-control: 3.0-6
libpve-storage-perl: 3.0-13
pve-libspice-server1: 0.12.4-2
vncterm: 1.1-4
vzctl: 4.0-1pve3
vzprocps: 2.0.11-2
vzquota: 3.1-2
pve-qemu-kvm: 1.4-17
ksm-control-daemon: 1.1-1
glusterfs-client: 3.4.0-2

Comments

[ptQa]

iptables-save покажите

Answer 1

[Melkij]

На правах тычка пальцем в небо, пробовали натить весь трафик?

/sbin/iptables -t nat -a POSTROUTING –o eth0 -j MASQUERADE

Answer 2

[Dango]

пробовал, не помогает
пакеты продолжают сыпать
заметил что пакеты сыпятся когда их виртуалки генерируют достаточно много, от 1k через nat
возможно переполняется какая то очередь и/или железка не успевает их обрабатывать?

Answer 3

[Ilya Evseev]

У вас мост vmbr0 используется, через него во внешнюю сеть может идти всё, что угодно.
brctl show покажите.
Если окажется, что в мост подключены и eth0, и интерфейсы виртуалок, то для блокирования надо использовать ebtables.

Ещё не помешает нормально настроить на 10.0.0.7 шлюз, чтобы она не пыталась обращаться к внешним узлам напрямую.

Answer 4

[Dango]

У вас мост vmbr0 используется, через него во внешнюю сеть может идти всё, что угодно.
brctl show покажите.

там же есть пример конфига
bridge_ports none

если бы в бридж входил eth0 я бы мог его еще подозревать, а так физически они изолированны

Ещё не помешает нормально настроить на 10.0.0.7 шлюз, чтобы она не пыталась обращаться к внешним узлам напрямую.

на виртуалке следующие настройки

ip: 10.0.0.7
mask 255.255.255.0
gw: 10.0.0.254
ns: 10.0.0.254

поясните что вы подразумеваете под "нормально" ?

Answer 5

[Mikhail Vasilyev]

Опять же, на уровне пальца в небо -
iptables -t nat -L POSTROUTING
ничего неожиданного не кажет?
iptables -t raw -I OUTPUT -o eth0 -s 10.0.0.0/8 -j DROP