LINUX.ORG.RU
ФорумAdmin

Помогите с NAT'ом

 , ,


0

3

Добрый день!

Есть ПК (дальше «хост»), на котором есть LXC-контейнер (дальше «контейнер»). Хост по vpn подключен к другой сети, в которую хочу получить доступ из контейнера. Пингую хост за vpn из контейнера - ответов не получаю. На хосте в tcpdump вижу такую картину - пинг уходит с ip контейнера в качестве источника, а ответ приходит с ip хоста (не контейнера) в качестве назначения и дальше в контейнер пакет не натится. Ресурсы в интернетах из контейнера доступны. Виртуалка в virtualbox на этом же хосте нормально может общаться с хостами за vpn. В случае с virtualbox в настройках сетевого адаптера указан просто NAT, конфиг контейнера:

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = virbr0
lxc.network.ipv4 = 192.168.122.2/24

ifconfig хоста (lo не стал писать)

tap0      Link encap:Ethernet  HWaddr 02:ac:36:d9:56:3a  
          inet addr:172.16.3.31  Bcast:172.16.3.255  Mask:255.255.255.0
          inet6 addr: fe80::ac:36ff:fed9:563a/64 Scope:Link
          UP BROADCAST RUNNING  MTU:1380  Metric:1

virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          
wlan0     Link encap:Ethernet  HWaddr 74:e5:43:78:d4:f0  
          inet addr:10.0.1.210  Bcast:10.0.1.255  Mask:255.255.255.0
          inet6 addr: fe80::76e5:43ff:fe78:d4f0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

tap0 - это интерфейс vpn-клиента, virbr0 - интерфейс lxc, wlan0 - wifi, то есть выход в интернеты.

iptables

*mangle
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill
COMMIT


*nat
-A POSTROUTING -s 192.168.122.0/24 -d 224.0.0.0/24 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 -d 255.255.255.255/32 -j RETURN
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
COMMIT

*filter
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
COMMIT

Правила в iptables не меняются при включении\отключении виртуалки в virtualbox. На мой взгляд все в норме, но явно что-то упускаю.

В общем я не знаю куда копать, подскажите, пожалуйста. Заранее огромное спасибо!

★★★★★
Ответ на: комментарий от post-factum
default via 10.0.1.1 dev wlan0 
10.0.1.0/24 dev wlan0  proto kernel  scope link  src 10.0.1.210 
10.41.0.0/16 via 172.16.3.31 dev tap0  proto static 
10.61.0.0/16 via 172.16.3.31 dev tap0  proto static 
10.62.0.0/16 via 172.16.3.31 dev tap0  proto static 
10.63.0.0/16 via 172.16.3.31 dev tap0  proto static 
10.64.0.0/16 via 172.16.3.31 dev tap0  proto static 
10.65.0.0/16 via 172.16.3.31 dev tap0  proto static 
10.66.0.0/16 via 172.16.3.31 dev tap0  proto static 
10.68.0.0/16 via 172.16.3.31 dev tap0  proto static 
10.69.0.0/16 via 172.16.3.31 dev tap0  proto static 
10.120.2.0/24 via 172.16.3.31 dev tap0  proto static 
10.151.2.0/24 via 172.16.3.31 dev tap0  proto static 
*тут ip vpnшлюза* via 10.0.1.1 dev wlan0  proto static 
172.16.0.0/12 via 172.16.3.31 dev tap0  proto static 
172.16.3.0/24 dev tap0  proto kernel  scope link  src 172.16.3.31 
172.16.104.0/24 via 172.16.3.31 dev tap0  proto static 
172.20.3.0/24 via 172.16.3.31 dev tap0  proto static 
172.20.14.0/23 via 172.16.3.31 dev tap0  proto static 
172.30.0.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.98.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.120.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 
192.168.152.96/28 via 172.16.3.31 dev tap0  proto static 
192.168.192.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.195.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.220.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.223.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.224.0/28 via 172.16.3.31 dev tap0  proto static 
192.168.224.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.225.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.226.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.227.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.228.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.229.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.230.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.231.0/25 via 172.16.3.31 dev tap0  proto static 
192.168.232.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.233.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.250.0/24 via 172.16.3.31 dev tap0  proto static 
192.168.251.0/24 via 172.16.3.31 dev tap0  proto static
alozovskoy ★★★★★
() автор топика
Последнее исправление: alozovskoy (всего исправлений: 1)
Ответ на: комментарий от trofk

