[решено]OpenVPN и маскарадинг

Привет всем!

Помогите разобраться. А именно:
1. Есть некий шлюз (универсальный) в центральном оффисе. Держит, в том числе и openVPN.
2. Есть несколько удаленных площадок, к которой ходим в рамках этого openVPN.
Симптомы:
1. Если мы идем из центрального офиса на удаленную площадку, то там наши пакеты имеют IP-адреса реальные, адреса хостов центрального офиса. Это правильно.
2. Если мы пытаемся послать через openVPN пакеты с удалённой площадки в центральный оффис - к получателю приходит замаскараденный адрес. Вместо реального IP ремутного хоста - IP адрес tun0-интерфейса этого нашего центрального шлюза. А это - неправильно.
Маскарадинг у меня на этом шлюзе включен. Но на совершенно ином (смотрящем в интернет) интерфейсе. Никаких правил в iptables по маскарадингу ни на tun0, ни на физическом интерфейсе у меня нет. В литературе читаю, что NAT на tun вешается средствами iptables. Но я же его не вешаю... Откуда он берется на tun0 - не понимаю.

Когда ходите с центрального офиса вы идёте самого сервера где стоит OpenVpn?
А получатель пакета сидит за NAT или тоже является клиентом OpenVpn?

Kettler написал:

Когда ходите с центрального офиса вы идёте самого сервера где стоит OpenVpn?
А получатель пакета сидит за NAT или тоже является клиентом OpenVpn?

Чуток соврал. Из лавки в ремутныю площадку прилетают честные пакеты. Из ремутной площадки в лавку прилетают пакеты с адресом tun-интерфейса ремутной площадки. То есть в центре tun имеет адрес 192.168.128.1. На ремутной площадке - 192.168.128.2.

Итак, если я пингую из центра (192.168.43.52) ремутную площадку, то имею на её входном интерфейсе (192.168.53.1):
[console]# tcpdump -n | grep ICMP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
16:32:47.405994 IP 192.168.43.52 > 192.168.53.1: ICMP echo request, id 43885, seq 1, length 64
16:32:47.406068 IP 192.168.53.1 > 192.168.43.52: ICMP echo reply, id 43885, seq 1, length 64
16:32:48.406758 IP 192.168.43.52 > 192.168.53.1: ICMP echo request, id 43885, seq 2, length 64
16:32:48.406802 IP 192.168.53.1 > 192.168.43.52: ICMP echo reply, id 43885, seq 2, length 64
16:32:49.407004 IP 192.168.43.52 > 192.168.53.1: ICMP echo request, id 43885, seq 3, length 64
16:32:49.407048 IP 192.168.53.1 > 192.168.43.52: ICMP echo reply, id 43885, seq 3, length 64
[/console]
На интерфейсе центральной машины - тоже всё правильно при этом:
[console]# tcpdump -n | grep ICMP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
16:42:14.391764 IP 192.168.43.52 > 192.168.53.1: ICMP echo request, id 57197, seq 1, length 64
16:42:14.393792 IP 192.168.53.1 > 192.168.43.52: ICMP echo reply, id 57197, seq 1, length 64
16:42:15.390793 IP 192.168.43.52 > 192.168.53.1: ICMP echo request, id 57197, seq 2, length 64
16:42:15.392336 IP 192.168.53.1 > 192.168.43.52: ICMP echo reply, id 57197, seq 2, length 64
[/console]
Всё замечтельно...

Но если я начинаю пинговать в обратную сторону, пинговать центр из ремутной площадки, то вот что имеем на интерфейсе центральной пингуемой машины...
[console]# tcpdump -n | grep ICMP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
16:35:08.642576 IP 192.168.128.2 > 192.168.43.52: ICMP echo request, id 5652, seq 1, length 64
16:35:08.642621 IP 192.168.43.52 > 192.168.128.2: ICMP echo reply, id 5652, seq 1, length 64
16:35:09.642724 IP 192.168.128.2 > 192.168.43.52: ICMP echo request, id 5652, seq 2, length 64
16:35:09.642821 IP 192.168.43.52 > 192.168.128.2: ICMP echo reply, id 5652, seq 2, length 64
16:35:10.642668 IP 192.168.128.2 > 192.168.43.52: ICMP echo request, id 5652, seq 3, length 64
16:35:10.642701 IP 192.168.43.52 > 192.168.128.2: ICMP echo reply, id 5652, seq 3, length 64
[/console]
То есть ремутный openVPN (клиент) заменил реальный адрес отправителя запроса своим и радуется жизни... Пинги - они, конечно ходят, но мне надо настраивать взаимодействие иных сервисов. А для них такое поведение ремутного хоста - несколько непонятно. Спрашиваем у одного, отвечает другой...

Хотя... Наверное Вы точно подметили - пингуемый ремутный хост един во всех своих ипостясях. И начинает он пинговать лавку не с физического интерфейса, а с tun'а. Так что считаем тему закрытой. Я затупил немного...

Теперь пробуем ещё подстроить маршруты для правильного хождения пакетов.