LINUX.ORG.RU
ФорумAdmin

роутинг на контейнер с ppp - непонятки :(

 ,


0

2

в контейнере поднят pptp (наш192.168.0.75 - 192.168.0.10их) ip ноды 192.168.0.84 ip контейнера 192.168.10.11 с контейнера нужный айпи 192.168.0.99(к нему нужен доступ из сети) - пингуется! с ноды роутинг прописан на контейнер и пакеты уходят на venet0 внутри контейнера пакетов на venet0 - нету :( модули iptables настроены, форвардинг и проч - разрешено!

куда смотреть?

назначил от балды роутинг для 192.168.10.123 на 192.168.10.11(ip контейнера) - фиг там - нету пакетов внутри контейнера! :(



Последнее исправление: frol314 (всего исправлений: 1)

Ок. если русским языком.

Ты хочешь сделать OpenVZ контейнер, который будет работать как прокси. Нужно чтоб хост для определенного IP обращался к контейнеру как к роутеру, и оттуда перенаправлялся в тоннель. Проблема в том что когда пакет уходит с хоста в контейнер, судя по выводу tcpdump/wireshark внутри контейнера все глухо и никакой пакет не приходит. Форвард разрешен, порты/icmp на контейнере разрешены. Сам контейнер через тоннель ходит как надо.

Я правильно понял вопрос? Если да - скинь таблицу маршрутов, хоть какой-то кусок tcpdump с обеих сторон и заодно посмотри что получает хост когда контейнер пытается пойти по тоннелю (так, на всякий случай). Плюс проверь SElinux и прочие фаерволы

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

спасибо за отзыв!

проблема в том, что на той стороне чужая сеть и нам там дали виртуалку с доступом по pptp :( и адресация сети совпадает с нашей в придачу :( поэтому не можем поднять pptp на основном гейте - совпадают адреса важных хостов :(

это хост-нода

192.168.0.75 192.168.10.11 255.255.255.255 UGH 0 0 0 venet0

192.168.10.11 0.0.0.0 255.255.255.255 UH 0 0 0 venet0

192.168.0.99 192.168.10.11 255.255.255.255 UGH 0 0 0 venet0

192.168.0.0 0.0.0.0 255.255.240.0 U 0 0 0 bond0

169.254.0.0 0.0.0.0 255.255.0.0 U 1007 0 0 bond0

0.0.0.0 192.168.0.60 0.0.0.0 UG 0 0 0 bond0

--- 192.168.0.99 ping statistics ---

3 packets transmitted, 0 received, 100% packet loss, time 11999ms

tcpdump -ni venet0

08:29:28.444807 IP 192.168.0.84 > 192.168.0.99: ICMP echo request, id 37026, seq 1, length 64

08:29:29.444760 IP 192.168.0.84 > 192.168.0.99: ICMP echo request, id 37026, seq 2, length 64

08:29:30.444723 IP 192.168.0.84 > 192.168.0.99: ICMP echo request, id 37026, seq 3, length 64

это ВМ

192.168.0.10 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0

192.168.0.99 192.168.0.10 255.255.255.255 UGH 0 0 0 ppp0

195.144.201.138 0.0.0.0 255.255.255.255 UH 0 0 0 venet0

169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 venet0

0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 venet0

[root@vpngate ~]# ping 192.168.0.99

2 packets transmitted, 2 received, 0% packet loss, time 1464ms

[root@vpngate ppp]# tcpdump -ni venet0

08:36:11.987438 IP 195.144.201.138.pptp > 192.168.10.11.36601: Flags [P.], seq 3240780200:3240780216, ack 1818670348, win 8326, options [nop,nop,TS val 3278471214 ecr 65887809], length 16: pptp CTRL_MSGTYPE=ECHORQ ID(1)

08:36:11.987487 IP 192.168.10.11.36601 > 195.144.201.138.pptp: Flags [.], ack 16, win 123, options [nop,nop,TS val 65947807 ecr 3278471214], length 0

08:36:11.987547 IP 192.168.10.11.36601 > 195.144.201.138.pptp: Flags [P.], seq 1:21, ack 16, win 123, options [nop,nop,TS val 65947807 ecr 3278471214], length 20: pptp CTRL_MSGTYPE=ECHORP ID(1) RESULT_CODE(1) ERR_CODE(0)

08:36:12.005851 IP 195.144.201.138 > 192.168.10.11: GREv1, call 0, seq 14, length 24: LCP, Echo-Request (0x09), id 3, length 10

08:36:12.007827 IP 192.168.10.11 > 195.144.201.138: GREv1, call 15422, seq 14, ack 14, length 26: LCP, Echo-Reply (0x0a), id 3, length 10

08:36:12.033412 IP 195.144.201.138 > 192.168.10.11: GREv1, call 0, ack 14, no-payload, length 12

08:36:12.088377 IP 195.144.201.138.pptp > 192.168.10.11.36601: Flags [.], ack 21, win 8326, options [nop,nop,TS val 3278471315 ecr 65947807], length 0

08:36:32.006580 IP 195.144.201.138 > 192.168.10.11: GREv1, call 0, seq 15, length 24: LCP, Echo-Request (0x09), id 4, length 10

08:36:32.009117 IP 192.168.10.11 > 195.144.201.138: GREv1, call 15422, seq 15, ack 15, length 26: LCP, Echo-Reply (0x0a), id 4, length 10

08:36:32.035144 IP 195.144.201.138 > 192.168.10.11: GREv1, call 0, ack 15, no-payload, length 12

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

контейнер ходит через pptp без проблем!

сделал dnat с ip 192.168.100.99 (на основном шлюзе для нашей сети)

в ихнюю сеть на ip 192.168.0.99 через гейт(виртуалка 192.168.10.11) для нашего гейта ;)

судя по пакетам всё ок - а вот виртуалка в качестве шлюза подкачала :( не хочет принимать чужие пакеты напрочь!

frol314
() автор топика
Ответ на: спасибо за отзыв! от frol314

Внешне вроде норм. Но вообще это все имхо лучше делать на основном роутере через nat, тупо замаппить их подсеть на что-то чего у вас нет и на роутере менять подсеть. Но тут нужно аккуратным быть, чтоб обе подсети разом не грохнуть.

В случае если всего 1 хост нужен все тривиально

А так - на вид норм но я хз как openvz отработает такую ситуацию. На всякий проверь правила iptables как в http://www.zedt.eu/tech/linux/setting-pptp-vpn-server-centos-openvz-vps/

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

проблема ещё в том, что у них адрес хоста с которым соединяют по pptp внутри 0.10 и он получается роутером для 0.99 а мне для гейта позарез нужен наш 0.10 (почтовик) вот и получается такая бодяга :(

так-то пока тайком установил openvpn но там персональные данные и всё такое - нельзя без разрешения и кучи согласований :(

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

напрягает, что нету пакетов от ноды в сеть которую поднимает ВМ притом на ноде они есть, а внутри ВМ нету! поднятая сеть(pptp) на ВМ работает прекрасно - всё настроил и поднял там опенвпн для всех остальных!

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

так сложилось исторически...

возможно получится сменить позже...

в любом случае не это важно - почему пакеты на venet0 ноды есть, а на venet0 (и venet0:0) ВМ нету?

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