был 58 в контейнере и 63 в виртуалке, через iptables задал в контейнере 63 - не помогло (в смысле изменения есть, результата нет). Изменение в виртуалке ttl на 58 также ничего не меняет.

alozovskoy ★★★★★
() автор топика
Последнее исправление: alozovskoy (всего исправлений: 2)

Мне кажется что тебе нужно в таблице нат всего одно правило:

-A POSTROUTING -o интерфейс.впн -j SNAT --to-source адрес.нат
И соответствующий маршрут.

sin_a ★★★★★
()
Ответ на: комментарий от sin_a

Что-то я не понимаю зачем это правило, у меня же подключение строится из контейнера, мне не нужно новые запросы из-за vpn натить в контейнер.

alozovskoy ★★★★★
() автор топика
Последнее исправление: alozovskoy (всего исправлений: 1)
Ответ на: комментарий от alozovskoy

Значит нужно что бы пакет выходящий из контейнера пошёл в впн? Тогда надо сделать на хосте нат на интерфейсе впн и маршрут для сетей, которые там искать. Или я что-то не так понял?

sin_a ★★★★★
()
*mangle
-A POSTROUTING -o virbr0 -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill

Какие замечательные грабли с аппаратным подсчетом КС в виртуальном устройстве. Я им в netdev@ про это еще 2 года назад говорил, что не нужно так делать.

Если по-хорошему, то нужно "-j CHECKSUM" делать на все в mangle/OUTPUT через veth. Что-то типа -m physdev --physdev-out veth+ -j CHECKSUM --checksum-fill"

Я это обходил в виде патча к ядру или «ethtool -K vethX rx off tx off»

Про NAT. Если есть связь с админами той сети, то NAT не нужен. Нужно только чтоб с той стороны VPN знали ( в виде маршрута через VPN) о твоей сети.

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от sin_a

Пакет исходящий из контейнера в vpn идет, а вот ответ не возвращается в контейнер, при этом на хосте я вижу что пакет из-за vpn пришел, но в качестве адреса у него значится ip tap-инферфейса хоста, а не ip интерфейса контейнера, то есть как будто когда пакет возвращается iptables не знает что запрос ушел из контейнера и не натит туда ответ.

alozovskoy ★★★★★
() автор топика
Ответ на: комментарий от vel

Нет, с той стороны никто не будет для меня ничего прикручивать, да и в принципе нет такой необходимости, мне же по сути не нужно чтоб к моему контейнеру из той сети был доступ.

alozovskoy ★★★★★
() автор топика
Ответ на: комментарий от alozovskoy

не натит туда ответ

Пакет идущий из впн по направлению в контейнер не нужно натить. Или я опять чего-то не понимаю?

sin_a ★★★★★
()
Ответ на: комментарий от alozovskoy

Мне кажется что тебе нужно в таблице нат всего одно правило:

-A POSTROUTING -o интерфейс.впн -j SNAT --to-source адрес.нат
И соответствующий маршрут.

sin_a ★★★★★ (11.04.2015 13:35:38)

вариант со SNAT хорош тем, что видно - попали туда пакеты или нет.

А VPN то работает ? С хоста есть доступ к интересующим хостам в удаленной сети ?

В контенере и на хосте сделай «ethtool -K XXXX rx off tx off» - пакеты с битыми КС могут не форвардиться через NAT.

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от sin_a

Пакет идущий из впн по направлению в контейнер не нужно натить. Или я опять чего-то не понимаю?

Если это ответный пакет, то не нужно. de-NAT делается автоматически.

А если с той стороный знают про эту сеть, то NAT вообще не нужен.

vel ★★★★★
()
Ответ на: комментарий от vel

А VPN то работает ? С хоста есть доступ к интересующим хостам в удаленной сети ?

Да, с этим все ОК.

ethtool -K XXXX rx off tx off

Не помогло (интерфейсы подставил, и так off был, в контейнере выполнилось, но безрезультатно).

