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. На мой взгляд все в норме, но явно что-то упускаю.

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

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

Ну главное отличие - ike поднимает tap-адаптер, vpnc - tun. Затем трафик через ike у меня уходит через wlan0 на адрес vpn-шлюза в Интернете и приходит так же с wlan0 с src=«пингуемый хост» и dest=«ip tap0», а в случае с vpnc - через этот tun и туда и обратно, в ответе dest=«ip моего контейнера», и потом форвардится в бридж и в контейнер.

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

Нет, ссылка из другово топика, вот та: http://binaryjunction.com/2010/05/07/openswan-vpn-client-cisco-servers/

vpnc - через этот tun и туда и обратно,

Нагуглил:

VPNC is a user space IPsec implementation that utilizes the tun device

Значит ″vpnc″ user-space, а ″shrew″, судя по выводу ″ip xfrm pol″ — kernel-space. ИМХО, с большой долей вероятности у openswan будут те же проблемы, что и у shrew. Я проверял на ядре 2.6.32, у вас явно новее, может имеет смысл сначала поднять тестовый openswan тунель, без cisco, а уже по результатам, либо пытаться подключить openswan к cisco, либо ковырять ядро.

mky ★★★★★
()

В общем я уже всю голову сломал с этими tun\tap и прочим (да еще и гуглится все это крайне плохо), так что я поднял SOCKS5-прокси из контейнера до хоста и завернул трафик в vpn через эту проксю - мне, в общем-то нужен ssh, так что сделал это через

cat ~/.ssh/config
Host *
ProxyCommand connect-proxy -S localhost:тутПортПрокси %h %p

Ну и на всякий случай добавил прокси в proxychains.

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