Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT
Anton Gorlov писал(а) в своём письме Wed, 28 Jun 2017 23:28:28 +0300: 28.06.2017 11:13, Михаил Касаджиков пишет: Это дело стало необходимым потому что то ли в свежих ядрах, то ли в дебиане (давно копал) теперь nat_helpers не применяются без явного на то указания. В ядрах..Вернее в таблесах автомат сделали депрекейтед. Тогда точно нужно переходить на правила в iptables. -- Написано с помощью почтового клиента Opera: http://www.opera.com/mail/
Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT
On Wed, Jun 28, 2017 at 10:09:49PM +0300, Andrey Tataranovich wrote: > On Wed, 28 Jun 2017 13:53:51 +0300 > Eugene Berdnikov wrote: > > > А просто "sysctl -w net.netfilter.nf_conntrack_helper=1" не помогает? > > Помогает. Тогда его в /etc/sysctl.conf. -- Eugene Berdnikov
Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT
On Wed, 28 Jun 2017 11:13:18 +0300 Михаил Касаджиков wrote: > Добавьте в iptables в таблицу raw правило для использования pptp: > > root@debby2: ~# iptables-save -t raw > # Generated by iptables-save v1.6.0 on Wed Jun 28 11:08:40 2017 > *raw > :PREROUTING ACCEPT [499445987:251052699965] > :OUTPUT ACCEPT [118702475:62694078445] > -A PREROUTING -p tcp -m tcp --dport 1723 -j CT --helper pptp > COMMIT > # Completed on Wed Jun 28 11:08:40 2017 > > Это дело стало необходимым потому что то ли в свежих ядрах, то ли в > дебиане (давно копал) теперь nat_helpers не применяются без явного на > то указания. После добавления правила pptp подключился без проблем. Ниже по треду предложили вариант с sysctl, который тоже работает. sysctl -w net.netfilter.nf_conntrack_helper=1 -- WBR, Andrey Tataranovich
Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT
On Wed, 28 Jun 2017 13:53:51 +0300 Eugene Berdnikov wrote: > А просто "sysctl -w net.netfilter.nf_conntrack_helper=1" не помогает? Помогает. -- WBR, Andrey Tataranovich
Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT
Eugene Berdnikov писал(а) в своём письме Wed, 28 Jun 2017 13:53:51 +0300: On Wed, Jun 28, 2017 at 11:13:18AM +0300, Михаил Касаджиков wrote: Andrey Tataranovich писал(а) в своём письме Tue, 27 Jun 2017 20:04:29 +0300: >Может кто-то знает что нужно подкрутить в новом ядре чтобы начал >правильно работать NAT? > Добавьте в iptables в таблицу raw правило для использования pptp: ... Это дело стало необходимым потому что то ли в свежих ядрах, то ли в дебиане (давно копал) теперь nat_helpers не применяются без явного на то указания. А просто "sysctl -w net.netfilter.nf_conntrack_helper=1" не помогает? Хм… Я, когда это дело начиналось, прочитал что теперь включать настраивать эти помощники нужно не параметрами модулей, а через raw-CT и что так оно рекомендовано. И с тех пор указываю порт и модуль явно. А в sysctl заглянуть и забыл. Но, думаю, sysctl тоже должен помочь. -- Написано с помощью почтового клиента Opera: http://www.opera.com/mail/
Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT
On Wed, Jun 28, 2017 at 11:13:18AM +0300, Михаил Касаджиков wrote: > Andrey Tataranovich писал(а) в своём письме Tue, 27 > Jun 2017 20:04:29 +0300: > >Может кто-то знает что нужно подкрутить в новом ядре чтобы начал > >правильно работать NAT? > > > > Добавьте в iptables в таблицу raw правило для использования pptp: ... > Это дело стало необходимым потому что то ли в свежих ядрах, то ли в > дебиане (давно копал) теперь nat_helpers не применяются без явного > на то указания. А просто "sysctl -w net.netfilter.nf_conntrack_helper=1" не помогает? -- Eugene Berdnikov
Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT
Andrey Tataranovich писал(а) в своём письме Tue, 27 Jun 2017 20:04:29 +0300: Доброго времени суток. Имеется сервер на Debian Jessie, который служит маршрутизатором сети. После апгрейдом ядра со штатного linux-image-3.16.0-4-amd64 (3.16.43-2+deb8u1) до linux-image-4.9.0-0.bpo.3-amd64 (4.9.30-2~bpo8+1) у клиентов сломалось подключение через pptp. Пробовал обновиться до linux-image-4.11.0-1-amd64 (4.11.6-1) из unstable, но ничего не поменялось. PPTP начинает работать, если перезагрузить маршрутизатор обратно на 3.16.43-2+deb8u1. Ввиду предстоящего апгрейда на stretch мне не хочется откатываться на старое ядро, да и маловероятно, что в ядре что-то глобально сломали - скорее всего я что-то упускаю относительно настроек. Когда pptp НЕ работает: $ sudo conntrack -L -p 47 gre 47 29 src=x.x.x.x dst=y.y.y.y srckey=0x0 dstkey=0x285d [UNREPLIED] src=y.y.y.y dst=z.z.z.z srckey=0x285d dstkey=0x0 mark=0 use=1 conntrack v1.4.2 (conntrack-tools): 1 flow entries have been shown. Когда pptp работает: $ sudo conntrack -L -p 47 gre 47 17995 src=x.x.x.x dst=y.y.y.y srckey=0x0 dstkey=0xbe6f src=y.y.y.y dst=z.z.z.z srckey=0xbe6f dstkey=0xc6ad [ASSURED] mark=0 use=1 conntrack v1.4.2 (conntrack-tools): 1 flow entries have been shown. x.x.x.x - локальный адрес клиента y.y.y.y - адрес VPN сервера z.z.z.z - внешний адрес маршрутизатора Может кто-то знает что нужно подкрутить в новом ядре чтобы начал правильно работать NAT? Добавьте в iptables в таблицу raw правило для использования pptp: root@debby2: ~# iptables-save -t raw # Generated by iptables-save v1.6.0 on Wed Jun 28 11:08:40 2017 *raw :PREROUTING ACCEPT [499445987:251052699965] :OUTPUT ACCEPT [118702475:62694078445] -A PREROUTING -p tcp -m tcp --dport 1723 -j CT --helper pptp COMMIT # Completed on Wed Jun 28 11:08:40 2017 Это дело стало необходимым потому что то ли в свежих ядрах, то ли в дебиане (давно копал) теперь nat_helpers не применяются без явного на то указания. -- Написано с помощью почтового клиента Opera: http://www.opera.com/mail/
Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT
On Wed, 28 Jun 2017 00:07:14 +0700 Леонид Кальмаев wrote: > Так а модуль то загружен pptp для того чтобы впн через нат полазил? $ grep pptp /etc/modules nf_nat_pptp nf_conntrack_pptp Насколько я знаю только эти два модуля нужны для работы pptp через NAT. $ lsmod | grep pptp nf_nat_pptp16384 0 nf_nat_proto_gre 16384 1 nf_nat_pptp nf_conntrack_pptp 16384 1 nf_nat_pptp nf_conntrack_proto_gre16384 1 nf_conntrack_pptp nf_nat 28672 4 nf_nat_pptp,nf_nat_proto_gre,nf_nat_masquerade_ipv4,nf_nat_ipv4 nf_conntrack 135168 11 nf_nat_pptp,nf_conntrack_ipv6,nf_conntrack_ipv4,ipt_MASQUERADE,nf_conntrack_pptp,nf_conntrack_netlink,nf_conntrack_proto_gre,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat И эти модули загружены в ядро. -- WBR, Andrey Tataranovich
Re: Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT
Так а модуль то загружен pptp для того чтобы впн через нат полазил? 28 июн. 2017 г. 12:04 ДП пользователь "Andrey Tataranovich" < tataranov...@gmail.com> написал: > Доброго времени суток. > > Имеется сервер на Debian Jessie, который служит маршрутизатором сети. > > После апгрейдом ядра со штатного linux-image-3.16.0-4-amd64 > (3.16.43-2+deb8u1) до linux-image-4.9.0-0.bpo.3-amd64 (4.9.30-2~bpo8+1) > у клиентов сломалось подключение через pptp. Пробовал обновиться до > linux-image-4.11.0-1-amd64 (4.11.6-1) из unstable, но ничего не > поменялось. > > PPTP начинает работать, если перезагрузить маршрутизатор обратно на > 3.16.43-2+deb8u1. Ввиду предстоящего апгрейда на stretch мне не хочется > откатываться на старое ядро, да и маловероятно, что в ядре что-то > глобально сломали - скорее всего я что-то упускаю относительно настроек. > > Когда pptp НЕ работает: > > $ sudo conntrack -L -p 47 > gre 47 29 src=x.x.x.x dst=y.y.y.y srckey=0x0 dstkey=0x285d > [UNREPLIED] src=y.y.y.y dst=z.z.z.z srckey=0x285d dstkey=0x0 mark=0 > use=1 conntrack v1.4.2 (conntrack-tools): 1 flow entries have been > shown. > > Когда pptp работает: > $ sudo conntrack -L -p 47 > gre 47 17995 src=x.x.x.x dst=y.y.y.y srckey=0x0 dstkey=0xbe6f > src=y.y.y.y dst=z.z.z.z srckey=0xbe6f dstkey=0xc6ad [ASSURED] mark=0 > use=1 conntrack v1.4.2 (conntrack-tools): 1 flow entries have been > shown. > > x.x.x.x - локальный адрес клиента > y.y.y.y - адрес VPN сервера > z.z.z.z - внешний адрес маршрутизатора > > Может кто-то знает что нужно подкрутить в новом ядре чтобы начал > правильно работать NAT? > > -- > WBR, Andrey Tataranovich > >
Маршрутизатор Debian Jessie с ядром из backports: не работает pptp через NAT
Доброго времени суток. Имеется сервер на Debian Jessie, который служит маршрутизатором сети. После апгрейдом ядра со штатного linux-image-3.16.0-4-amd64 (3.16.43-2+deb8u1) до linux-image-4.9.0-0.bpo.3-amd64 (4.9.30-2~bpo8+1) у клиентов сломалось подключение через pptp. Пробовал обновиться до linux-image-4.11.0-1-amd64 (4.11.6-1) из unstable, но ничего не поменялось. PPTP начинает работать, если перезагрузить маршрутизатор обратно на 3.16.43-2+deb8u1. Ввиду предстоящего апгрейда на stretch мне не хочется откатываться на старое ядро, да и маловероятно, что в ядре что-то глобально сломали - скорее всего я что-то упускаю относительно настроек. Когда pptp НЕ работает: $ sudo conntrack -L -p 47 gre 47 29 src=x.x.x.x dst=y.y.y.y srckey=0x0 dstkey=0x285d [UNREPLIED] src=y.y.y.y dst=z.z.z.z srckey=0x285d dstkey=0x0 mark=0 use=1 conntrack v1.4.2 (conntrack-tools): 1 flow entries have been shown. Когда pptp работает: $ sudo conntrack -L -p 47 gre 47 17995 src=x.x.x.x dst=y.y.y.y srckey=0x0 dstkey=0xbe6f src=y.y.y.y dst=z.z.z.z srckey=0xbe6f dstkey=0xc6ad [ASSURED] mark=0 use=1 conntrack v1.4.2 (conntrack-tools): 1 flow entries have been shown. x.x.x.x - локальный адрес клиента y.y.y.y - адрес VPN сервера z.z.z.z - внешний адрес маршрутизатора Может кто-то знает что нужно подкрутить в новом ядре чтобы начал правильно работать NAT? -- WBR, Andrey Tataranovich
Re: nat не натит сеть, которая недоступна напрямую
On Wed, May 29, 2013 at 03:19:46PM +0400, Mikhail A Antonov wrote: > 29.05.2013 14:27, Eugene Berdnikov пишет: ... > > лишнего. Не пишите "! -d 172.16.2.44/32" в правиле SNAT, оно там излишне > > потому что пакет с локальным dst_ip в POSTROUTING не попадёт. Но эта > > мелочь режет глаз, а с чайниками в netdev никто разговаривать не хочет. > Замечено следующее - если на сервере запущен какой-то сервис (пусть > будет почтовый сервер) и пользователь из локальной сети захочет > подключиться к этому серверу используя внешний адрес - у него ничего не > выйдет. Если в правиле указать что если dst свой - не натить - то всё > работает. Это странно, потому что, повторю, пакет с локальным dst_ip не должен попадать в POSTROUTING. И если указание локального адреса в правиле что-то меняет, это уже повод задуматься... Я подозреваю, что в Вашей конфигурации где-то дважды отрабатывает conntrack, потому что пакет проходит "транзитом" через сетевую подсистему HN два раза, заныривая по пути в виртуалку GW. И это обстоятельство может привести к каким-то ошибкам (багам) в районе nat'a, потому что для nat'a существеннен факт принадлежности пакета уже установленной коннекции. Для диагностики этого дела можно дополнить tcpdump и трассировку цепочек мониторингом коннекций. Запускайте conntrack -E (-n, -g, -j), кроме того, можно нашинковать цепочки iptables логгированием (-j LOG) состояний контрака, чтобы выяснить, в какой момент коннекция регистрируется ядром, где она переходит из NEW в ESTABLISHED и т.д. Возможно, тогда станет ясно, почему в POSTROUTING она неправильно обрабатывается. > пользователь с ноутом, на котором настроен почтовый клиент, который > подключается к серверу по имени mail.company.com. > Он всегда будет получать внешний адрес mail.company.com и пытаться к > нему подключиться. > Из внешней сети он нормально будет работать. Из внутренней - нет. Вообще говоря, в случае стандартной конфигурации шлюза подключение через внутренний интерфейс по внешнему адресу должно работать. > Можно нагородить костылей в виде заворачивания всех dns-запросов к себе > и отдавать локальные адреса локальным пользователям, используя view в > bind, но чем оно лучше? Для вьюшек не нужно заворачивать запросы на шлюзе, достаточно просто иметь собственный dns. :) Вьюшки это настолько полезный и удобный функционал, что я просто не представляю, как без них жить... Но это отдельный вопрос, никак не связанный с багами nat'а, a чем вьюшки лучше nat'а -- ну, наверное тем же, чем тёплое лучше мягкого. :) -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130529144024.gh3...@sie.protva.ru
Re: nat не натит сеть, которая недоступна напрямую
29.05.2013 14:27, Eugene Berdnikov пишет: > On Wed, May 29, 2013 at 01:41:11PM +0400, Mikhail A Antonov wrote: >> 29.05.2013 10:50, Eugene Berdnikov пишет: >>> Проверьте tcpdump'ом с обеих сторон и трассировкой правил iptables, >>> может быть, там всё-таки есть ошибка конфигурации. >> iptables приводил в первом письме. > Я сказал "трассировку": iptables -t raw -j TRACE. Я не верно понял. Спасибо, посмотрю на это подробнее. Ни разу не пользовался. >> tcpdump тоже смотрел: >> root@klon-gw:~# tcpdump -pni any -vvv host 213.79.76.3 > Здесь непонятно, через какие интерфейсы ходят пакеты. Вы думаете, что > знаете их точно, но постороннему человеку нужны доказательства. > К тому же с бриджами всё непросто, там можно отдельно слушать brX, > а можно те интерфейсы, которые к бриджу подключены, и получать > разные результаты. У меня слушается именно бридж. Про это прослушивание eth я в курсе. Когда буду писать в netdev разнесу tcpdump по интерфейсам >> на GW - пакет пришёл, пакет ушёл >> на HN - пакет пришёл на физику, ушёл в бридж, вернулся в vnet, прошёл >> через hn на выход на другую физику >> Всё работает, кроме ната. > Да, похоже на баг. Но таки проверьте, что что все интерфейсы и цепочки > проходятся в нужной последовательности. Я проверил. Но попробую трассировку применить. Если я нарвался на ядерный баг - куда мне писать? >>> В net...@vger.kernel.org. Но если нет готовности собирать у себя ядро >>> из свежего git'а и делать бисекты, а также пробовать патчи от тамошних >>> хакеров, то лучше туда не соваться, а искать обходной путь... IMHO. >> Эта конфигурация легко собирается на любой машине, на которой сможет >> работать kvm. Не думаю что тамошним хакерам будет удобно играть в >> испорченный телефон. Быстрее, проще и удобнее у себя такое же сделать. > Наивный человек, :) никто не будет городить такое страшилище с kvm, > а собирать ядро придётся Вам, если вообще кого-то эта тема заинтересует. > Причём заинтересовать может лишь если ситуация воспроизводится на самом > свежем ядре из git'а, которое сейчас под рукой у девелоперов. > > Нужен простой и понятный тесткейс: два интерфейса, одно правило, ничего > лишнего. Не пишите "! -d 172.16.2.44/32" в правиле SNAT, оно там излишне > потому что пакет с локальным dst_ip в POSTROUTING не попадёт. Но эта > мелочь режет глаз, а с чайниками в netdev никто разговаривать не хочет. Замечено следующее - если на сервере запущен какой-то сервис (пусть будет почтовый сервер) и пользователь из локальной сети захочет подключиться к этому серверу используя внешний адрес - у него ничего не выйдет. Если в правиле указать что если dst свой - не натить - то всё работает. Пример: пользователь с ноутом, на котором настроен почтовый клиент, который подключается к серверу по имени mail.company.com. Он всегда будет получать внешний адрес mail.company.com и пытаться к нему подключиться. Из внешней сети он нормально будет работать. Из внутренней - нет. Можно нагородить костылей в виде заворачивания всех dns-запросов к себе и отдавать локальные адреса локальным пользователям, используя view в bind, но чем оно лучше? -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: nat не натит сеть, которая недоступна напрямую
On Wed, May 29, 2013 at 01:41:11PM +0400, Mikhail A Antonov wrote: > 29.05.2013 10:50, Eugene Berdnikov пишет: > > > > Проверьте tcpdump'ом с обеих сторон и трассировкой правил iptables, > > может быть, там всё-таки есть ошибка конфигурации. > > iptables приводил в первом письме. Я сказал "трассировку": iptables -t raw -j TRACE. > tcpdump тоже смотрел: > root@klon-gw:~# tcpdump -pni any -vvv host 213.79.76.3 Здесь непонятно, через какие интерфейсы ходят пакеты. Вы думаете, что знаете их точно, но постороннему человеку нужны доказательства. К тому же с бриджами всё непросто, там можно отдельно слушать brX, а можно те интерфейсы, которые к бриджу подключены, и получать разные результаты. > на GW - пакет пришёл, пакет ушёл > на HN - пакет пришёл на физику, ушёл в бридж, вернулся в vnet, прошёл > через hn на выход на другую физику > Всё работает, кроме ната. Да, похоже на баг. Но таки проверьте, что что все интерфейсы и цепочки проходятся в нужной последовательности. > >> Если я нарвался на ядерный баг - куда мне писать? > > В net...@vger.kernel.org. Но если нет готовности собирать у себя ядро > > из свежего git'а и делать бисекты, а также пробовать патчи от тамошних > > хакеров, то лучше туда не соваться, а искать обходной путь... IMHO. > Эта конфигурация легко собирается на любой машине, на которой сможет > работать kvm. Не думаю что тамошним хакерам будет удобно играть в > испорченный телефон. Быстрее, проще и удобнее у себя такое же сделать. Наивный человек, :) никто не будет городить такое страшилище с kvm, а собирать ядро придётся Вам, если вообще кого-то эта тема заинтересует. Причём заинтересовать может лишь если ситуация воспроизводится на самом свежем ядре из git'а, которое сейчас под рукой у девелоперов. Нужен простой и понятный тесткейс: два интерфейса, одно правило, ничего лишнего. Не пишите "! -d 172.16.2.44/32" в правиле SNAT, оно там излишне потому что пакет с локальным dst_ip в POSTROUTING не попадёт. Но эта мелочь режет глаз, а с чайниками в netdev никто разговаривать не хочет. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130529102701.gb4...@protva.ru
Re: nat не натит сеть, которая недоступна напрямую
29.05.2013 10:50, Eugene Berdnikov пишет: > > Проверьте tcpdump'ом с обеих сторон и трассировкой правил iptables, > может быть, там всё-таки есть ошибка конфигурации. iptables приводил в первом письме. tcpdump тоже смотрел: root@klon-gw:~# tcpdump -pni any -vvv host 213.79.76.3 tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 23:58:36.450112 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.17.1.2 > 213.79.76.3: ICMP echo request, id 14733, seq 1, length 64 23:58:36.450161 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.17.1.2 > 213.79.76.3: ICMP echo request, id 14733, seq 1, length 64 root@klon-hn0:~# tcpdump -pni any -vvv host 213.79.76.3 tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 23:58:38.907749 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.17.1.2 > 213.79.76.3: ICMP echo request, id 14733, seq 1, length 64 23:58:38.907772 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.17.1.2 > 213.79.76.3: ICMP echo request, id 14733, seq 1, length 64 23:58:38.907958 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.17.1.2 > 213.79.76.3: ICMP echo request, id 14733, seq 1, length 64 23:58:38.907958 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.17.1.2 > 213.79.76.3: ICMP echo request, id 14733, seq 1, length 64 23:58:38.907967 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.17.1.2 > 213.79.76.3: ICMP echo request, id 14733, seq 1, length 64 на GW - пакет пришёл, пакет ушёл на HN - пакет пришёл на физику, ушёл в бридж, вернулся в vnet, прошёл через hn на выход на другую физику Всё работает, кроме ната. На br1 на HN повесил 172.17.1.1, потушив GW: root@klon-hn0:~# tcpdump -pni any -vvv host 213.79.76.3 tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 00:23:06.865122 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.17.1.2 > 213.79.76.3: ICMP echo request, id 16360, seq 1, length 64 00:23:06.865147 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.16.2.44 > 213.79.76.3: ICMP echo request, id 16360, seq 1, length 64 00:23:06.870937 IP (tos 0x0, ttl 56, id 24230, offset 0, flags [none], proto ICMP (1), length 84) 213.79.76.3 > 172.16.2.44: ICMP echo reply, id 16360, seq 1, length 64 00:23:06.870953 IP (tos 0x0, ttl 55, id 24230, offset 0, flags [none], proto ICMP (1), length 84) 213.79.76.3 > 172.17.1.2: ICMP echo reply, id 16360, seq 1, length 64 00:23:06.870956 IP (tos 0x0, ttl 55, id 24230, offset 0, flags [none], proto ICMP (1), length 84) 213.79.76.3 > 172.17.1.2: ICMP echo reply, id 16360, seq 1, length 64 Пакет проходит как надо. А вот что будет если включить нат на GW: root@klon-gw:~# tcpdump -pni any -vvv host 213.79.76.3 tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 00:41:28.400688 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.17.1.2 > 213.79.76.3: ICMP echo request, id 17548, seq 1, length 64 00:41:28.400717 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.17.0.2 > 213.79.76.3: ICMP echo request, id 17548, seq 1, length 64 00:41:28.407494 IP (tos 0x0, ttl 55, id 24226, offset 0, flags [none], proto ICMP (1), length 84) 213.79.76.3 > 172.17.0.2: ICMP echo reply, id 17548, seq 1, length 64 00:41:28.407504 IP (tos 0x0, ttl 54, id 24226, offset 0, flags [none], proto ICMP (1), length 84) 213.79.76.3 > 172.17.1.2: ICMP echo reply, id 17548, seq 1, length 64 tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 00:41:30.272168 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.17.1.2 > 213.79.76.3: ICMP echo request, id 17548, seq 1, length 64 00:41:30.272189 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.17.1.2 > 213.79.76.3: ICMP echo request, id 17548, seq 1, length 64 00:41:30.272635 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.17.0.2 > 213.79.76.3: ICMP echo request, id 17548, seq 1, length 64 00:41:30.272635 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.17.0.2 > 213.79.76.3: ICMP echo request, id 17548, seq 1, length 64 00:41:30.272648 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 172.16.2.44 > 213.79.76.3: ICMP echo request, id 17548, seq 1, length 64 00:41:30.278967 IP (tos 0x0, ttl 56, id 24226, offset 0, flags [none], proto ICMP (1), length 84) 213.79.76.3 > 172.16.2.44: ICMP echo reply, id 17548, seq 1, length 64 00:41:30.278988 IP (tos 0x0, ttl 55, id 24226, offset 0, flags [none], proto ICMP (1), length 84) 213
Re: nat не натит сеть, которая недоступна напрямую
29.05.2013 09:56, Dmitry A. Zhiglov пишет: > Мне эта тема тоже интересна. На squeeze в подобной конфигурации пакеты > вылетали не через виртуализованный гейт, а через ip, который был > присвоен "виртуальному коммутатору", то есть если создана > vnet0:192.168.0.1/24 и в ней находятся виртуалки, то пакет летит не с > виртуализованного шлюза виртуальной сети (например адрес гейта > 192.168.0.254) а с 192.168.0.1, который является "шлюзом" для vnet0 > "гипервизора". Какой IP ближе к пользователю - с того и летит. Это логично и нормально. Именно поэтому на бридже у HN нет адреса из сети с пользователями. > Еще, когда kvm создает виртуальные сети (они же "виртуальные > коммутаторы"), то на гипервизоре он настраивает как-то iptables. > Попробуйте посмотреть как изменяется iptables и возможно ebtables на > гипервизоре до создания (и/или активации погашенной) vnet0 и после > создания/активации, может там есть что подкрутить. У меня он "сам" iptables не трогает. При запуске виртуальной машины kvm создаёт vnet виртуальной машины и подключает его к созданному мной "вручную" бриджу. Больше kvm ничего не делает в плане сети. -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: nat не натит сеть, которая недоступна напрямую
On Wed, May 29, 2013 at 12:39:25AM +0400, Mikhail A Antonov wrote: > Если трафик проходит через GW и имеет адрес не GW - пакет проходит через > HN, но nat не выполняется. Проверьте tcpdump'ом с обеих сторон и трассировкой правил iptables, может быть, там всё-таки есть ошибка конфигурации. > Если я нарвался на ядерный баг - куда мне писать? В net...@vger.kernel.org. Но если нет готовности собирать у себя ядро из свежего git'а и делать бисекты, а также пробовать патчи от тамошних хакеров, то лучше туда не соваться, а искать обходной путь... IMHO. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130529065052.gw4...@protva.ru
Re: nat не натит сеть, которая недоступна напрямую
29 мая 2013 г., 0:39 пользователь Mikhail A Antonov написал: > 28.05.2013 23:58, Eugene Berdnikov пишет: >> On Tue, May 28, 2013 at 10:40:39PM +0400, Mikhail A Antonov wrote: >> [skip] >>> Есть идеи что это и почему оно работает не так, как предполагается? >> Стык бриджа с ip-nat довольно редко применяется, он плохо отлажен, >> здесь есть хорошие шансы найти несколько новых ядерных багов... > Я пробовал повесить на br1, который сбриджован с eth0, который смотрит в > сеть с пользователями IP 172.17.1.1/24 (потушив виртуалку GW и убрав > маршрут из таблицы маршрутизации) - нат заработал. > Если нат включить на GW - то процесс ната выполняется дважды, но > пользователи получают интернет. > Если трафик проходит через GW и имеет адрес не GW - пакет проходит через > HN, но nat не выполняется. > > Если я нарвался на ядерный баг - куда мне писать? > > Интересно, а на xen этот баг повторяется? Есть счастливчики с такой > конфигурацией с xen? Мне эта тема тоже интересна. На squeeze в подобной конфигурации пакеты вылетали не через виртуализованный гейт, а через ip, который был присвоен "виртуальному коммутатору", то есть если создана vnet0:192.168.0.1/24 и в ней находятся виртуалки, то пакет летит не с виртуализованного шлюза виртуальной сети (например адрес гейта 192.168.0.254) а с 192.168.0.1, который является "шлюзом" для vnet0 "гипервизора". Еще, когда kvm создает виртуальные сети (они же "виртуальные коммутаторы"), то на гипервизоре он настраивает как-то iptables. Попробуйте посмотреть как изменяется iptables и возможно ebtables на гипервизоре до создания (и/или активации погашенной) vnet0 и после создания/активации, может там есть что подкрутить.
Re: nat не натит сеть, которая недоступна напрямую
28.05.2013 23:58, Eugene Berdnikov пишет: > On Tue, May 28, 2013 at 10:40:39PM +0400, Mikhail A Antonov wrote: > [skip] >> Есть идеи что это и почему оно работает не так, как предполагается? > Стык бриджа с ip-nat довольно редко применяется, он плохо отлажен, > здесь есть хорошие шансы найти несколько новых ядерных багов... Я пробовал повесить на br1, который сбриджован с eth0, который смотрит в сеть с пользователями IP 172.17.1.1/24 (потушив виртуалку GW и убрав маршрут из таблицы маршрутизации) - нат заработал. Если нат включить на GW - то процесс ната выполняется дважды, но пользователи получают интернет. Если трафик проходит через GW и имеет адрес не GW - пакет проходит через HN, но nat не выполняется. Если я нарвался на ядерный баг - куда мне писать? Интересно, а на xen этот баг повторяется? Есть счастливчики с такой конфигурацией с xen? -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: nat не натит сеть, которая недоступна напрямую
On Tue, May 28, 2013 at 10:40:39PM +0400, Mikhail A Antonov wrote: [skip] > Есть идеи что это и почему оно работает не так, как предполагается? Стык бриджа с ip-nat довольно редко применяется, он плохо отлажен, здесь есть хорошие шансы найти несколько новых ядерных багов... Я под 2.6.30 сталкивался с тем, что в направлении ethX->brX пакеты не натятся, хотя в обратном направлении brX->ethX всё нормально. При этом трассировка показывала, что пакеты идут по PREROUTING и пролетают мимо правила DNAT, как это им удаётся -- непонятно. :-) Нужно было копаться в сорцах ядра, но я не стал париться, быстро решил свою проблему через -J REDIRECT и юзерспейсовый форвардер. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130528195848.gg3...@sie.protva.ru
nat не натит сеть, которая недоступна напрямую
Здравствуйте. Имею проблему с nat - правило есть, преобразования не происходит. Свежеустановленный debian wheezy. ~# uname -a Linux klon-hn0 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux ~# iptables --version iptables v1.4.14 Есть железная машина [HN], на которой запускаются виртуалки. ~# ip a 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc mq master br1 state UP qlen 1000 link/ether 88:51:fb:28:fa:2c brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 1500 qdisc mq state UP qlen 1000 link/ether 88:51:fb:28:fa:2d brd ff:ff:ff:ff:ff:ff inet 172.16.2.44/24 brd 172.16.2.255 scope global eth1 inet6 2001:67c:2158:a039:8a51:fbff:fe28:fa2d/64 scope global dynamic valid_lft 86248sec preferred_lft 14248sec inet6 fe80::8a51:fbff:fe28:fa2d/64 scope link valid_lft forever preferred_lft forever 4: br0: mtu 1500 qdisc noqueue state UP link/ether fe:54:00:00:d2:81 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/28 brd 172.17.0.15 scope global br0 inet6 fe80::6c53:b6ff:fef6:a74c/64 scope link valid_lft forever preferred_lft forever 5: br1: mtu 1500 qdisc noqueue state UP link/ether 88:51:fb:28:fa:2c brd ff:ff:ff:ff:ff:ff inet 172.17.0.17/28 brd 172.17.0.31 scope global br1 inet6 fe80::8a51:fbff:fe28:fa2c/64 scope link valid_lft forever preferred_lft forever 6: vnet0: mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN qlen 500 link/ether fe:54:00:00:d2:81 brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fe00:d281/64 scope link valid_lft forever preferred_lft forever 7: vnet1: mtu 1500 qdisc pfifo_fast master br1 state UNKNOWN qlen 500 link/ether fe:54:00:12:84:dc brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fe12:84dc/64 scope link valid_lft forever preferred_lft forever Вот так выглядят бриджи: ~# brctl show bridge namebridge idSTP enabledinterfaces br08000.fe54d281novnet0 br18000.8851fb28fa2cnoeth0 vnet1 Таблица маршрутизации: ~# ip r default via 172.16.2.1 dev eth1 172.16.2.0/24 dev eth1 proto kernel scope link src 172.16.2.44 172.17.0.0/28 dev br0 proto kernel scope link src 172.17.0.1 172.17.0.16/28 dev br1 proto kernel scope link src 172.17.0.17 172.17.1.0/24 via 172.17.0.2 dev br0 Собсно правило NAT: ~# iptables-save -t nat # Generated by iptables-save v1.4.14 on Tue May 28 20:42:38 2013 *nat :PREROUTING ACCEPT [1066:99540] :INPUT ACCEPT [5:339] :OUTPUT ACCEPT [1:80] :POSTROUTING ACCEPT [864:77910] -A POSTROUTING ! -d 172.16.2.44/32 -o eth1 -j SNAT --to-source 172.16.2.44 COMMIT # Completed on Tue May 28 20:42:38 2013 Т.е. схематично сеть выглядит так: [(eth1:172.16.2.44)-HN-(br0:172.17.0.1)]~~~[(eth0:172.17.0.2)-GW-(eth1:172.17.1.1)]===[(eth0:172.17.1.2)-USER] Трафик с GW, проходящий через HN - натится а вот трафик от USER (обычная машина, включённая в eth0 на HN) - не натится т.е. tcpdump -pni eth1 на HN показывает трафик с IP-адресом от USER, хотя должен был понатить GW является kvm-вируалкой, которая физически живёт на машине HN её eth0 сбриждован с br0, который в реальные eth не смотрит eth1 от GW сбриджован с br1, который физически уходит на eth0 HN Пересечений по интерфейсам (физическим и логическим) я не наблюдаю Вот адреса на GW: ~# ip a 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:00:d2:81 brd ff:ff:ff:ff:ff:ff inet 172.17.0.2/28 brd 172.17.0.15 scope global eth0 inet6 fe80::5054:ff:fe00:d281/64 scope link valid_lft forever preferred_lft forever 3: eth1: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:12:84:dc brd ff:ff:ff:ff:ff:ff inet 172.17.1.1/24 brd 172.17.1.255 scope global eth1 inet 192.168.15.205/24 scope global eth1 inet6 fe80::5054:ff:fe12:84dc/64 scope link valid_lft forever preferred_lft forever Трафик самой GW уходящий в интернет через HN нормально натится. Трафик из сети 172.17.1.0/24 (которая напрямую HN не видит) до 172.17.0.1 (адрес HN) ходит, но дальше - не натится. Имею довольно большое количество установок где натить надо и сети, доступные напрямую, и сети, которые так же зароучены через другие машины - и там всё работает. Физически на машине HN на eth0 висит локалка и iLO от самой машины. Если на eth0 (т.е. на br1) повесить IP из 172.17.1.0/24 и iLO поставить адрес из той же сети, то трафик не пойдёт через машину GW. На GW планируется поставить прозрачную проксю для офиса и возможно трафикосчиталку. На железную машину, которая занимается запуском виртуалок, проксю ставить не хочу. Ставить непонятную
Re: NAT
Ivan Shmakov writes: >>>>>> Sergey Korobitsin writes: > > […] > > > Мне вот интересны ещё всякие разновидности NAT: симметричный, > > full-cone, и т. п. Где такое пишут, например? > > Пишут в RFC 3489. Впрочем, в отменяющем его RFC 5389 находим: > > --cut: urn:ietf:rfc:5389 -- > […] Furthermore, classic STUN's algorithm for classification of NAT > types was found to be faulty, as many NATs did not fit cleanly into > the types defined there. > --cut: urn:ietf:rfc:5389 -- > > IOW, введение этих разновидностей порядка на деле не добавило. Спасибо, это исчерпало и мой вопрос тоже. -- ** * jabber: free...@jabber.mipt.ru * * Registered linux user #546240* ** -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehlw95an@ws00.freehck.ru
Re: NAT
>>>>> Sergey Korobitsin writes: […] > Мне вот интересны ещё всякие разновидности NAT: симметричный, > full-cone, и т. п. Где такое пишут, например? Пишут в RFC 3489. Впрочем, в отменяющем его RFC 5389 находим: --cut: urn:ietf:rfc:5389 -- […] Furthermore, classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there. --cut: urn:ietf:rfc:5389 -- IOW, введение этих разновидностей порядка на деле не добавило. -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86wqzo3kfo@gray.siamics.net
Re: NAT
Artem Chuprina ☫ → To debian-russian@lists.debian.org @ Thu, Sep 20, 2012 13:19 +0400 > Dmitrii Kashin -> debian-russian@lists.debian.org @ Thu, 20 Sep 2012 > 10:27:48 +0400: > > DK> Не посоветует ли сообщество какой-нибудь литературы, в которой были бы > DK> описаны тонкости работы NAT также толково, как у Эндрю Таненбаума > DK> описаны тонкости работы TCP/IP? > > Мне казалось, что при хорошем понимании работы TCP/IP, даже без > тонкостей, все тонкости работы NAT очевидны. Ну, добавить man iptables > (действия DNAT, SNAT и MASQUERADE), если его настраивать. Если они не > очевидны, то понимания работы TCP/IP нет, и начинать надо отсюда. Мне вот интересны ещё всякие разновидности NAT: симметричный, full-cone, и т.п. Где такое пишут, например? -- Bright regards, Sergey Korobitsin, Chief Research Officer Arta Software, http://arta.kz/ xmpp:underta...@jabber.arta.kz -- Наилучший путь предсказать будущее — создать его. -- Фраза на собрании в XEROX PARC в 1971 году —Алан Кей (Alan Key) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120920092343.gf10...@undertaker.dev.lan.arta.kz
Re: NAT
Dmitrii Kashin -> debian-russian@lists.debian.org @ Thu, 20 Sep 2012 10:27:48 +0400: DK> Не посоветует ли сообщество какой-нибудь литературы, в которой были бы DK> описаны тонкости работы NAT также толково, как у Эндрю Таненбаума DK> описаны тонкости работы TCP/IP? Мне казалось, что при хорошем понимании работы TCP/IP, даже без тонкостей, все тонкости работы NAT очевидны. Ну, добавить man iptables (действия DNAT, SNAT и MASQUERADE), если его настраивать. Если они не очевидны, то понимания работы TCP/IP нет, и начинать надо отсюда. DK> Интересуют проблемы, связанные с NAT при использовании TCP и UDP. DK> Методы его обхода - VPN, STUN и что там еще есть. Собственно, метод его обхода один - VPN. А уж какая реализация VPN берется и как настраивается - это зависит от возможностей машин на концах и параноидальности админов посредине. Но по этой области нужно скорее гуглить обзоры, чем искать книжки. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d31hcarb@wizzle.ran.pp.ru
NAT
Не посоветует ли сообщество какой-нибудь литературы, в которой были бы описаны тонкости работы NAT также толково, как у Эндрю Таненбаума описаны тонкости работы TCP/IP? Интересуют проблемы, связанные с NAT при использовании TCP и UDP. Методы его обхода - VPN, STUN и что там еще есть. Заранее спасибо. -- ** * jabber: free...@jabber.mipt.ru * * Registered linux user #546240* ** -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fw6dky3f@ws00.freehck.ru
Re: Доступ к машине за nat
openvpn допустим на 443 порт повесить на linux-host (A), а другие сервера конектится к нему будут. У меня так настроено - чудесно работает. Создание сертификатов и конфигов клиенту у меня делает скрипт. Смотри вложение. 24 июня 2011 г. 18:52 пользователь Ed написал: > Дано: > 1. linux-host (A) у меня под боком, со статическим IP. > 2. много десятков удалённых linux-хостов (B1, B2, ); на них есть доступ > в интернет, возможно с серым ip-адресом (например GPRS); > > все хосты в моём полном распоряжении. > > Требуется: > иметь воможность организовать ssh-сессию с A на любой из Bx. > > Как это лучше организовать? > > Я знаю два решения: > - openvpn; > - reverse ssh port forwarding. > > openvpn пользуюсь сейчас, в режиме static key, не нравится количество > телодвижений на добавление нового туннеля. > переход на клиент/серверные сертификаты по-моему ситуацию не исправит. > > ssh также с первого взгляда не очень удобен в конфигурации с множеством > клиентов. > > при этом оба инструмента избыточны, мне нужен только проброс порта из-под > nat, никакого шифрования не требуется. > > может быть я просмотрел какое-то простое и удобное решение? > > > -- > To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/4e04b2bb.9060...@yandex.ru > > 1openvpn_client Description: Binary data
Re: Доступ к машине за nat
On 2011.06.24 at 19:52:27 +0400, Ed wrote: > > openvpn пользуюсь сейчас, в режиме static key, не нравится > количество телодвижений на добавление нового туннеля. > переход на клиент/серверные сертификаты по-моему ситуацию не исправит. > > ssh также с первого взгляда не очень удобен в конфигурации с > множеством клиентов. > > при этом оба инструмента избыточны, мне нужен только проброс порта > из-под nat, никакого шифрования не требуется. > > может быть я просмотрел какое-то простое и удобное решение? И никто не вспомнил про существование у ssh ключика -w, позволяющего организовать полноценную vpn, а не просто проброс порта. Понятно, что это решение тоже избыточное, но позволяет организовать vpn с использованием более простой ключевой инфраструктуры ssh. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110627091218.ga12...@wagner.pp.ru
Re: Доступ к машине за nat
25.06.2011 12:25, Andrey Rahmatullin пишет: > On Sat, Jun 25, 2011 at 02:29:21AM +0400, Mikhail A Antonov wrote: Дано: 1. linux-host (A) у меня под боком, со статическим IP. 2. много десятков удалённых linux-хостов (B1, B2, ); на них есть доступ в интернет, возможно с серым ip-адресом (например GPRS); все хосты в моём полном распоряжении. Требуется: иметь воможность организовать ssh-сессию с A на любой из Bx. Как это лучше организовать? >>> IPv6 >>> >> Ой гемор, если провайдер не даёт. Туннель на туннеле и туннелем погоняет > Зато если с обеих сторон запустить miredo, больше никакой настройки не > требуется. > Замучаешься узнавать какой у кого адрес - они всегда динамические. Ну или заморочки с dyndns. Нет, я не против IPv6 и teredo в частности, но в некоторых местах провайдеры ТАКОЕ творят с udp-трафиком что их хочется убить на месте. Потому я не очень поддерживаю идею с teredo. ИМХО, здесь openvpn будет более универсальным и правильным решением. -- Best regards, Mikhail. signature.asc Description: OpenPGP digital signature
Re: Доступ к машине за nat
On Sat, Jun 25, 2011 at 02:29:21AM +0400, Mikhail A Antonov wrote: > >> Дано: > >> 1. linux-host (A) у меня под боком, со статическим IP. > >> 2. много десятков удалённых linux-хостов (B1, B2, ); на них есть > >> доступ в интернет, возможно с серым ip-адресом (например GPRS); > >> > >> все хосты в моём полном распоряжении. > >> > >> Требуется: > >> иметь воможность организовать ssh-сессию с A на любой из Bx. > >> > >> Как это лучше организовать? > > IPv6 > > > Ой гемор, если провайдер не даёт. Туннель на туннеле и туннелем погоняет Зато если с обеих сторон запустить miredo, больше никакой настройки не требуется. -- WBR, wRAR signature.asc Description: Digital signature
Re: Доступ к машине за nat
2011/6/24 Ed : > Дано: > 1. linux-host (A) у меня под боком, со статическим IP. > 2. много десятков удалённых linux-хостов (B1, B2, ); на них есть доступ > в интернет, возможно с серым ip-адресом (например GPRS); > > все хосты в моём полном распоряжении. > > Требуется: > иметь воможность организовать ssh-сессию с A на любой из Bx. > > Как это лучше организовать? На каждом из Bx вставить в автозагрузку autossh -2 -fN -M 2000(1,2,3,4,5...) -R 2202(1,2,3,4,5...):localhost:22 IP.of.A.host На A ходить на соотв. localhost:2202x. -- С уважением, Константин Матюхин
Re: Доступ к машине за nat
24.06.2011 19:52, Ed пишет: Дано: 1. linux-host (A) у меня под боком, со статическим IP. 2. много десятков удалённых linux-хостов (B1, B2, ); на них есть доступ в интернет, возможно с серым ip-адресом (например GPRS); все хосты в моём полном распоряжении. Требуется: иметь воможность организовать ssh-сессию с A на любой из Bx. A (statIPv4) + Bх (dyndns + iptables[statIPv4:] + denyhosts + ssh[Port ; PermitRootLogin no]) в ssh также возможен проброс портов 1 (webmin) или 5900 (vnc) или etc --- jabber shell bot + закрытая конференция[login:pass] =) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e057a49.9070...@mail.ru
Re: Доступ к машине за nat
24.06.2011 20:01, Andrey Rahmatullin пишет: > On Fri, Jun 24, 2011 at 07:52:27PM +0400, Ed wrote: >> Дано: >> 1. linux-host (A) у меня под боком, со статическим IP. >> 2. много десятков удалённых linux-хостов (B1, B2, ); на них есть >> доступ в интернет, возможно с серым ip-адресом (например GPRS); >> >> все хосты в моём полном распоряжении. >> >> Требуется: >> иметь воможность организовать ssh-сессию с A на любой из Bx. >> >> Как это лучше организовать? > IPv6 > Ой гемор, если провайдер не даёт. Туннель на туннеле и туннелем погоняет -- Best regards, Mikhail. signature.asc Description: OpenPGP digital signature
Re: Доступ к машине за nat
On 06/24/2011 03:52 PM, Ed wrote: Дано: 1. linux-host (A) у меня под боком, со статическим IP. 2. много десятков удалённых linux-хостов (B1, B2, ); на них есть доступ в интернет, возможно с серым ip-адресом (например GPRS); все хосты в моём полном распоряжении. Требуется: иметь воможность организовать ssh-сессию с A на любой из Bx. Как это лучше организовать? Я знаю два решения: - openvpn; - reverse ssh port forwarding. openvpn пользуюсь сейчас, в режиме static key, не нравится количество телодвижений на добавление нового туннеля. Если вы хотите залогиниться на машину по ssh, вам все равно лучше сделать сертификат. (Вы их можете наштамповать сразу штук 50 и потом переписывать). Что еще вам надо сделать, что бы подключить новую машину к openvpn ? reverse ssh port forwarding - тоже удобно, там будут порты их где-то надо помнить/записывать - можно сделать алиасы в .zshrc alias -g fh="uxterm -e ssh -t user@server_a.com 'ssh -p 20xx user@localhost' &! exit" , а у openvpn - ip адреса серые-статические можно прописать, в файле /ccd/$common_name (последний берется из сертификата который пытается залогиниться) внутри - одна строчка: ifconfig-push 192.168.xx.xx 255.255.255.0 Что вы хотите упростить ? Может быть вам нужен интерфейс для создания сертификатов ? -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/iu2s6i$7f2$1...@dough.gmane.org
Re: Доступ к машине за nat
Sergey Korobitsin ☫ → To Ed @ Fri, Jun 24, 2011 22:00 +0600 > Ed ☫ → To debian-russian@lists.debian.org @ Fri, Jun 24, 2011 19:52 +0400 > > Port Knoking, но это если ip белый. Тьфу, knocking. Прошу прощения за письмо в личную почту. -- Bright regards, Sergey Korobitsin, Chief Research Officer Arta Software, http://arta.kz/ xmpp:underta...@jabber.arta.kz -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110624161909.gl24...@undertaker.dev.lan.arta.kz
Re: Доступ к машине за nat
Ed ☫ → To debian-russian@lists.debian.org @ Fri, Jun 24, 2011 19:52 +0400 > Дано: > 1. linux-host (A) у меня под боком, со статическим IP. > 2. много десятков удалённых linux-хостов (B1, B2, ); на них есть > доступ в интернет, возможно с серым ip-адресом (например GPRS); > > все хосты в моём полном распоряжении. > > Требуется: > иметь воможность организовать ssh-сессию с A на любой из Bx. > > Как это лучше организовать? > > Я знаю два решения: > - openvpn; > - reverse ssh port forwarding. > > openvpn пользуюсь сейчас, в режиме static key, не нравится > количество телодвижений на добавление нового туннеля. > переход на клиент/серверные сертификаты по-моему ситуацию не исправит. > > ssh также с первого взгляда не очень удобен в конфигурации с > множеством клиентов. > > при этом оба инструмента избыточны, мне нужен только проброс порта > из-под nat, никакого шифрования не требуется. > > может быть я просмотрел какое-то простое и удобное решение? > Port Knoking, но это если ip белый. -- Bright regards, Sergey Korobitsin, Chief Research Officer Arta Software, http://arta.kz/ xmpp:underta...@jabber.arta.kz -- Технология ведет нас к сценарию, где капиталистический метод производства будет побежден и с течением времени заменен другим. В наших руках ростки будущих ролей, не признающие рыночных отношений. -- "Mikhail", автор бразильской локализации Гнутеллы. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110624160042.gk24...@undertaker.dev.lan.arta.kz
Re: Доступ к машине за nat
24.06.2011 18:52, Ed пишет: Дано: 1. linux-host (A) у меня под боком, со статическим IP. 2. много десятков удалённых linux-хостов (B1, B2, ); на них есть доступ в интернет, возможно с серым ip-адресом (например GPRS); все хосты в моём полном распоряжении. Требуется: иметь воможность организовать ssh-сессию с A на любой из Bx. Как это лучше организовать? Я знаю два решения: - openvpn; - reverse ssh port forwarding. openvpn пользуюсь сейчас, в режиме static key, не нравится количество телодвижений на добавление нового туннеля. переход на клиент/серверные сертификаты по-моему ситуацию не исправит. Почему же? Серверный сертификат генерится 1 (один) раз Подключение клиента = генерация сертификата+генерация конфига (опционально) + копирование ssh также с первого взгляда не очень удобен в конфигурации с множеством клиентов. Подключение клиента = генерация пары ключей + копирование публичного ключа на сервер + копирование приватного ключа клиенту + придумывание уникального номера порта при этом оба инструмента избыточны, мне нужен только проброс порта из-под nat, никакого шифрования не требуется. может быть я просмотрел какое-то простое и удобное решение? Все автоматизируется.. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e04b546.8030...@gmail.com
Re: Доступ к машине за nat
On Fri, Jun 24, 2011 at 07:52:27PM +0400, Ed wrote: > Дано: > 1. linux-host (A) у меня под боком, со статическим IP. > 2. много десятков удалённых linux-хостов (B1, B2, ); на них есть > доступ в интернет, возможно с серым ip-адресом (например GPRS); > > все хосты в моём полном распоряжении. > > Требуется: > иметь воможность организовать ssh-сессию с A на любой из Bx. > > Как это лучше организовать? IPv6 -- WBR, wRAR signature.asc Description: Digital signature
Доступ к машине за nat
Дано: 1. linux-host (A) у меня под боком, со статическим IP. 2. много десятков удалённых linux-хостов (B1, B2, ); на них есть доступ в интернет, возможно с серым ip-адресом (например GPRS); все хосты в моём полном распоряжении. Требуется: иметь воможность организовать ssh-сессию с A на любой из Bx. Как это лучше организовать? Я знаю два решения: - openvpn; - reverse ssh port forwarding. openvpn пользуюсь сейчас, в режиме static key, не нравится количество телодвижений на добавление нового туннеля. переход на клиент/серверные сертификаты по-моему ситуацию не исправит. ssh также с первого взгляда не очень удобен в конфигурации с множеством клиентов. при этом оба инструмента избыточны, мне нужен только проброс порта из-под nat, никакого шифрования не требуется. может быть я просмотрел какое-то простое и удобное решение? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e04b2bb.9060...@yandex.ru
Re: Debian Squeeze i386: nat\ip_forvard внутри VE OpenVZ
7 февраля 2011 г. 15:40 пользователь Вереск написал: > Добрый день! > > Есть безлимитный контейнер с 2-мя проброшенными внутрь сетевушками eth1 и > eth2. > /etc/network/interfaces: > > auto lo > iface lo inet loopback > > allow-hotplug eth1 > auto eth1 > iface eth1 inet static > address 10.0.0.35 > netmask 255.255.255.0 > gateway 10.0.0.1 > > allow-hotplug eth2 > auto eth2 > iface eth2 inet static > address 10.0.1.1 > netmask 255.255.255.0 > > > > На ноде применяю правила iptables для существующего там eth0, модули ядрёные > работают, всё хорошо. Пытаюсь применить правила внутри VE - не применяются. > Точнее даже не так: > 1. ip_forward включён и в ноде и VE > 2. все нужные модули загружены ДО старта VE и добавлены в конфиг VE > 3. правила INPUT в VE работают! проверил на SSH-демоне, всё хорошо пашет. А > вот правила цепочек NAT и FORWARD как-будто вообще не написаны. То есть, ни > полностью NAT "всем дать всё" не работает, ни FORWARD тем более. > 4. Сами правила проверенные, рабочие. > > Помогите, пожалуйста, второй день провожу в бесплодных попытках понять, чего > ему не хватает. не оно? http://wiki.openvz.org/Bridge_doesn't_forward_packets
Re: ipv6 за NAT
On Tue, Jun 01, 2010 at 10:33:41PM +0800, Denis Feklushkin wrote: > > Настраиваю ipv6 туннели от HE. > там 6to4? 6to4 не "там", 6to4 в ядре. А там 6in4. -- WBR, wRAR (ALT Linux Team) Powered by the ALT Linux fortune(6): * swi после суботнего апдейта сизифа (4 месяца спустя) обнаружил что ffmpeg играет те wmv3 что раньше не играл!! УРА FFMPEG ура порнухе порнуху и раньше крутило а вот онимэ не фсе )) так что ура хентаю ;) signature.asc Description: Digital signature
Re: ipv6 за NAT
On Tue, 1 Jun 2010 16:51:43 +0400 Валентин Лоскутов wrote: > Здравствуйте. > > Понимаю, что вопрос из разряда "взлетаю на самолёте; большую кнопку справа и > пять маленьких слева нажал, рычаг на себя потянул; что дальше?" но, тем не > менее > > Настраиваю ipv6 туннели от HE. там 6to4? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100601223341.02f2e...@gmail.com
ipv6 за NAT
Здравствуйте. Понимаю, что вопрос из разряда "взлетаю на самолёте; большую кнопку справа и пять маленьких слева нажал, рычаг на себя потянул; что дальше?" но, тем не менее Настраиваю ipv6 туннели от HE. На первой машине с белым статическим IP всё заработало сразу, без танцев с бубном. А вот на машине, спрятанной за NAT никак добиться работы не могу. На ней сделал всё так же, как и в первом случае (в качестве local пробовал указать и свой "серый" адрес, и тот, в который NAT'юсь) Подозреваю, что проблема где-то в роутерах "провайдера". NAT делается на Cisco 5300, которой рулю не я, а человек, который никогда с ipv6 не разбирался, да и не особо желающий разбираться. Но если я пойму что именно его нужно попросить сделать, то он, возможно, сделает. Я попросил "открыть протокол 41". Он сделал permit 41 any ip_в_который_я_NAT'юсь permit 41 ip_в_который_я_NAT'юсь any Это проблему не решило. С моей машины проблема выглядит так (2001:470:1f0a:12a8::2 - мой конец туннеля): $ ping6 ipv6.he.net -n PING ipv6.he.net(2001:470:0:64::2) 56 data bytes From 2001:470:1f0a:12a8::2 icmp_seq=1 Destination unreachable: Address unreachable From 2001:470:1f0a:12a8::2 icmp_seq=2 Destination unreachable: Address unreachable ^C --- ipv6.he.net ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 999ms $ ping6 ipv6.he.net PING ipv6.he.net(ipv6.he.net) 56 data bytes From radko1001-1-pt.tunnel.tserv6.fra1.ipv6.he.net icmp_seq=1 Destination unreachable: Address unreachable From Sinker-1-pt.tunnel.tserv6.fra1.ipv6.he.net icmp_seq=2 Destination unreachable: Address unreachable From radko1001-1-pt.tunnel.tserv6.fra1.ipv6.he.net icmp_seq=3 Destination unreachable: Address unreachable From Sinker-1-pt.tunnel.tserv6.fra1.ipv6.he.net icmp_seq=4 Destination unreachable: Address unreachable ^C --- ipv6.he.net ping statistics --- 4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3003ms На кошке в это время мои пакеты видны вот так: #sh ip cache flow | incl 216.66.80.30 Fa0.5 10.10.5.123 Null 216.66.80.3029 1 #sh ip cache flow | incl 216.66.80.30 Fa0.5 10.10.5.123 Null 216.66.80.3029 2 #sh ip cache flow | incl 216.66.80.30 Fa0.5 10.10.5.123 Null 216.66.80.3029 3 По словам того человека "access-list'ы всё это учитывают" и он предполагает проблему с NAT. Т.е. нужны или какие-то дополнительные настройки NAT, или дополнительный access-list для него. NAT динамический, что бы это ни значило. Может, у кого-то есть мысли как это поправить? До свидания. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100601165143.46c32...@rim2000m.ru
Re: PIDGIN видеозвонки, какие пор ты пробрасывать за NAT
Сам недавно заинтересовался вопросом видеозвонков. Дома примерно такая же схема. Давай потестим совместно как-ндь. 21.05.10, vanessa написал(а): > 21.05.10 07:39, Олег Ключкин написав(ла): >> А о каком протоколе идет речь? > XMPP > Я тут питался что-то искать в интернете, нашел следующее. Pidgin в > принципе неправильно поределил мой внешний IP, включил ему STUN после > чего адрес определился правильно. Но вот проверить раньше чем завтра > не смогу. Оно поможет или кто его знает ? > >> >> 20.05.10, vanessa написал(а): >>> Собственно вопрос сабжевый,комп за натом, что нужно пробросить чтоб >>> работили видеозвонки ? >>> >>> >>> -- >>> To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org >>> with a subject of "unsubscribe". Trouble? Contact >>> listmas...@lists.debian.org >>> Archive: http://lists.debian.org/4bf5928e.9000...@rabitsa.org.ua >>> >>> > > > -- > To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/4bf63768.7000...@rabitsa.org.ua > >
Re: PIDGIN видеозвонки, какие порты пробрасывать за NAT
21.05.10 07:39, Олег Ключкин написав(ла): А о каком протоколе идет речь? XMPP Я тут питался что-то искать в интернете, нашел следующее. Pidgin в принципе неправильно поределил мой внешний IP, включил ему STUN после чего адрес определился правильно. Но вот проверить раньше чем завтра не смогу. Оно поможет или кто его знает ? 20.05.10, vanessa написал(а): Собственно вопрос сабжевый,комп за натом, что нужно пробросить чтоб работили видеозвонки ? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bf5928e.9000...@rabitsa.org.ua -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bf63768.7000...@rabitsa.org.ua
Re: PIDGIN видеозвонки, каки е порты пробрасывать за NAT
On Thu, 20 May 2010 22:50:38 +0300 vanessa wrote: > Собственно вопрос сабжевый,комп за натом, что нужно пробросить чтоб > работили видеозвонки ? поднять UPnP-демона и пускай клиентские программы сами решают чего им надо пробрасывать? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100521035658.2143b...@gmail.com
Re: PIDGIN видеозвонки, какие пор ты пробрасывать за NAT
А о каком протоколе идет речь? 20.05.10, vanessa написал(а): > Собственно вопрос сабжевый,комп за натом, что нужно пробросить чтоб > работили видеозвонки ? > > > -- > To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/4bf5928e.9000...@rabitsa.org.ua > >
PIDGIN видеозвонки, какие п орты пробрасывать за NAT
Собственно вопрос сабжевый,комп за натом, что нужно пробросить чтоб работили видеозвонки ? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bf5928e.9000...@rabitsa.org.ua
Re: Раздача IPTV в NAT через сервер Linux
On Sun, 22 Nov 2009 17:29:38 +0200 Alex wrote: > > IPTV это что-то маркетинговое? надо бы конкретно протоколы > > UDP IP-multicast? signature.asc Description: PGP signature
Re: Раздача IPTV в NAT через сервер Linux
On Sun, 22 Nov 2009 15:22:29 +0200 Alex wrote: > Дома есть NAT. Раздаю интернет через сервер. Вроде все хорошо, все > качается, все лазится по интернетам. Но IPTV работает только на > сервере. А это плохо. > > OS Debian sid. > IP статический. IPTV это что-то маркетинговое? надо бы конкретно протоколы signature.asc Description: PGP signature
Re: Раздача IPTV в NAT через серве р Linux
22 ноября 2009 г. 18:22 пользователь Alex написал: > Дома есть NAT. Раздаю интернет через сервер. Вроде все хорошо, все > качается, все лазится по интернетам. Но IPTV работает только на > сервере. А это плохо. > > OS Debian sid. > IP статический. > Хватай его на сервере с помощью vlc, и с помощью же vlc вещай в локалку. -- Константин Фадеев
Re: VirtualBox + NAT + pppoe
26 октября 2009 г. 4:39 пользователь Prokofyev Vladislav < v.prokof...@gmail.com> написал: > 2009/10/25 Денис Рыбальченко > >>>>У меня одинаковые ip на разных одновременно открытых вирт машинах, это > >>>нормально? > > >>>Eсли я правильно понял суть вопроса то да, физически то у тебя айпи один > на хост машине. > > >>виртуальная машина является отдельным хостом в сети, поэтому адреса > должны быть разные. > >> > >Внутрение адреса или внешние? > > внутренние. > > >чтото я непойму, для нескольких внешних адресов на одной физической машине > нужно же по > >крайней мере пару сетевых карт как самый простой вариант + бокс настроеный > на коннект > >через сетевой мост, на каждую машину по девайсу, но в случае с НАТом > внешний айпи у всех > >машин будет один, ровно как и локальный. Если я чтото пропускаю > >просветите, буду весьма благодарен. > > у вас каша в голове. читайте про алиасинг сетевых интерфейсов, NAT и > маршрутизацию. > > -- > With best regards, > Vladislav Prokofyev > Ну за внутрение адреса я таки согласен, и спасибо почитаю, но зачем же так грубо... =\ -- WBR Dennis
Re: VirtualBox + NAT + pppoe
2009/10/25 Денис Рыбальченко >>>>У меня одинаковые ip на разных одновременно открытых вирт машинах, это >>>нормально? >>>Eсли я правильно понял суть вопроса то да, физически то у тебя айпи один на хост машине. >>виртуальная машина является отдельным хостом в сети, поэтому адреса должны быть разные. > >Внутрение адреса или внешние? внутренние. >чтото я непойму, для нескольких внешних адресов на одной физической машине нужно же по >крайней мере пару сетевых карт как самый простой вариант + бокс настроеный на коннект >через сетевой мост, на каждую машину по девайсу, но в случае с НАТом внешний айпи у всех >машин будет один, ровно как и локальный. Если я чтото пропускаю >просветите, буду весьма благодарен. у вас каша в голове. читайте про алиасинг сетевых интерфейсов, NAT и маршрутизацию. -- With best regards, Vladislav Prokofyev
Re: VirtualBox + NAT + pppoe
Денис Рыбальченко пишет: 25 октября 2009 г. 14:02 пользователь Prokofyev Vladislav mailto:v.prokof...@gmail.com>> написал: 2009/10/25 Денис Рыбальченко mailto:sauronfromli...@gmail.com>> >>У меня одинаковые ip на разных одновременно открытых вирт машинах, это >>нормально? >Eсли я правильно понял суть вопроса то да, физически то у тебя айпи один на хост машине. виртуальная машина является отдельным хостом в сети, поэтому адреса должны быть разные. -- With best regards, Vladislav Prokofyev Внутрение адреса или внешние? чтото я непойму, для нескольких внешних адресов на одной физической машине нужно же по крайней мере пару сетевых карт как самый простой вариант + бокс настроеный на коннект через сетевой мост, на каждую машину по девайсу, но в случае с НАТом внешний айпи у всех машин будет один, ровно как и локальный. Если я чтото пропускаю просветите, буду весьма благодарен. -- WBR Dennis обновил систему, поставил из squeeze virtulabox 3, да работает все из коробки, только не понятно почему на виртуальной машине аццкий пинг от 500ms до 5000ms, когда на реальной машине он не превышает 5ms -- С уважением, Aleksander Khoroshenkov, .masterhost -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: VirtualBox + NAT + pppoe
25 октября 2009 г. 14:02 пользователь Prokofyev Vladislav < v.prokof...@gmail.com> написал: > 2009/10/25 Денис Рыбальченко > > >>У меня одинаковые ip на разных одновременно открытых вирт машинах, это > >>нормально? > > >Eсли я правильно понял суть вопроса то да, физически то у тебя айпи один > на хост машине. > > виртуальная машина является отдельным хостом в сети, поэтому адреса должны > быть разные. > > -- > With best regards, > Vladislav Prokofyev > Внутрение адреса или внешние? чтото я непойму, для нескольких внешних адресов на одной физической машине нужно же по крайней мере пару сетевых карт как самый простой вариант + бокс настроеный на коннект через сетевой мост, на каждую машину по девайсу, но в случае с НАТом внешний айпи у всех машин будет один, ровно как и локальный. Если я чтото пропускаю просветите, буду весьма благодарен. -- WBR Dennis
Re: VirtualBox + NAT + pppoe
2009/10/25 Денис Рыбальченко >>У меня одинаковые ip на разных одновременно открытых вирт машинах, это >>нормально? >Eсли я правильно понял суть вопроса то да, физически то у тебя айпи один на хост машине. виртуальная машина является отдельным хостом в сети, поэтому адреса должны быть разные. -- With best regards, Vladislav Prokofyev
Re: VirtualBox + NAT + pppoe
25 октября 2009 г. 0:50 пользователь Prokofyev Vladislav < v.prokof...@gmail.com> написал: > > Не надо так делать. Последние версии VirtualBox поддерживают режим моста, > почитайте документацию. > > я не слежу за последними версиями vbox, поэтому не вижу смысла читать их > документацию. и странно почему у автора сразу все не заработало. > > > омг... только есть пару вопрос, на какой это машине делать(физической или > виртуальной)? И если делать на > > физической, то можно по конкретнее в чем смысл этих действий? > > на физической. создается бридж, который затем используется хостом и > гостевой машиной. 1 машина - 1 tap-интерфейс. > как вариант можно поставить более свежую версию, утверждают, что там уже > все из коробки работает. > > -- > With best regards, > Vladislav Prokofyev > таки да, из коробки всё работает, по крайней мере в 3.х версии, и по крайней мере у меня... >James Brown >У меня одинаковые ip на разных одновременно открытых вирт машинах, это >нормально? Если я правильно понял суть вопроса то да, физически то у тебя айпи один на хост машине. -- WBR Dennis
Re: VirtualBox + NAT + pppoe
> Не надо так делать. Последние версии VirtualBox поддерживают режим моста, почитайте документацию. я не слежу за последними версиями vbox, поэтому не вижу смысла читать их документацию. и странно почему у автора сразу все не заработало. > омг... только есть пару вопрос, на какой это машине делать(физической или виртуальной)? И если делать на > физической, то можно по конкретнее в чем смысл этих действий? на физической. создается бридж, который затем используется хостом и гостевой машиной. 1 машина - 1 tap-интерфейс. как вариант можно поставить более свежую версию, утверждают, что там уже все из коробки работает. -- With best regards, Vladislav Prokofyev
Re: VirtualBox + NAT + pppoe
Илья wrote: > > Стандартно vbox настраивает первый виртуальный адаптер nat как 10.0.2.15, > шлюз 10.0.2.2, и сервер DNS в 10.0.2.3. > > > У меня одинаковые ip на разных одновременно открытых вирт машинах, это нормально? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: VirtualBox + NAT + pppoe
24.10.09, 22:46, "Prokofyev Vladislav" : > подгрузить модуль tun, установить соответствующие утилиты, в virtualbox в > качестве интерфейса выбрать tap0. Не надо так делать. Последние версии VirtualBox поддерживают режим моста, почитайте документацию. > естественно можно (и даже нужно) засунуть это дело в скрипт. если нет dhcp > внутри сети, присвоить адрес br0 вручную. Это ближе, скорее всего в гостевой системе не правильно отрабатывает dhcp клиент, либо файрвол. -- С уважением, Илья Мингалиев. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: VirtualBox + NAT + pppoe
>Стоит debian lenny, выход в инет осуществляется через pppoe. Подскажите, как можно настроить virtualbox чтобы через >?>виртуальную машину можно было так же ходить в инет? Пробывал через NAT однако так я понимаю он пытается пробиться в инет >через интерфейс eth0. подгрузить модуль tun, установить соответствующие утилиты, в virtualbox в качестве интерфейса выбрать tap0. /usr/sbin/tunctl -t tap0 -u user /bin/chmod 666 /dev/net/tun /sbin/ifconfig eth0:0 192.168.0.1 netmask 255.255.255.0 /usr/sbin/brctl addbr br0 /sbin/ifconfig eth0 0.0.0.0 /usr/sbin/brctl addif br0 eth0:0 /sbin/dhclient br0 /usr/sbin/brctl addif br0 tap0 /sbin/ifconfig tap0 192.168.0.2 up /bin/bash -c 'echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp' естественно можно (и даже нужно) засунуть это дело в скрипт. если нет dhcp внутри сети, присвоить адрес br0 вручную. в таблице маршрутов должно быть примерно следующее: # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.20.5.00.0.0.0 255.255.255.0 U0 0 0 br0 192.168.0.0 0.0.0.0 255.255.255.0 U0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U0 0 0 tap0 0.0.0.010.20.5.1 0.0.0.0 UG 0 0 0 br0 0.0.0.010.20.5.1 0.0.0.0 UG 0 0 0 eth0 у меня работает стабильно. удачи :) -- With best regards, Vladislav Prokofyev
Re: VirtualBox + NAT + pppoe
24.10.09, 18:43, "Alexander Khoroshenkov" : > > WBR Dennis. > При загрузки LiveCD XoR Gentoo и поднятия интерфейса eth0, он резолвит > хосты, однако они не пингуются и не доступны. Походу что-то не то > таблицей роутинга. Хотя там прописано: > 10.0.2.0* 255.255.255.0 U 0 0 0 eth0 > loopback * 255.0.0.0 U 0 0 0 lo > default * 10.0.2.254U 0 0 0 eth0 Стандартно vbox настраивает первый виртуальный адаптер nat как 10.0.2.15, шлюз 10.0.2.2, и сервер DNS в 10.0.2.3. -- С уважением, Илья Мингалиев. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: VirtualBox + NAT + pppoe
Денис Рыбальченко пишет: Стоит debian lenny, выход в инет осуществляется через pppoe. Подскажите, как можно настроить virtualbox чтобы через виртуальную машину можно было так же ходить в инет? Пробывал через NAT однако так я понимаю он пытается пробиться в инет через интерфейс eth0 вообщето, насколько я помню, это при подключении через сетевой мост бокс стучиться в eth0, с натом нет такого, сетевой адаптер в настройках с NATом вообще не присутствует. Может поможет шамантсво c виртуальными адаптерами? У меня виндуза и фряха в боксе нормально ходят в инет с дефолтными настройками при том же pppoe. WBR Dennis. При загрузки LiveCD XoR Gentoo и поднятия интерфейса eth0, он резолвит хосты, однако они не пингуются и не доступны. Походу что-то не то таблицей роутинга. Хотя там прописано: 10.0.2.0* 255.255.255.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default * 10.0.2.254U 0 0 0 eth0 -- С уважением, Aleksander Khoroshenkov, .masterhost -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: VirtualBox + NAT + pppoe
> Стоит debian lenny, выход в инет осуществляется через pppoe. Подскажите, > как можно настроить virtualbox чтобы через виртуальную машину можно было так > же ходить в инет? Пробывал через NAT однако так я понимаю он пытается > пробиться в инет через интерфейс eth0 > вообщето, насколько я помню, это при подключении через сетевой мост бокс стучиться в eth0, с натом нет такого, сетевой адаптер в настройках с NATом вообще не присутствует. Может поможет шамантсво c виртуальными адаптерами? У меня виндуза и фряха в боксе нормально ходят в инет с дефолтными настройками при том же pppoe. WBR Dennis.
VirtualBox + NAT + pppoe
Стоит debian lenny, выход в инет осуществляется через pppoe. Подскажите, как можно настроить virtualbox чтобы через виртуальную машину можно было так же ходить в инет? Пробывал через NAT однако так я понимаю он пытается пробиться в инет через интерфейс eth0. -- С уважением, Aleksander Khoroshenkov, .masterhost -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Почтовый сервер за NAT ом
11.03.2009 17:45, ivan пишет:
> Извиняюсь за неточность изложения. Два сервера одинаково настроеные
> (дистрибутив, файервол/NAT, почтовый сервер). А стоят в разных сетях.
> Имеют разные доменные имена. Меж собой никак не взаимодействуют.
> С них, с обоих, поочередно, я пытался отправить тестовые письма на
> сервер который не принимает.
>> У меня есть предположение, что удалённый сервер пытается выполнить
>> callback, то есть создаёт встречное подключение и пытается проверить,
>> существует ли на вашем сервере такой почтовый ящик. Если удалённый
>> сервер попадает на тот почтовик, который ничего не знает об этой
>> учётке, он может сразу же разорвать подключение.
> Ну это было бы совсем жесткая проверка.
В формулировке "на сервере" она ещё и некорректная. Сервер, отправляющий
почту, не обязан её принимать для кого бы то ни было. И может просто
держать 25 порт закрытым. Проверяют наличие ящика в домене, в
соответствии с MX RR. И в этом случае никакой особой проблемы нет.
> В настоящее время, мне кажется, у всех закрыта такая опция - давать
> проверять наличие ящиков на сервере. Для спамеров это было бы кладом.
VRFY обычно закрыт. Но на RCPT TO принимающий сервер обязан отвечать
правду, никуда не денешься. Может отвечать правду не с первой попытки
("greylisting"), но это не препятствует верификации.
В общем, я согласен, что причина на уровне IP или TCP, а не на SMTP. Я
тут давеча жаловался в эту рассылку, что NAT через интерфейс типа VLAN
нормально заработал только после слова "ifconfig vlan274 promisc". Без
этого короткие диалоги из телнета проходили, а любой более длинный поток
данных по TCP - нет. Обнаружил я это, естественно, случайно: запустил
tcpdump - и под ним всё вдруг заработало :-)
Кстати, рекомендую попробовать.
А.Л.
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Почтовый сервер за NAT ом
10.03.2009 22:57, ivan пишет: > Есть у меня два почтовых сервера. Оба стоят во внутренней сети > (192.168.x.x) за НАТом. Работают три года, исправно получают и отсылают > в любые стороны. Но неделю назад появился сервер который не захотел > принимать от меня почту ни с одного из них. > Проверил отправку собщений телнетом со шлюза (с внешнего интерфейса, с > "белым" адресом) все отправляется, а из внутренней сети не желает. Какое имя говорит отправляющий почтовый сервер в HELO? И что будет, если в точности то же самое сказать из телнета с гейтовой машины? А.Л. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Странности с NAT.
Oleg Frolkov пишет: ... Сорри что плохо объяснил, как раз получается что имеет место быть двойной NAT. pppoe поднимается на модеме. На модеме этот роутер указан как DMZ хост и на на роутере поднят NAT. Загружены модули ip_conntrack_pptp и ip_nat_pptp (Насколько я понимаю они нужны для того чтобы через NAT ходили pptp сесиии.) Так вот компьютер с внутренней сети не может через эти 2 NAT-а поднять pptp соединения с наружними хостами. Аналогичная конфигурация в другом месте работает. причем сегодня там даже поставил тот модем с которым у меня ничего не получалось в предыдущем посте - т.е. это проблема не в NATе модема, через этот модем у меня не работало а в другом месте работает. При этом сам роутер может поднять pptp соединение с наружним хостом. Вот поднимаю я соединение с таким хостом с роутера - получаю на роутере 2 рабочих интерфейса: br-vlan10 - Мой интерфейс через который хожу в интернет. ppp10 - Второй интерфейс через который хожу в удаленную локалку (там тоже есть интернет). Теперь задача на компе с внутренней сети поднять еще одно pptp соединение до совершенно другого хоста (ну предположим мне потребовалось поднять VPN до какой-то сети) - получаем облом если роутинг до домашнего компа идет через br-vlan10.. если тут -же прописываю на роутере route add 1.2.3.4 dev ppp10 то pptp взлетает влет. То что я выспался ничуть не помогло. в общем-то конфигурация достаточно примитивна. Я бы не сказал. Интересно было бы взглянуть на таблицу маршрутизации Единственное за что можно зацепиться это странное поведение NAT или tcpdump. В общем с внутреннего компьютера (192.168.11.11) запускаю ping 1.2.3.4 В tcpdump на br-vlan10 вижу ping 192.168.11.11 -> 1.2.3.4 reply 1.2.3.4 ->192.168.1.11 Хотя должен видеть пинги не от внутреннего компьютера а от адреса внешнего интерфейса, уже это меня удивило. Поначалу подумал что у меня на роутере не работает NAT а умный ADSL модем это все переваривает. Убрал из конфига строчку с NAT - пинги перестали ходить... опять поствил - Что за строчка-то? пошли, но какого фига я в tcpdump на ВНЕШНЕМ интерфейсе вижу внутренние адреса? > Мне это кто-то может объяснить? Чудес-то не бывает -- имхо, NAT не работает на br-vlan10. Если роутинг до пингуемого хоста заворачиваю в поднятый тут-же ppp10 то вижу как положено пинги уходят и приходят от адреса этого ppp интерфейса а не от внутренних адресов: а на ppp10 - работает! Пока я вижу разницу только в этом. Там где с поднятием pptp все в порядке - tcpdump на внешнем интерфейсе показывает трафик с адресами этого внешнего интерфейса а не с внутренними. В этот раз я чуть яснее объяснил проблему? Сейчас, конечно, понятнее. Я бы - добился нормальной работы nat на интерфейсе br-vlan (кстати, какой модуль реализует br-vlan? может у этого модуля проблемы с nat?) - проверил работу туннеля через модем (какая модель?) при опущеном ppp10 на router-е, мне кажется , что не все модемы позволяют пропускать через себя более одного pptp-соединения. Даже это следует проверить в первую очередь, и вообще,нужен ли nat на br-vlan или можно обойтись маршрутизацией? Ну и tcpdump тебе в помощь! Кстати Ваш ответ увидел в рассылке, а вот своего вопроса не увидел :( - видимо где-то косяк. Оег. -- С уважением, Любимец Андрей Алексеевич -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Странности с NAT.
Andrey Lyubimets пишет: Oleg Frolkov пишет: Приветствую. Всю ночь бьюсь с непонятным поведением NAT, или tcpdump В общем ситуация такая WAN<->ADSL<->ROUER<->Comp Написано много, понятно мало. Непонятно как у тебя организовано адсл соединение - модем в режиме бриджа и pppoe на роутере или модем в режиме "роутер" и получается двойной nat - на модеме и на роутере( но тогда что за линк ppp10?) Сорри что плохо объяснил, как раз получается что имеет место быть двойной NAT. pppoe поднимается на модеме. На модеме этот роутер указан как DMZ хост и на на роутере поднят NAT. Загружены модули ip_conntrack_pptp и ip_nat_pptp (Насколько я понимаю они нужны для того чтобы через NAT ходили pptp сесиии.) Так вот компьютер с внутренней сети не может через эти 2 NAT-а поднять pptp соединения с наружними хостами. Аналогичная конфигурация в другом месте работает. причем сегодня там даже поставил тот модем с которым у меня ничего не получалось в предыдущем посте - т.е. это проблема не в NATе модема, через этот модем у меня не работало а в другом месте работает. При этом сам роутер может поднять pptp соединение с наружним хостом. Вот поднимаю я соединение с таким хостом с роутера - получаю на роутере 2 рабочих интерфейса: br-vlan10 - Мой интерфейс через который хожу в интернет. ppp10 - Второй интерфейс через который хожу в удаленную локалку (там тоже есть интернет). Теперь задача на компе с внутренней сети поднять еще одно pptp соединение до совершенно другого хоста (ну предположим мне потребовалось поднять VPN до какой-то сети) - получаем облом если роутинг до домашнего компа идет через br-vlan10.. если тут -же прописываю на роутере route add 1.2.3.4 dev ppp10 то pptp взлетает влет. То что я выспался ничуть не помогло. в общем-то конфигурация достаточно примитивна. Единственное за что можно зацепиться это странное поведение NAT или tcpdump. В общем с внутреннего компьютера (192.168.11.11) запускаю ping 1.2.3.4 В tcpdump на br-vlan10 вижу ping 192.168.11.11 -> 1.2.3.4 reply 1.2.3.4 ->192.168.1.11 Хотя должен видеть пинги не от внутреннего компьютера а от адреса внешнего интерфейса, уже это меня удивило. Поначалу подумал что у меня на роутере не работает NAT а умный ADSL модем это все переваривает. Убрал из конфига строчку с NAT - пинги перестали ходить... опять поствил - пошли, но какого фига я в tcpdump на ВНЕШНЕМ интерфейсе вижу внутренние адреса? Мне это кто-то может объяснить? Если роутинг до пингуемого хоста заворачиваю в поднятый тут-же ppp10 то вижу как положено пинги уходят и приходят от адреса этого ppp интерфейса а не от внутренних адресов: Пока я вижу разницу только в этом. Там где с поднятием pptp все в порядке - tcpdump на внешнем интерфейсе показывает трафик с адресами этого внешнего интерфейса а не с внутренними. В этот раз я чуть яснее объяснил проблему? Кстати Ваш ответ увидел в рассылке, а вот своего вопроса не увидел :( - видимо где-то косяк. Оег. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Странности с NAT.
Oleg Frolkov пишет: Приветствую. Всю ночь бьюсь с непонятным поведением NAT, или tcpdump В общем ситуация такая WAN<->ADSL<->ROUER<->Comp Написано много, понятно мало. Непонятно как у тебя организовано адсл соединение - модем в режиме бриджа и pppoe на роутере или модем в режиме "роутер" и получается двойной nat - на модеме и на роутере( но тогда что за линк ppp10?) На роутере стоит Debian etch и в iptables фактически 2 записи: #br-vlan10 интерфейс смотрящий на ADSL модем /sbin/iptables -t nat -A POSTROUTING -o br-vlan10 -j SNAT --to-source 192.168.10.10 #ppp10 интерфейс поднимающийся через br-vlan10 /sbin/iptables -t nat -A POSTROUTING -o ppp10 -j SNAT --to-source 192.168.168.168 INPUT,OUTPUT,FORWARD policy ALLOW Предположим Comp имеет адрес 192.168.11.11 ? Загружены всевозможные ip_conntrack_ и ip_nat_ В итоге имеем невозможность поднять pptp с Comp если роутинг до хоста к которому цепляемся идет через br-vlan10 и все поднимается нормально если я роутинг заворачиваю в ppp10 Мало того - при опущенном ppp10 я с Comp не могу поднять pptp до того хоста до которого прекрасно поднимается с роутера.. что-то у меня подозрение, что ppp10 - это pppoe -соединение к провайдеру, тогда такое поведение абсолютно нормально. При трассировке с помощью tcpdump была замечена следующая странность: ping Пакеты на исходящем интерфейсе br-vlan10 были не от NAT адреса, а от адреса внутреннего компьютера и ответы тоже приходили и tcpdump их видел как ответы внутреннему компьютеру. Сначала меня удивил сей факт что tcpdump получается уже заглядывает в таблицу NAT но потом я завернул роутинг до пингуемого хоста в ppp10 и там все стало выглядеть нормально Я в шоке всю ночь бьюсь как рыба об лед убирал строчку с NAT - хм - про какую строчку речь ответы как и положено перестали приходить на интерфейсе вижу ping 192.168.11.11 -> 1.2.3.4 В ответ тишина. Опять ставлю ping 192.168.11.11 -> 1.2.3.4 reply 1.2.3.4 ->192.168.1.11 На ppp10 как положено ping 192.168.10.10 -> 1.2.3.4 reply 1.2.3.4 -> 192.168.10.10 Такая катавасия у меня творится дома - не могу поднять с ноута pptp соединение до работы и других хостов. Приходится сначала поднимать на Linux шлюзе и заворачивать роутинг в него.. через ppp10 все работает. Есть еще другая машина с etch (На работе) - там все нормально в vlanXXX уходит все как положено и pptp с хостов локальной сети поднимаются. Подозрения падают только разве на br-vlanXXX (т.е. бридж) но с чего-бы? Обе машины подключены по ADSL к одному провайдеру.. В общем какие будут мысли? Куда копать? выспаться, собраться с мыслями и описать ситуацию попонятнее, а там, или сам поймёшь в чём проблема, или кто подскажет. :-) Олег. - С уважением, Любимец Андрей Алексеевич -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Странности с NAT.
Приветствую. Всю ночь бьюсь с непонятным поведением NAT, или tcpdump В общем ситуация такая WAN<->ADSL<->ROUER<->Comp На роутере стоит Debian etch и в iptables фактически 2 записи: #br-vlan10 интерфейс смотрящий на ADSL модем /sbin/iptables -t nat -A POSTROUTING -o br-vlan10 -j SNAT --to-source 192.168.10.10 #ppp10 интерфейс поднимающийся через br-vlan10 /sbin/iptables -t nat -A POSTROUTING -o ppp10 -j SNAT --to-source 192.168.168.168 INPUT,OUTPUT,FORWARD policy ALLOW Предположим Comp имеет адрес 192.168.11.11 Загружены всевозможные ip_conntrack_ и ip_nat_ В итоге имеем невозможность поднять pptp с Comp если роутинг до хоста к которому цепляемся идет через br-vlan10 и все поднимается нормально если я роутинг заворачиваю в ppp10 Мало того - при опущенном ppp10 я с Comp не могу поднять pptp до того хоста до которого прекрасно поднимается с роутера.. При трассировке с помощью tcpdump была замечена следующая странность: ping Пакеты на исходящем интерфейсе br-vlan10 были не от NAT адреса, а от адреса внутреннего компьютера и ответы тоже приходили и tcpdump их видел как ответы внутреннему компьютеру. Сначала меня удивил сей факт что tcpdump получается уже заглядывает в таблицу NAT но потом я завернул роутинг до пингуемого хоста в ppp10 и там все стало выглядеть нормально Я в шоке всю ночь бьюсь как рыба об лед убирал строчку с NAT - ответы как и положено перестали приходить на интерфейсе вижу ping 192.168.11.11 -> 1.2.3.4 В ответ тишина. Опять ставлю ping 192.168.11.11 -> 1.2.3.4 reply 1.2.3.4 ->192.168.1.11 На ppp10 как положено ping 192.168.10.10 -> 1.2.3.4 reply 1.2.3.4 -> 192.168.10.10 Такая катавасия у меня творится дома - не могу поднять с ноута pptp соединение до работы и других хостов. Приходится сначала поднимать на Linux шлюзе и заворачивать роутинг в него.. через ppp10 все работает. Есть еще другая машина с etch (На работе) - там все нормально в vlanXXX уходит все как положено и pptp с хостов локальной сети поднимаются. Подозрения падают только разве на br-vlanXXX (т.е. бридж) но с чего-бы? Обе машины подключены по ADSL к одному провайдеру.. В общем какие будут мысли? Куда копать? Олег. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: VLAN, NAT и promiscuou s mode
On Tue, Jan 13, 2009 at 02:31:36PM +0300, Alexey Lobanov wrote: > On 13.01.2009 10:46, Eugene Berdnikov wrote: > >> Во-первых, утверждение насчёт промиска было бы неплохо проверить, >> поставив промиск статически через ip или ifconfig. > > # ifconfig vlan274 promisc - помогло, трафик через SNAT пошёл. Пациента забавно перекосило... >> Во-вторых, отключите промиск в tcpdump'е (-np -i vlan274 -Uw file.pcap) >> и покажите, что в этот файл написалось для проблемной коннекции. > > А ничего хорошего. Делаю "ls" через ssh - команда отображается, > последние ack'и уходят, далее тишина и в шелле, и в tcpdump. Суть > понятна: короткие пакеты с одной буквой внутри проходят, полномерные с > длинной выдачей "ls" - нет, не принимаются интерфейсом. После перевода > интерфейса в promisc принимаются. Вроде бы логично :-) - но почему Суть неясна, и ничего логичного не вижу. Собственно, нужен file.pcap, а лучше два: один в режиме promisc, другой без. > только для SNAT? Собственные, не-SNAT'ные соединения с проблемного хоста > при этом работают совершенно нормально. Меня это наталкивает на мысль, что кривизна в маршрутизации по vlan'ам. То есть часть пакетов не тэгируется, и в дампе это будет видно. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: VLAN, NAT и promiscuous mode
On 13.01.2009 10:46, Eugene Berdnikov wrote: Во-первых, утверждение насчёт промиска было бы неплохо проверить, поставив промиск статически через ip или ifconfig. # ifconfig vlan274 promisc - помогло, трафик через SNAT пошёл. Некоторым образом это решение проблемы, спасибо. Интересно, какие могут быть осложнения от такого решения? Во-вторых, отключите промиск в tcpdump'е (-np -i vlan274 -Uw file.pcap) и покажите, что в этот файл написалось для проблемной коннекции. А ничего хорошего. Делаю "ls" через ssh - команда отображается, последние ack'и уходят, далее тишина и в шелле, и в tcpdump. Суть понятна: короткие пакеты с одной буквой внутри проходят, полномерные с длинной выдачей "ls" - нет, не принимаются интерфейсом. После перевода интерфейса в promisc принимаются. Вроде бы логично :-) - но почему только для SNAT? Собственные, не-SNAT'ные соединения с проблемного хоста при этом работают совершенно нормально. А.Л. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: VLAN, NAT и promiscuou s mode
On Mon, Jan 12, 2009 at 06:53:45PM +0300, Alexey Lobanov wrote: > -A POSTROUTING -s 10.0.3.0/255.255.255.0 -o vlan274 -p tcp -m tcp > --dport imaps -j SNAT --to-source 81.23.101.210 > > Результат: соединение через SNAT работает только тогда, когда на > интерфейс напущен сниффер, "tcpdump -i vlan274". Если сниффера нет, то > соединение устанавливается, но данные не передаются. > > Известно, что у провайдера, как это принято, имеется глюк с MTU в VLAN. > При стандартном MTU 1500 интерфейс именно так вёл себя (соединение есть, > данные не идут) на любом TCP, а не только на транслированном. Вылечено > "mtu 1280". Но при чём тут promiscuous mode и SNAT? Во-первых, утверждение насчёт промиска было бы неплохо проверить, поставив промиск статически через ip или ifconfig. Во-вторых, отключите промиск в tcpdump'е (-np -i vlan274 -Uw file.pcap) и покажите, что в этот файл написалось для проблемной коннекции. -- Eugene Berdnikov -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
VLAN, NAT и promiscuous mode
Hi all. Дано: исправно работавший гейт с нехитрым набором правил статического NAT для исходящих соединений: -A POSTROUTING -s 10.0.3.0/255.255.255.0 -o eth1 -p tcp -m tcp --dport imaps -j SNAT --to-source 81.23.101.210 На провайдерском интерфейсе подняли VLAN'ы по 802.1q, чтобы разделить его на Интернет и межофисный канал. auto vlan274 iface vlan274 inet static vlan-raw-device eth1 pre-up iptables-restore -A POSTROUTING -s 10.0.3.0/255.255.255.0 -o vlan274 -p tcp -m tcp --dport imaps -j SNAT --to-source 81.23.101.210 Результат: соединение через SNAT работает только тогда, когда на интерфейс напущен сниффер, "tcpdump -i vlan274". Если сниффера нет, то соединение устанавливается, но данные не передаются. Известно, что у провайдера, как это принято, имеется глюк с MTU в VLAN. При стандартном MTU 1500 интерфейс именно так вёл себя (соединение есть, данные не идут) на любом TCP, а не только на транслированном. Вылечено "mtu 1280". Но при чём тут promiscuous mode и SNAT? А.Л. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Пропал NAT: Другой случай
On Friday 19 December 2008 10:30:03 Александр Владимирович Екимов wrote: > Добрый день, All! > > Целый год гулял в интернете по ноуту через настольный ПК и беды не знал. > Настольному говорил: > iptables -t nat -A POSTROUTING -s 10.22.99.0/24 -o eth1 -j MASQUERADE > Соответственно ноуту давался ip из диапазона 10.22.99.0/24 > Внезапно тырнет на ноуте отвалился. > tcpdump на настольном при попытке получить что-нибудь из интернета ноутом > пишет: [отскипал кусман] Вопрос решен. Wi-fi карточки использовались с виндовыми драйверами через ndiswrapper. И так совпало,что ведро из testing + ndiswrapper + виндовый драйвер для broadcom 4318 давали на выходе tagged VLAN. Причем ноут с картой broadcom 4311 v2 и ведром testing amd64 работал без аномалий. Вопрос решил установкой ванильного 2.6.28. На обоих картах заработал драйвер b43. Единственная проблема - низкая скорость. Буду решать. -- Александр Владимирович Екимов, н.с. ООО "НПО "СПЕКТРОН"
Re: Пропал NAT: Другой случай
On Friday 19 December 2008 15:03:00 Dmitry Marin wrote: > Покотиленко Костик wrote: > > В Птн, 19/12/2008 в 14:04 +0300, Dmitry Marin пишет: > >> Александр Владимирович Екимов wrote: > >>> Ноут пингует только себя( 10.22.99.2) и настольный ПК( 10.22.99.1) > >>> С ноута я могу зайти по ssh на десктоп и все ОК. А дальше все глухо. Не > >>> локалки моего провайдера, не тырнета не видит. > >> > >> cat /proc/sys/net/ipv4/ip_forward на десктопе единицу дает? > > > > И результат команд в студию "host mail.ru" и "traceroute 65.65.65.65" на > > десктопе и на ноуте. > > В приватной переписке выяснилось, что icmp reply от внешних ресурсов > приходят и видны на беспроводном интерфейсе десктопа. А вот на таком-же > интерфейсе ноутбука их, похоже нет. > У меня что-то такое похожее было с ethernet из-за кривого на тот момент > драйвера. Переводом интерфейса в promisc.-mode какое-то время лечилось :-) > Какие идеи? Извиняюсь за приват. Давно не пользовался почтовым клиентом и нажал не на ту кнопочку :D promisc результатов не принес. -- Александр Владимирович Екимов, н.с. ООО "НПО "СПЕКТРОН"
Re: Пропал NAT: Другой случай
On Friday 19 December 2008 14:49:06 Покотиленко Костик wrote: > В Птн, 19/12/2008 в 14:04 +0300, Dmitry Marin пишет: > > Александр Владимирович Екимов wrote: > > > Ноут пингует только себя( 10.22.99.2) и настольный ПК( 10.22.99.1) > > > С ноута я могу зайти по ssh на десктоп и все ОК. А дальше все глухо. Не > > > локалки моего провайдера, не тырнета не видит. > > > > cat /proc/sys/net/ipv4/ip_forward на десктопе единицу дает? Да > > И результат команд в студию "host mail.ru" и "traceroute 65.65.65.65" на > десктопе и на ноуте. Десктоп: host mail.ru mail.ru A 194.67.57.226 mail.ru A 194.67.57.26 mail.ru A 194.67.57.126 traceroute 65.65.65.65 traceroute to 65.65.65.65 (65.65.65.65), 30 hops max, 40 byte packets 1 10.11.24.1 (10.11.24.1) 1.228 ms 1.427 ms 1.612 ms 2 cifra-cisco-37.gw.cifracom.ru (10.255.255.37) 1.362 ms 2.661 ms 3.821 ms 3 10.255.255.85 (10.255.255.85) 0.881 ms 0.977 ms 1.187 ms 4 10.255.255.97 (10.255.255.97) 2.576 ms 3.677 ms 3.678 ms 5 10.255.255.3 (10.255.255.3) 1.099 ms 1.086 ms 1.069 ms 6 border.cifracom.ru (195.189.80.33) 1.255 ms 1.586 ms 2.334 ms 7 te-0-2-0-0-2112.spb-bg1.bb.severen.net (93.174.240.241) 8.163 ms 6.079 ms te-0-2-0-0-2108.spb-bg1.bb.severen.net (93.174.240.237) 6.043 ms 8 sap-b2-link.telia.net (213.248.99.153) 1.728 ms 1.753 ms 1.739 ms 9 hls-b3-link.telia.net (80.91.252.246) 8.048 ms 8.040 ms 8.024 ms 10 s-bb1-pos6-2-0.telia.net (213.248.64.101) 15.032 ms 15.057 ms 15.047 ms 11 kbn-bb1-link.telia.net (213.248.65.142) 24.672 ms 24.720 ms 24.706 ms 12 nyk-bb1-link.telia.net (80.91.249.24) 116.071 ms 116.061 ms 117.183 ms 13 nyk-b2-link.telia.net (80.91.250.1) 109.811 ms 109.809 ms 109.768 ms 14 ex2-tg4-0.eqnwnj.sbcglobal.net (151.164.249.73) 108.990 ms 109.002 ms * 15 dist1.10g1-2.rcsntx.sbcglobal.net (151.164.243.182) 160.400 ms * * 16 se1-g5-2.rcsntx.sbcglobal.net (70.245.63.8) 159.025 ms 159.397 ms 159.388 ms 17 * * * [отскипал] 30 * * * ноут: host mail.ru connection timed out; no servers could be reached traceroute 65.65.65.65 traceroute to 65.65.65.65 (65.65.65.65), 30 hops max, 60 byte packets 1 * * * 2 (10.255.255.37) 5.059 ms 7.749 ms 8.014 ms 3 * * * 4 * * * [отскипал т.к. одни звезды] 30 * * * Вот такие пироги -- Александр Владимирович Екимов, н.с. ООО "НПО "СПЕКТРОН" -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Пропал NAT: Другой случай
Покотиленко Костик wrote: В Птн, 19/12/2008 в 14:04 +0300, Dmitry Marin пишет: Александр Владимирович Екимов wrote: Ноут пингует только себя( 10.22.99.2) и настольный ПК( 10.22.99.1) С ноута я могу зайти по ssh на десктоп и все ОК. А дальше все глухо. Не локалки моего провайдера, не тырнета не видит. cat /proc/sys/net/ipv4/ip_forward на десктопе единицу дает? И результат команд в студию "host mail.ru" и "traceroute 65.65.65.65" на десктопе и на ноуте. В приватной переписке выяснилось, что icmp reply от внешних ресурсов приходят и видны на беспроводном интерфейсе десктопа. А вот на таком-же интерфейсе ноутбука их, похоже нет. У меня что-то такое похожее было с ethernet из-за кривого на тот момент драйвера. Переводом интерфейса в promisc.-mode какое-то время лечилось :-) Какие идеи? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Пропал NAT: Другой случай
В Птн, 19/12/2008 в 14:04 +0300, Dmitry Marin пишет: > Александр Владимирович Екимов wrote: > > > Ноут пингует только себя( 10.22.99.2) и настольный ПК( 10.22.99.1) > > С ноута я могу зайти по ssh на десктоп и все ОК. А дальше все глухо. Не > > локалки моего провайдера, не тырнета не видит. > > cat /proc/sys/net/ipv4/ip_forward на десктопе единицу дает? И результат команд в студию "host mail.ru" и "traceroute 65.65.65.65" на десктопе и на ноуте. -- Покотиленко Костик -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Пропал NAT: Другой случай
Александр Владимирович Екимов wrote: Ноут пингует только себя( 10.22.99.2) и настольный ПК( 10.22.99.1) С ноута я могу зайти по ssh на десктоп и все ОК. А дальше все глухо. Не локалки моего провайдера, не тырнета не видит. cat /proc/sys/net/ipv4/ip_forward на десктопе единицу дает? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Пропал NAT: Другой случай
On Friday 19 December 2008 13:10:47 Roman Gushcha wrote: > On Fri, 19 Dec 2008 10:30:03 +0300 > > Александр Владимирович Екимов wrote: > > Добрый день, All! > > > > Целый год гулял в интернете по ноуту через настольный ПК и беды не знал. > > Настольному говорил: > > iptables -t nat -A POSTROUTING -s 10.22.99.0/24 -o eth1 -j MASQUERADE > > Эти магические записи до конца я не понимаю. Есть идеи? > > -- > > Александр Владимирович Екимов > > На ноуте винда. Которая похоже для разрешения имен запрашивает не > стандартный сервис через 53 порт, а что-то свое, по мультикасту. Надо с ней > и разбираться: что на ней указано в качестве днс-серверов? Еще сегодня утром эта винда называлась Debian lenny. IP ДНС сервера она принимает по dhcp(поднятый мной соответсвенно). Это ДНС моего провайдера > > Чтобы убедиться что проблема связана именно с разрешением имен надо из > виндовой консоли попинговать что-нибудь по IP-адресу. Ноут пингует только себя( 10.22.99.2) и настольный ПК( 10.22.99.1) С ноута я могу зайти по ssh на десктоп и все ОК. А дальше все глухо. Не локалки моего провайдера, не тырнета не видит. Повторюсь. До этого около года все работало. Грешу на какие-то апдейты. -- Александр Владимирович Екимов, н.с. ООО "НПО "СПЕКТРОН"
Re: Пропал NAT: Другой случай
В Птн, 19/12/2008 в 13:05 +0300, Dmitry Marin пишет: > Покотиленко Костик wrote: > > В Птн, 19/12/2008 в 10:30 +0300, Александр Владимирович Екимов пишет: > >> Добрый день, All! > >> 10:22:21.282700 IP loop.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? > >> 251.0.0.224.in-addr.arpa. (42) > >> 10:22:23.040281 arp who-has loop.local tell unix-mobile.local > >> 10:22:23.040300 arp reply loop.local is-at 00:18:f3:95:e2:0e (oui Unknown) > >> 10:22:23.044301 IP unix-mobile.local.57091 > lbox.local.domain: 38073+ A? > >> weather.noaa.gov. (34) > >> > >> Эти магические записи до конца я не понимаю. Есть идеи? > > > > DNS? > > > > А не zeroconf вдруг заработал? mdns -- это же вроде что-то от Avahi? > Надо бы посмотреть чего с интерфейсом творится. Так или иначе, проблема похоже в разрешении имён. -- Покотиленко Костик -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Пропал NAT: Друг ой случай
On Fri, 19 Dec 2008 10:30:03 +0300 Александр Владимирович Екимов wrote: > Добрый день, All! > > Целый год гулял в интернете по ноуту через настольный ПК и беды не знал. > Настольному говорил: > iptables -t nat -A POSTROUTING -s 10.22.99.0/24 -o eth1 -j MASQUERADE > Соответственно ноуту давался ip из диапазона 10.22.99.0/24 > Внезапно тырнет на ноуте отвалился. > tcpdump на настольном при попытке получить что-нибудь из интернета ноутом > пишет: > > listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes > 10:22:18.041971 IP unix-mobile.local.57091 > lbox.local.domain: 38073+ A? > weather.noaa.gov. (34) > 10:22:18.044092 IP lbox.local.domain > unix-mobile.local.57091: 38073 1/3/2 A > weather.noaa.gov (139) > 10:22:18.150625 IP6 fe80::218:f3ff:fe95:e20e.mdns > ff02::fb.mdns: 0[|domain] > 10:22:18.150717 IP loop.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? > 2.99.22.10.in-addr.arpa. (41) > 10:22:18.155304 IP unix-mobile.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 > (Cache flush) PTR[|domain] > 10:22:18.274606 IP6 fe80::218:f3ff:fe95:e20e.mdns > ff02::fb.mdns: 0[|domain] > 10:22:18.274694 IP loop.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? > 251.0.0.224.in-addr.arpa. (42) > 10:22:19.278605 IP6 fe80::218:f3ff:fe95:e20e.mdns > ff02::fb.mdns: 0[|domain] > 10:22:19.278709 IP loop.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? > 251.0.0.224.in-addr.arpa. (42) > 10:22:21.282601 IP6 fe80::218:f3ff:fe95:e20e.mdns > ff02::fb.mdns: 0[|domain] > 10:22:21.282700 IP loop.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? > 251.0.0.224.in-addr.arpa. (42) > 10:22:23.040281 arp who-has loop.local tell unix-mobile.local > 10:22:23.040300 arp reply loop.local is-at 00:18:f3:95:e2:0e (oui Unknown) > 10:22:23.044301 IP unix-mobile.local.57091 > lbox.local.domain: 38073+ A? > weather.noaa.gov. (34) > > Эти магические записи до конца я не понимаю. Есть идеи? > -- > Александр Владимирович Екимов На ноуте винда. Которая похоже для разрешения имен запрашивает не стандартный сервис через 53 порт, а что-то свое, по мультикасту. Надо с ней и разбираться: что на ней указано в качестве днс-серверов? Чтобы убедиться что проблема связана именно с разрешением имен надо из виндовой консоли попинговать что-нибудь по IP-адресу. Адрес можно узнать с линукс-машины, например так: host www.ru -- Roman S. Gushcha -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Пропал NAT: Другой случай
Покотиленко Костик wrote: В Птн, 19/12/2008 в 10:30 +0300, Александр Владимирович Екимов пишет: Добрый день, All! 10:22:21.282700 IP loop.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 10:22:23.040281 arp who-has loop.local tell unix-mobile.local 10:22:23.040300 arp reply loop.local is-at 00:18:f3:95:e2:0e (oui Unknown) 10:22:23.044301 IP unix-mobile.local.57091 > lbox.local.domain: 38073+ A? weather.noaa.gov. (34) Эти магические записи до конца я не понимаю. Есть идеи? DNS? А не zeroconf вдруг заработал? mdns -- это же вроде что-то от Avahi? Надо бы посмотреть чего с интерфейсом творится. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Пропал NAT: Другой случай
В Птн, 19/12/2008 в 10:30 +0300, Александр Владимирович Екимов пишет: > Добрый день, All! > > Целый год гулял в интернете по ноуту через настольный ПК и беды не знал. > Настольному говорил: > iptables -t nat -A POSTROUTING -s 10.22.99.0/24 -o eth1 -j MASQUERADE > Соответственно ноуту давался ip из диапазона 10.22.99.0/24 > Внезапно тырнет на ноуте отвалился. > tcpdump на настольном при попытке получить что-нибудь из интернета ноутом > пишет: > > listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes > 10:22:18.041971 IP unix-mobile.local.57091 > lbox.local.domain: 38073+ A? > weather.noaa.gov. (34) > 10:22:18.044092 IP lbox.local.domain > unix-mobile.local.57091: 38073 1/3/2 A > weather.noaa.gov (139) > 10:22:18.150625 IP6 fe80::218:f3ff:fe95:e20e.mdns > ff02::fb.mdns: 0[|domain] > 10:22:18.150717 IP loop.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? > 2.99.22.10.in-addr.arpa. (41) > 10:22:18.155304 IP unix-mobile.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 > (Cache flush) PTR[|domain] > 10:22:18.274606 IP6 fe80::218:f3ff:fe95:e20e.mdns > ff02::fb.mdns: 0[|domain] > 10:22:18.274694 IP loop.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? > 251.0.0.224.in-addr.arpa. (42) > 10:22:19.278605 IP6 fe80::218:f3ff:fe95:e20e.mdns > ff02::fb.mdns: 0[|domain] > 10:22:19.278709 IP loop.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? > 251.0.0.224.in-addr.arpa. (42) > 10:22:21.282601 IP6 fe80::218:f3ff:fe95:e20e.mdns > ff02::fb.mdns: 0[|domain] > 10:22:21.282700 IP loop.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? > 251.0.0.224.in-addr.arpa. (42) > 10:22:23.040281 arp who-has loop.local tell unix-mobile.local > 10:22:23.040300 arp reply loop.local is-at 00:18:f3:95:e2:0e (oui Unknown) > 10:22:23.044301 IP unix-mobile.local.57091 > lbox.local.domain: 38073+ A? > weather.noaa.gov. (34) > > Эти магические записи до конца я не понимаю. Есть идеи? DNS? -- Покотиленко Костик -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Пропал NAT: Другой случай
Добрый день, All! Целый год гулял в интернете по ноуту через настольный ПК и беды не знал. Настольному говорил: iptables -t nat -A POSTROUTING -s 10.22.99.0/24 -o eth1 -j MASQUERADE Соответственно ноуту давался ip из диапазона 10.22.99.0/24 Внезапно тырнет на ноуте отвалился. tcpdump на настольном при попытке получить что-нибудь из интернета ноутом пишет: listening on wlan0, link-type EN10MB (Ethernet), capture size 96 bytes 10:22:18.041971 IP unix-mobile.local.57091 > lbox.local.domain: 38073+ A? weather.noaa.gov. (34) 10:22:18.044092 IP lbox.local.domain > unix-mobile.local.57091: 38073 1/3/2 A weather.noaa.gov (139) 10:22:18.150625 IP6 fe80::218:f3ff:fe95:e20e.mdns > ff02::fb.mdns: 0[|domain] 10:22:18.150717 IP loop.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 2.99.22.10.in-addr.arpa. (41) 10:22:18.155304 IP unix-mobile.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 (Cache flush) PTR[|domain] 10:22:18.274606 IP6 fe80::218:f3ff:fe95:e20e.mdns > ff02::fb.mdns: 0[|domain] 10:22:18.274694 IP loop.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 10:22:19.278605 IP6 fe80::218:f3ff:fe95:e20e.mdns > ff02::fb.mdns: 0[|domain] 10:22:19.278709 IP loop.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 10:22:21.282601 IP6 fe80::218:f3ff:fe95:e20e.mdns > ff02::fb.mdns: 0[|domain] 10:22:21.282700 IP loop.local.mdns > 224.0.0.251.mdns: 0 PTR (QM)? 251.0.0.224.in-addr.arpa. (42) 10:22:23.040281 arp who-has loop.local tell unix-mobile.local 10:22:23.040300 arp reply loop.local is-at 00:18:f3:95:e2:0e (oui Unknown) 10:22:23.044301 IP unix-mobile.local.57091 > lbox.local.domain: 38073+ A? weather.noaa.gov. (34) Эти магические записи до конца я не понимаю. Есть идеи? -- Александр Владимирович Екимов
Re: Пропал NAT
Sentinel wrote: Ядро самосборное, 2.6.23.12. Погуглил - и, если правильно понимаю, NAT из последних ядер убран. cat /usr/src/linux-source-.../.config grep CONFIG_IP что выдает ? проверте CONFIG_IP_NF_NAT=y Если у вас старый конфиг, то попробуйте сделать "make oldconfig" - он задаст вопросы только про новые или переименованные компоненты. Потом можно подредактировать через "make menuconfig". -- Sincerely, Nicholas -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Пропал NAT
Sentinel wrote: Коллеги, поможите советом. Ситуация: стандартный Etch, пытаюсь выполнить следующую команду iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE На что получаю: iptables v1.3.6: can't initialize iptables table `nat': Table does not exist (do you need to insmod?) Ядро самосборное, 2.6.23.12. Погуглил - и, если правильно понимаю, NAT Попробуйте стандартное ядро. Скорее всего дело в самосборности -- не собрали нужный модуль (кажется ip_nat.ko). Или попробуйте modprobe iptable_nat, если не сделали при сборке kernel module autoloading. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Пропал NAT
Sentinel пишет: > Коллеги, поможите советом. Ситуация: стандартный Etch, пытаюсь выполнить > следующую команду > > iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE > > На что получаю: iptables v1.3.6: can't initialize iptables table `nat': > Table does not exist (do you need to insmod?) > > Ядро самосборное, 2.6.23.12. Погуглил - и, если правильно понимаю, NAT > из последних ядер убран. К сожалению, в сетях полнейший профан, поэтому > не бейте за такой вопрос: как сделать то же самое, что делает > вышеупомянутая команда, но без NAT'a? Спасибо заранее. > > С уважением, Евгений. Начиная с некоторой версии изменились структура модулей для iptables. Конфиг, я так подозреваю взяли со старого ядра. Посмотрите настройки и включите модули для iptables (они там есть). Или пользуйтесь дистрибутивным ядром. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Пропал NAT
Коллеги, поможите советом. Ситуация: стандартный Etch, пытаюсь выполнить следующую команду iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE На что получаю: iptables v1.3.6: can't initialize iptables table `nat': Table does not exist (do you need to insmod?) Ядро самосборное, 2.6.23.12. Погуглил - и, если правильно понимаю, NAT из последних ядер убран. К сожалению, в сетях полнейший профан, поэтому не бейте за такой вопрос: как сделать то же самое, что делает вышеупомянутая команда, но без NAT'a? Спасибо заранее. С уважением, Евгений.
Re: Доступ по ssh к машине за NAT
В Пнд, 24/11/2008 в 23:42 +0300, Andrew N Golovkov пишет: > On Monday 24 November 2008 23:38:25 Alexander Tiurin wrote: > > Доброго времени суток! > > Есть машина за натом с фэйковым ипом и машина с реальным ипом в мире. > > Нужно организовать нечто, что бы можно было по ssh обращаться к > > машине за натом с машины с реальником. Сразу отмечу, что править > > правила nat нет возможности. > > ИМХО, напрашивается VPN (т.е. на машину в мире ставлю сервер ВПН и к > > нему цепляюсь машиной за натом), но это ИМХО и может можно идею > > реализовать попроще. > > Пните плиз в нужном направлении! > > Спасибо! > > VPN это не сложно. Тем более, что раз настроил - потом проще и надёжнее. -- Покотиленко Костик <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Доступ по ssh к машине за NAT
В Вто, 25/11/2008 в 11:26 +0300, Alexander Tiurin пишет: > > Правда, man page не помогла, ничего не понял .) > > Я тоже) Смотря о чём думать когда читаешь ;) > > А вот тут вполне доступное описание: > > http://www.howtoforge.com/reverse-ssh-tunneling > > Дополню http://linux-life.ru/book/SSH.html. На русском. -- Покотиленко Костик <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Доступ по ssh к машине за NAT
> Правда, man page не помогла, ничего не понял .) Я тоже) > А вот тут вполне доступное описание: > http://www.howtoforge.com/reverse-ssh-tunneling Дополню http://linux-life.ru/book/SSH.html. На русском.
Re: Доступ по ssh к машине за NAT
On Mon, 24 Nov 2008, Artem Chuprina wrote: man ssh. -R. Пожалуйста. Спасибо! Правда, man page не помогла, ничего не понял .) А вот тут вполне доступное описание: http://www.howtoforge.com/reverse-ssh-tunneling Ю.
Re: Доступ по ssh к машине за NAT
Alexander Tiurin -> debian-russian@lists.debian.org @ Mon, 24 Nov 2008 23:38:25 +0300: AT> Доброго времени суток! AT> Есть машина за натом с фэйковым ипом и машина с реальным ипом в мире. AT> Нужно организовать нечто, что бы можно было по ssh обращаться к AT> машине за натом с машины с реальником. Сразу отмечу, что править AT> правила nat нет возможности. AT> ИМХО, напрашивается VPN (т.е. на машину в мире ставлю сервер ВПН и к AT> нему цепляюсь машиной за натом), но это ИМХО и может можно идею AT> реализовать попроще. AT> Пните плиз в нужном направлении! AT> Спасибо! man ssh. -R. Пожалуйста. -- Artem Chuprina RFC2822: Jabber: [EMAIL PROTECTED] Реляционная база данных - это не единственный способ сделать дурацкий поиск. Victor Wagner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Доступ по ssh к машине за NAT
On Monday 24 November 2008 23:38:25 Alexander Tiurin wrote: > Доброго времени суток! > Есть машина за натом с фэйковым ипом и машина с реальным ипом в мире. > Нужно организовать нечто, что бы можно было по ssh обращаться к > машине за натом с машины с реальником. Сразу отмечу, что править > правила nat нет возможности. > ИМХО, напрашивается VPN (т.е. на машину в мире ставлю сервер ВПН и к > нему цепляюсь машиной за натом), но это ИМХО и может можно идею > реализовать попроще. > Пните плиз в нужном направлении! > Спасибо! VPN это не сложно.
Доступ по ssh к машине за NAT
Доброго времени суток! Есть машина за натом с фэйковым ипом и машина с реальным ипом в мире. Нужно организовать нечто, что бы можно было по ssh обращаться к машине за натом с машины с реальником. Сразу отмечу, что править правила nat нет возможности. ИМХО, напрашивается VPN (т.е. на машину в мире ставлю сервер ВПН и к нему цепляюсь машиной за натом), но это ИМХО и может можно идею реализовать попроще. Пните плиз в нужном направлении! Спасибо!
Re: Действие DROP в nat/POSTROUTING и nat/PREROUTING
В Вто, 29/07/2008 в 10:35 +0400, Stanislav Maslovski пишет: > On Tue, Jul 29, 2008 at 01:22:01PM +0700, Ivan Dubrov wrote: > > Alexander Tyurin wrote: > > > > Приветствую! > > Есть хост 192,168,1,20. Все последующие правила прописаны именно на этом > > хосте. > > > > При правиле > > iptables -A INPUT -p tcp -d 192.168.1.20 -j DROP > > доступа к сетевым ресурсам нет. Логично. > > > > При > > iptables -A OUTPUT -p tcp -s 192.168.1.20 -j DROP > > нет доступа к ресурсм сети. Логично. > > > > При > > iptables -t nat -A POSTROUTING -p tcp -s 192.168.1.20 -j DROP > > доступа нет. Вот тут уже интересно т.к. не понятно почему. > > > > При > > iptables -t nat -A PREROUTING -p tcp -d 192.168.1.20 -j DROP > > а вот это правило не понятно почему не действует. Никаких проблем с > > коннектом у хоста не возникает. Кто-нить может объяснить такую разницу в > > поведении 2х последних правил? > > > > Возможно, картинка поможет: http://wfrag.org/files/tables_traverse.jpg > > Картинки такие, увы, новичков с толку сбивают, так как создают ложное > представление, что _все_ пакеты идут через PREROUTING, например. Не проходят только локально сделанные. -- Покотиленко Костик <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Действие DROP в nat/POSTROUTING и nat/PREROUTING
В Вто, 29/07/2008 в 01:13 +0400, Alexander Tyurin пишет: > Приветствую! > Есть хост 192,168,1,20. Все последующие правила прописаны именно на > этом хосте. > При > iptables -t nat -A POSTROUTING -p tcp -s 192.168.1.20 -j DROP > > доступа нет. Вот тут уже интересно т.к. не понятно почему. > Первый пакет начинающий соединение (SYN) дропается, соединение не устанавливается, логично. > При > iptables -t nat -A PREROUTING -p tcp -d 192.168.1.20 -j DROP > а вот это правило не понятно почему не действует. Никаких проблем с > коннектом у хоста не возникает. Кто-нить может объяснить такую разницу > в поведении 2х последних правил? Первый пакет начинающий соединение (SYN) НЕ дропается, соединение устанавливается, остальные пакеты этого соединения в nat не попадут, логично. Однако, коннекты на эту машину не пройдут. Почитайте как работает conntrack и таблица nat в iptables. -- Покотиленко Костик <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Действие DROP в nat/POSTROUTING и nat/PREROUTING
В Срд, 30/07/2008 в 11:52 +0400, Stanislav Maslovski пишет: > Так чем же-таки отличаются входящие соединения от исходящих? :) Ну... входящие входят, исходящие выходят... чем они еще отличаются? Или ты о том, что входящие идут через PREROUTING, а исходящие через POSTROUTING и этим отличаются? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