alozovskoy ★★★★★
() автор топика
Ответ на: комментарий от alozovskoy

Если icmp-трафик не напряженный, то можно попробовать воспользоваться TRACE на хосте

iptables -t raw -A PREROUTING -p icmp -j TRACE
Она пишет в лог все правила iptables, через которые проходит пакет. Пользоваться нужно аккуратно т.к. пишется много строк на каждый пакет. Там видно где и как выполнился NAT.

После этого послать пару пингов из контейнера.

Если счетчик в этом правиле стал не нулевым, а в логах пусто, нужно убедиться, что в /proc/sys/net/netfilter/nf_log/2 не «NONE» (должно упоминаться nf_log_ipv4). Если «NONE», то нужно выполнить

iptables -I INPUT 1 -j LOG
iptables -D INPUT 1

Не забудь очистить raw после получения логов.

vel ★★★★★
()
Ответ на: комментарий от vel

Посмотрел, но опять же ничего полезного - пакет уходит в vpn с SRC контейнера, а приходит - с DEST vpn-интерфейса хоста.

alozovskoy ★★★★★
() автор топика

В общем два направления для раздумий у меня есть:

1. virtualbox не создает «физический» адаптер когда тип подключения NAT, а разделяет существующий. Это видно и в tcpdump - у меня в качестве ip источника при пинге из виртуалки идет ip хоста, ответы туда же, как именно это работает я не понял, но у меня нет и в iptables никаких правил, так что я считаю что тут работа virtualbox аналогична работе любой другой программы, которую я на хосте запускаю, то есть вообще можно не принимать во внимание что это система в системе если смотреть со стороны сети.

2. В lxc у меня используется libvirt, и конфигом бриджа управляет он, так что буду курить какие есть подводные камни при NATе «интерфейса» libvirt либо вообще запилю его бриджем не в какой-нибудь новый интерфейс на хосте а прям в wlan0, то есть получу аналог сети virtualbox и думаю это поможет (но это на крайний случай).

alozovskoy ★★★★★
() автор топика
Ответ на: комментарий от alozovskoy

Посмотрел, но опять же ничего полезного - пакет уходит в vpn с SRC контейнера, а приходит - с DEST vpn-интерфейса хоста.

А в TRACE видно что через nat-таблицу пакеты проходят?

Есть возможность перехватывать пакеты идущие через L2 в L3. man ebtables на предмет brouting. Оно для тах вариантов и предназначено.

А этот libvirt создает конфиг для lxc? Если да, то там видно во что он подключает интерфейс в lxc.network.link. Через lxc-info и brctl show это можно посмотреть.

Не знаю как сейчас, но пару лет назад, когда я смотрел на libvirt с точки зрения настройки сети lxc, оно было угребищем.

Если контейнер подключить через veth без моста, то проблем с нат-ом точно нет.

Про virtualbox ничего не скажу - никогда не пользовался этой поделкой.

vel ★★★★★
()
Ответ на: комментарий от vel

А в TRACE видно что через nat-таблицу пакеты проходят?

Исходящие - да, входящие - нет.

А этот libvirt создает конфиг для lxc?

Да что-то не пойму - я мост всегда настраивал через конфиг контейнера lxc, сейчас решил удалить этот мост (выпилив его из контейнера и перезапустив lxc), brctl говорит что мост используется. Полез смотреть - в конфиге libvirt этот мост тоже прописан, при чем с теми же параметрами (ip например) что и в lxc, но этот конфиг лежит в /etc/libvirt/qemu/networks/default.xml, при чем тут вообще qemu я не понял, но видно что libvirt и lxc между собой взаимодействуют.

Если контейнер подключить через veth без моста, то проблем с нат-ом точно нет.

Сейчас попробую без моста, но он и сейчас через veth подключен. И ebtables тоже попробую. А еще есть идея попробовать snat сделать, подменяя адрес контейнера на адрес хоста, может тогда получится, хотя кмк это masquerade и делает.

alozovskoy ★★★★★
() автор топика
Ответ на: комментарий от alozovskoy

А в TRACE видно что через nat-таблицу пакеты проходят?

Исходящие - да, входящие - нет.

разНАТивание пакета видно только косвенно. в raw адреса оригинальные, а в mangle/prerouting dst уже локальный.

А исходящие НАТятся ?

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

Да. Вот в кратком изложении (оставил только нужную на мой взгляд инфу, то есть этапы прохождения пакета все, а всякие LEN да TTL убрал)

TRACE: raw:PREROUTING:policy:2 IN=virbr0 OUT= PHYSIN=vethH6N77H SRC=192.168.122.2 DST=172.16.40.2
TRACE: mangle:PREROUTING:policy:1 IN=virbr0 OUT= PHYSIN=vethH6N77H SRC=192.168.122.2 DST=172.16.40.2
TRACE: nat:PREROUTING:policy:1 IN=virbr0 OUT= PHYSIN=vethH6N77H SRC=192.168.122.2 DST=172.16.40.2
TRACE: mangle:FORWARD:policy:1 IN=virbr0 OUT=tap0 PHYSIN=vethH6N77H SRC=192.168.122.2 DST=172.16.40.2
TRACE: filter:FORWARD:rule:2 IN=virbr0 OUT=tap0 PHYSIN=vethH6N77H SRC=192.168.122.2 DST=172.16.40.2
TRACE: mangle:POSTROUTING:policy:2 IN= OUT=tap0 PHYSIN=vethH6N77H SRC=192.168.122.2 DST=172.16.40.2
TRACE: nat:POSTROUTING:rule:5 IN= OUT=tap0 PHYSIN=vethH6N77H SRC=192.168.122.2 DST=172.16.40.2
TRACE: raw:OUTPUT:policy:1 IN= OUT=wlan0 SRC=10.0.1.210 DST=*тут ip vpn-шлюза*
TRACE: mangle:OUTPUT:policy:1 IN= OUT=wlan0 SRC=10.0.1.210 DST=*тут ip vpn-шлюза*
TRACE: filter:OUTPUT:policy:2 IN= OUT=wlan0 SRC=10.0.1.210 DST=*тут ip vpn-шлюза* 
TRACE: mangle:POSTROUTING:policy:2 IN= OUT=wlan0 SRC=10.0.1.210 DST=*тут ip vpn-шлюза*
TRACE: raw:PREROUTING:policy:2 IN=wlan0 OUT= SRC=172.16.40.2 DST=172.16.3.24
TRACE: mangle:PREROUTING:policy:1 IN=wlan0 OUT= SRC=172.16.40.2 DST=172.16.3.24
alozovskoy ★★★★★
() автор топика
Последнее исправление: alozovskoy (всего исправлений: 1)
Ответ на: комментарий от alozovskoy

TRACE: nat:POSTROUTING:rule:5 IN= OUT=tap0 PHYSIN=vethH6N77H SRC=192.168.122.2 DST=172.16.40.2

Отлично! Туда занатилось. В «conntack -L -p icmp» должно быть видно ip которым НАТилось.

А обратный пакет видно ? TRACE можно ограничить только для virbr0 и для tap0, чтоб другой трафик не попадал в логи.

vel ★★★★★
()
Ответ на: комментарий от vel

А обратный пакет видно ?

Все что было написал. Трафика на хосте не было, ждал долго, так что ничего не пропустил.

alozovskoy ★★★★★
() автор топика
Ответ на: комментарий от alozovskoy

А эта проблема не может быть в настройках vpn-сервера? Нашел вот такой пост, не пойму оно или нет http://vpn-help.shrew.narkive.com/zH10QmYb/nat-via-tunnel

Да, и тут такой случай уже был - Проблема с VPN, не маршрутизируются пакеты, CheckPoint

Пойду смотреть как запилить сеть lxc аналогично «NAT» в virtualbox (то есть чтоб не с отдельного интерфейса пакеты уходили)

alozovskoy ★★★★★
() автор топика
Последнее исправление: alozovskoy (всего исправлений: 2)
Ответ на: комментарий от alozovskoy

Странно. Хоть самому собирай такую конструкцию.

vel ★★★★★
()
Ответ на: комментарий от alozovskoy

Нет проблем. Все замечательно работает. На хосте бридж eth0

bridge name     bridge id               STP enabled     interfaces
eth0            8000.000010000052       no              dcpp0
                                                        eth0x
eth0x - сетевушка, dcpp0 - локальный конец veth идущий в контейнер.
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = eth0
lxc.network.name = eth0
lxc.network.veth.pair=dcpp0
lxc.network.hwaddr = 00:01:43:49:79:ba
lxc.network.ipv4 = 10.0.0.40/24
lxc.network.ipv4.gateway = 10.0.0.253
Хост
# ip ro
default via 10.150.100.1 dev eth1  metric 1 
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.253 
10.3.2.0/24 dev tap0  proto kernel  scope link  src 10.3.2.10
10.10.0.0/20 via 10.3.2.1 dev tap0
10.14.140.0/24 via 10.3.2.1 dev tap0 
10.52.210.0/24 via 10.3.2.1 dev tap0 
10.150.100.0/25 dev eth1  proto kernel  scope link  src 10.150.100.7 
127.0.0.0/8 dev lo  scope link 
192.168.1.0/24 via 10.3.2.1 dev tap0 
xxx.xxx.xxx.xxx via 10.150.100.1 dev eth1 
xxx.xxx.xxx.xxx - адрес ovpn сервера. NAT
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o tap0 -j MASQUERADE
контейнер
# ip ro
default via 10.0.0.253 dev eth0 
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.40
# traceroute -n 10.52.210.9
traceroute to 10.52.210.9 (10.52.210.9), 30 hops max, 60 byte packets
 1  10.0.0.253  0.070 ms  0.022 ms  0.022 ms
 2  10.3.2.1  21.427 ms  23.996 ms  23.997 ms
 3  10.200.2.1  23.987 ms  23.977 ms  23.965 ms
 4  10.52.210.9  23.959 ms  23.953 ms  23.944 ms
10.52.210.9 - машинка в глубине удаленной сети

Есть достаточно важная особенность - ядро без CONFIG_BRIDGE_NETFILTER.

Если оно с ним, то желательно отключить sysctl net.bridge.bridge-nf-call-iptables или разрешить хождение через бридж любых пакетов

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от vel

Есть достаточно важная особенность - ядро без CONFIG_BRIDGE_NETFILTER.

У меня CONFIG_BRIDGE_NETFILTER=y, добавил

net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0

но это не помогло.

В остальном вроде все так.

Это похоже проблема vpn через cisco, с openvpn у меня тоже все в порядке без каких либо дополнительных настроек.

alozovskoy ★★★★★
() автор топика

mky, может сможешь помочь, посмотри, пожалуйста.

alozovskoy ★★★★★
() автор топика
Ответ на: комментарий от vel

Хотел обратить внимание, что вот у ответного пакета интерфейс wlan0,

TRACE: raw:PREROUTING:policy:2 IN=wlan0 OUT= SRC=172.16.40.2 DST=172.16.3.24

хотя по идее это пакет из тунеля, поэтому у него должно быть IN=tap0... или не должен?

2ТС. Какой именно VPN-клиент используется? Ну и так, пальцем в небо. rp_filter выключен? И, этот ответный пакет — это точно ответ на ваш пинг, у него icmp-echo-replay и id/seq совпадают?

mky ★★★★★
()
Ответ на: комментарий от mky

Какой именно VPN-клиент используется?

В репозитории называется ike, вообще это shrew.

rp_filter выключен?

Да, на всех интерфейсах

И, этот ответный пакет — это точно ответ на ваш пинг, у него icmp-echo-replay и id/seq совпадают?

Больше я в этот момент с этим сервером никак не общался, id и seq совпадают, так что ответ точно на мой пинг. Да и проверял не раз, все время идентичная картина.

alozovskoy ★★★★★
() автор топика
Ответ на: комментарий от alozovskoy

Попробуйте включить nf_conntrack_log_invalid и сделать пинг, может что в лог упадёт.

Я не знаю, как устроен shrew, посмотрите вывод команды ″ip xfrm pol show″. Если там будут правила (политики) для ваших VPN-адресов, значит обычный стек NETKEY.

mky ★★★★★
()
Ответ на: комментарий от mky

Попробуйте включить nf_conntrack_log_invalid и сделать пинг, может что в лог упадёт.

Ничего не упало.

посмотрите вывод команды ″ip xfrm pol show″

Там есть правила для подсетей за vpn, выглядит вот так:

src a.a.a.a/32 dst b.b.b.b/16 
	dir out priority 0 ptype main 
	tmpl src c.c.c.c dst d.d.d.d
		proto esp reqid 0 mode tunnel
src b.b.b.b/16 dst a.a.a.a/32 
	dir in priority 0 ptype main 
	tmpl src d.d.d.d dst c.c.c.c
		proto esp reqid 0 mode tunnel

Где:

  • a.a.a.a - ip моего tap0 интерфейса (то есть тот что мне выдается при подключении к vpn)
  • b.b.b.b - разные сети за vpn
  • c.c.c.c - ip моего wlan0 интерфейса (то есть той сети, через которую я хожу в интернет)
  • d.d.d.d - ip vpn-шлюза (к которому я подключаюсь, внешний адрес)
alozovskoy ★★★★★
() автор топика
Последнее исправление: alozovskoy (всего исправлений: 1)
Ответ на: комментарий от alozovskoy

В общем дело не в lxc и не в бриджах - то же самое я наблюдаю и просто NAT'я запросы с соседнего ПК (сам по себе NAT при этом нормально работает, проблема именно с vpn через cisco).

alozovskoy ★★★★★
() автор топика
Ответ на: комментарий от alozovskoy

проблема именно с vpn через cisco

Судя по тому, что там обычный NETKEY, это проблема ipsec. Хотел попробовать поднять ipsec тунель через openswan и посмотреть, будет ли там работать SNAT, но пока нет времени.

Из интереса, а ″ping -I 192.168.122.1 -n 172.16.40.2″ с хоста сработает?

Ещё попробуйте включить log_martians, может там будет что про дропаемые пакеты.

mky ★★★★★
()
Ответ на: комментарий от mky

Из интереса, а ″ping -I 192.168.122.1 -n 172.16.40.2″ с хоста сработает?

Да, работает.

log_martians

В лог ничего не падает.

Хотел попробовать поднять ipsec тунель через openswan

А может быть посоветуете какой-нибудь хороший мануал по этим swan'ам - пытался запустить, но у меня то есть только пара паролей да адрес шлюза, а в документации описываются конфиги так будто у меня доступ к Cisco есть с возможностью ее частичного переконфигурирования. Или может ему как-то можно подсунуть конфиги от нативного клиента, а то и взять где-то стандартный конфиг для такого случая?

alozovskoy ★★★★★
() автор топика
Ответ на: комментарий от alozovskoy

Не поднимал ipsec к Cisco VPN. Вот простой конфиг: http://www.ibiblio.org/pub/Linux/system/recovery/ Насколько я понял, там всё отличие от обычного случая это опции ″leftmodecfgclient=yes″/″rightmodecfgserver=yes″ и ″leftxauthclient=yes″, ″leftxauthusername=″.

Но, прежде чем пробовать подключить Swan к вашему VPN, нужно сначала убедиться, что в нём нет подобной проблемы с ответами на SNAT-пакеты.

mky ★★★★★
()
Ответ на: комментарий от mky

Да, проблема именно с клиентом - поднял vpn используя vpnc - все работает отлично. Правда с используемой циской есть проблема с vpnc - там какие-то сложности с повторной аутентификацией (не специалист, не могу точно описать) и соединение каждые 10 минут отваливается, так что использовать его как основной vpn-клиент не получится.

alozovskoy ★★★★★
() автор топика
Последнее исправление: alozovskoy (всего исправлений: 1)
Ответ на: комментарий от alozovskoy

Странно. Сечас проверил, сделал SNAT в ipsec тунель с openswan. Всё работает. Если у вас работает с vpnc, но не работает с shrew, то не понято почему. Эти клиенты, насколько я понимаю, не получают пакеты от сервера к клиенту.

Пакеты преобразуются (дешифруются) политикой xfrm и далее идут по iptables как обычные пакеты. И мне не понятно, чем пакет из shrew-тунеля может оличаться от пакета из vpnc-тунеля. Попробуйте сделать ″-j TRACE″ ping'а для shrew и сравнить все поля в описании пакета.

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.