и все, тишина, дальне никаких сообщений или попыток перехода к init. На клавиатуру реагирует (enter - переход на строку вниз) Пробовал в качестве init указывать ядру /bin/bash, ситуация не меняется.
Чтож этой заразе нужно? :( Если взять этот винт и воткнуть в другую машину с via c3, intel p2 - все отлично грузится (при сборке ядра с pentium/pentium2)
Для тестирования сетевых девайсов (soho роутеры) на "устойчивость" nat разыскивается программа, которая могла бы эмулировать создание множества соединений (по tcp/udp) с заданным хостом.
Другими словами, софтварная эмуляция p2p клиента, стоящего за роутером - такой клиент создает от себя множество сессий и к нему из внешнего мира так же ломится новых соединений,nat на хардварных роутерах не всегда это выдерживает.
Может кто сталкивался с подобной проблемой? Есть ли такая софтинка? Под линукс желательно :)
Проблема. Мейл-хост с postfix + courier-imap имеет несколько разных сетевых интерфейсов с разными доменными именами. Возможно ли, не запуская несколько копий pop3/imap/postfix(smtp) указать им, что для разных интерфейсов они должны использовать разные сертификаты (при установлении TLS-соединения с клиентами)?
А то тот же thebat при попытке соединения с таким mail-хостом по smtp на mail2.host.com для отсылки почты видит, что присланный ему сертификат для доменного имени mail1.host.com не соответствует тому имени, с которым он соединился и обрывает сессию. Что, в принципе, логично.
Есть роутер, облуживающий локальную сеть, к которому подведено два канала в Интернет от разных провайдеров:
ip-mark=1
10.10.0.1
eth1 -------- gw 10.10.0.10
LAN ====== eth0 ROUTER
10.0.0.0/24 eth2 -------- gw 10.20.0.20
10.20.0.1
ip-mark=2
default gw роутера - eth2 (10.20.0.20)
Большинство пользователей пускается через канал eth1.
На машине так же стоит squid, который тоже работает через eth1.
Это реализовано через IP-Mark-и в iptables
iptables -t mangle -A OUTPUT -d !10.0.0.0/24 -m owner --uid-owner squid -j MARK --set-mark 1
iptables -A FORWARD -s 10.0.0.0/24 -d !10.0.0.1 -j MARK --set-mark 2
Далее в iproute2 все эти марки разруливаются:
ip rule ls
0: from all lookup local
10010: from 10.10.0.1 lookup channel_1
10020: from all fwmark 0x1 lookup channel_1
10030: from all fwmark 0x2 lookup channel_2
10040: from 10.10.0.1 lookup channel_1
10050: from 10.20.0.1 lookup channel_2
32766: from all lookup main
32767: from all lookup default
ip route ls table channel_1
10.10.0.10 dev eth1 scope link src 10.10.0.1
10.20.0.20 dev eth2 scope link src 10.20.0.1
10.0.0.0/24 dev eth0 scope link src 10.0.0.1
default via 10.10.0.10 dev eth1
ip route ls table channel_2
10.10.0.10 dev eth1 scope link src 10.10.0.1
10.20.0.20 dev eth2 scope link src 10.20.0.1
10.0.0.0/24 dev eth0 scope link src 10.0.0.1
default via 10.20.0.20 dev eth2
Т.е. если пакет пометили MARK=1, идем через первый канал, если MARK=2
- через второй.
Если пакет уходит с IP адреса eth1, то через первый, с IP адреса eth2
- через второй.
Все отлично работает, почти.
По какой то загадочной причине, если с ICQ серверов приходят пакеты
(к нам) c порта 20480 (мы их не заказывали, по крайней мере явно,
так как на эти (icq) подсети разрешен коннект лишь на порт 5190):
tcpdump -i eth1 -tnn port 20480
listening on eth1, link-type EN10MB (Ethernet), capture size 68 bytes
IP 64.12.163.198.20480 > 10.10.0.1.46575: F 989230390:989230390(0) ack 3759679222 win 16384
IP 64.12.163.198.20480 > 10.10.0.1.46532: F 3850546332:3850546332(0) ack 3695983447 win 16384
IP 64.12.163.198.20480 > 10.10.0.1.46350: R 2325480714:2325480714(0) ack 3423810008 win 16384
IP 64.12.163.198.20480 > 10.10.0.1.46534: F 803308875:803308875(0) ack 3697429387 win 16384
IP 64.12.163.198.20480 > 10.10.0.1.46459: F 1838867399:1838867399(0) ack 3558304478 win 16384
IP 64.12.163.198.20480 > 10.10.0.1.46582: F 2365749742:2365749742(0) ack 3762615305 win 16384
IP 64.12.163.198.20480 > 10.10.0.1.46580: F 1896503484:1896503484(0) ack 3751645506 win 16384
IP 64.12.163.198.20480 > 10.10.0.1.46584: F 919800549:919800549(0) ack 3763930573 win 16384
IP 64.12.163.198.20480 > 10.10.0.1.46586: F 818128566:818128566(0) ack 3759034461 win 16384
IP 64.12.163.198.20480 > 10.10.0.1.46587: F 878087222:878087222(0) ack 3760221868 win 16384
IP 64.12.163.198.20480 > 10.10.0.1.46644: F 625144099:625144099(0) ack 3834986459 win 16384
IP 64.12.163.198.20480 > 10.10.0.1.46621: F 1294591151:1294591151(0) ack 3788650210 win 16384
IP 64.12.163.198.20480 > 10.10.0.1.46542: F 39607421:39607421(0) ack 3708106639 win 16384
то роутер отвечает почему то не с eth1 (хотя вроде как, если не левый пакет приходит на этот интерфейс и адрес 10.10.0.1, то отвечать мы должны же с этого адреса и интерфейса?), а отвечает роутер с eth2:
tcpdump -i eth2 -tnn
listening on eth2, link-type EN10MB (Ethernet), capture size 68 bytes
IP 10.10.0.1.46620 > 64.12.163.198.20480: R 3796472795:3796472795(0) win 0
IP 10.10.0.1.46640 > 64.12.163.198.20480: R 3824027914:3824027914(0) win 0
IP 10.10.0.1.46533 > 64.12.163.198.20480: R 3687496548:3687496548(0) win 0
IP 10.10.0.1.46595 > 64.12.163.198.20480: R 3770445592:3770445592(0) win 0
IP 10.10.0.1.46578 > 64.12.163.198.20480: R 3764669375:3764669375(0) win 0
IP 10.10.0.1.46576 > 64.12.163.198.20480: R 3747630349:3747630349(0) win 0
IP 10.10.0.1.46610 > 64.12.163.198.20480: R 3784433598:3784433598(0) win 0
IP 10.10.0.1.46588 > 64.12.163.198.20480: R 3761104850:3761104850(0) win 0
IP 10.10.0.1.46659 > 64.12.163.198.20480: R 3858790926:3858790926(0) win 0
IP 10.10.0.1.46669 > 64.12.163.198.20480: R 3847494617:3847494617(0) win 0
IP 10.10.0.1.46641 > 64.12.163.198.20480: R 3825184905:3825184905(0) win 0
(в примере приведены возможно не те самые пакеты ответов,
которые ушли в ответ на запросы из первого лога tcpdump-а,
но факт именно в этом, запрос на eth1, ответ - на eth2).
Собственно, я никак не могу понять, какого %^&*($%^& ответы с 10.10.0.1(адрес принадлежит eth1), уходят с eth2?
Хотя в ip rule явно прописано другое? :(
Ядро 2.6.7, iptables 1.2.9, iproute2-2.6.7.20040608, Gentoo Linux
На ядре 2.6.8.1 и iptables 1.2.11 ситуация не меняется.
Люди, подскажите, как организовать "ipsec transport mode" с автоматической генерацией ключей между двумя хостами?
Пусть есть два хоста,
net(10.10.0.0/24)=10.0.0.1 --- 10.0.0.2=net(10.20.0.0/24)
как между ними организовать трафик ipsec соединение в режиме транспорта? С туннелем все впорядке, в простейшем случае для левой машины(10.0.0.1) конфиги выглядят так:
/etc/ipsec.conf
spdadd 10.10.0.0/24 10.20.0.0/24 any -P out ipsec
esp/tunnel/10.0.0.1-10.0.0.2/require;
spdadd 10.20.0.0/24 10.10.0.0/24 any -P in ipsec
esp/tunnel/10.0.0.2-10.0.0.1/require;
/etc/racoon.conf
remote 10.0.0.2 {
exchange_mode main;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 5;
}
}
sainfo address 10.10.0.0/24 any address 10.20.0.0/24 any {
encryption_algorithm 3des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
Для правой все зеркально отображаем. Запускаем демон racoon, туннель
поднимается, трафик ходит.
А как подобного (с автоматической генерацией ключей) добиться для
"transport mode"?
Делаю по аналогии
/etc/ipsec.conf
spdadd 10.0.0.1/32 10.0.0.2/32 any -P out ipsec
esp/transport//require
ah/transport//require
spdadd 10.0.0.2/32 10.0.0.1/32 any -P in ipsec
esp/transport//require
ah/transport//require
/etc/racoon.conf
remote 10.0.0.2 {
exchange_mode main;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 5;
}
}
sainfo address 10.0.0.1 any address 10.0.0.2 any {
encryption_algorithm 3des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
На www.ipsec-howto.org про transport mode with auto keyed connection
, к сожалению, ничего не сказано.
В логах пишется:
/usr/sbin/racoon -f /etc/racoon/racoon.conf -4 -F
INFO: @(#)ipsec-tools 0.3.3 (http://ipsec-tools.sourceforge.net)
INFO: @(#)This product linked OpenSSL 0.9.7d 17 Mar 2004 (http://www.openssl.org/)
INFO: IPsec-SA request for 10.0.0.2 queued due to no phase1 found.
INFO: initiate new phase 1 negotiation: 10.0.0.1[500]<=>10.0.0.2[500]
INFO: begin Identity Protection mode.
NOTIFY: the packet is retransmitted by 10.0.0.2[500].
ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP 10.0.0.2->10.0.0.1
INFO: delete phase 2 handler.
INFO: request for establishing IPsec-SA was queued due to no phase1 found.
NOTIFY: the packet is retransmitted by 10.0.0.2[500].
NOTIFY: the packet is retransmitted by 10.0.0.2[500].
NOTIFY: the packet is retransmitted by 10.0.0.2[500].
ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP 10.0.0.2->10.0.0.1
INFO: delete phase 2 handler.
INFO: request for establishing IPsec-SA was queued due to no phase1 found.
NOTIFY: the packet is retransmitted by 10.0.0.2[500].
ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP 10.0.0.2->10.0.0.1
INFO: delete phase 2 handler.
INFO: request for establishing IPsec-SA was queued due to no phase1 found.
а на 10.0.0.2
INFO: respond new phase 1 negotiation: 10.0.0.2[500]<=>10.0.0.1[500]
INFO: begin Identity Protection mode.
ERROR: phase1 negotiation failed due to time up. 894021715a4b0fba:0da61a7661898aa9
INFO: respond new phase 1 negotiation: 10.0.0.2[500]<=>10.0.0.1[500]
INFO: begin Identity Protection mode.
т.е. на чем то оно тормозится, но где?
Помогите, плз, с настройкой роутинга.
Есть два компа, находящихся в разных сетях
10.0.0.10, у которого (default gw) указан как 10.0.0.1
20.0.0.20, у него default gw 20.0.0.1
Задача - видеть подсеть 30.0.0.0, которая находится за 10.0.0.10 (у 10.0.0.10 есть второй интерфейс 30.0.0.10)
Манипулировать можно лишь на 10.0.0.10 и 20.0.0.20 (их шлюзы, 10.0.0.1 и 20.0.0.1 мне недоступны)
Вот примерно так все выглядит:
сеть роутер1 gw for 1 internet
30.0.0.0/24 ---- 10.0.0.10 --- 10.0.0.1 ==== [ ] ==== 20.0.0.1 --- 20.0.0.20
Проблема в том, что за хостом 20.0.0.20 нет никакой подсети, поэтому не получается делать туннели (или я недопонял идею туннеля)
Пробовал обычный GRE (по howto с lartc.org)
со стороны 10.0.0.10
ip tunnel add tun1 mode gre remote 20.0.0.20 local 10.0.0.10 ttl 255
ip link set tun1 up
ip addr add 10.0.0.10 dev tun1
ip route add 20.0.0.20/32 dev tun1
со стороны 20.0.0.20
ip tunnel add tun1 mode gre remote 10.0.0.20 local 20.0.0.20 ttl 255
ip link set tun1 up
ip addr add 20.0.0.20 dev tun1
ip route add 30.0.0.0/24 dev tun1
Засада в том, что на 10.0.0.10 прописывается роутинг до 20.0.0.20 на tun1, но хост 20.0.0.20 сам же является терминатором туннеля.
Из-за этого конструкция не работает :(
Ну прописывание напрямую, т.е.
route add -net 30.0.0.0/24 gw 10.0.0.10 тоже не работает, т.к. (видимо) гейтвей должен находится в одной физической подсети c 10.0.0.10 (а точнее, гейтвей должен быть достижим напрямую через любой из девайсов, указанных в ifconfig).
В общем, я где то ошибаюсь, или чего то не вижу.
Просвятите :)
Есть машина под Gentoo 1.4 (2.6.5), у которой оба интерфейса смотрят в один свич, но входят они в разные подсети:
eth1: 10.0.10.1 mac 10:10:10:10:10:10 (NET1)
eth2: 10.0.20.1 mac 20:20:20:20:20:20 (NET2)
оба интерфейса является default gw для своих сетей.
Во время работы машины периодически происходит вот такая гадость:
кто либо из NET1 или NET2 запрашивает MAC адрес 10.0.10.1 или 10.0.20.1 соотвественно
AA:AA:AA:AA:AA:AA > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 10.0.10.1 tell 10.0.10.23
но в ответ, вместо логичного ответа от 10.0.10.1 (с его MAC адресом)
мы видимо ответ
20:20:20:20:20:20 > AA:AA:AA:AA:AA:AA, ethertype ARP (0x0806), length 42: arp reply 10.0.10.1 is-at 20:20:20:20:20:20
т.е. вместо ответа с нужного (eth1) интерфейса, приходит ответ от соседнего (eth2) интерфейса, что "де именно я являюсь тем, кого вы ждете". Разумеется трафик к результате идет не на тот интерфейс и,
так как файрвол организован с привязкой входящего трафика к интерфейсам, то связь временно отрубается (до получения спрашивающим корректного MAC адреса от своего default-gw).
Почему подобная ситуация вообще может происходить? Никак понять не могу.
Господа, сколько раз уже высказывалось это пожелание.
Почему бы не сделать возможность (зарегистрированным участникам конференции) получать уведомление об ответе хотя бы на собственную (созданную собственноручно) тему? А в идеале - на любую, на которую человек подписался.
Сколько еще столетий должно пройти, прежде чем эта возможность будет организована?
Возможно ли завернуть разные протоколы (www, ftp, mail) развести по двум разным провайдерам?
Схема примерно ясна - маркируем (iptables-ами) пакеты на разные dest-порты
iptables -t mangle ... --set-mark 0x2
#все остальные - на второго провайдера
iptables -t mangle ... --dport 80 ... --set-mark 0x1
iptables -t mangle ... --dport 21 ... --set-mark 0x1
и далее по ip rule направляем их в разные таблицы (в которых прописаны
разные default gw)
ip rule add fwmark 1 table provider1
ip rule add fwmark 2 table provider2
Но. Как быть с протоколом FTP (и другими, которые открывают более одного соединения для своей работы) - первый коннект (на порт 21)
у него пометится как "1", но ftp-data уже пометится как "2" и в результате пакеты уйдут к разным провайдерам (т.е. ничего не заработает). Это для пассивного фтп конечно.
Есть варианты решения этой проблемы?
Есть бридж (linux 2.6.4 +iptables+ebtables), стоящий между локальной
сетью и кабельным модемом.
Нужно с'эмулировать dhcp запрос клиента (находящегося в локальной
сети) на бридже (пакет dhcp запроса уходит с бриджа).
Зачем? Так как на клиенте (допустим) стоит статический адрес (и его нельзя менять), а если не запрашивать пару раз в суток dhcp сервер
с клиента, то клиента провайдер блокирует (отключает).
Исходные данные.
Бридж, стоящий между локальной сетью (lan1) и ктв модемом.
[modem] --- [bridge] ---- (lan)
в бридже две сетевухи в br0 (одна смотрит в модем, вторая - в lan1)
Вот тут возникает затык. Я запускаю dhcpcd в режиме
dhcpcd -n -o -T -R eth0
(eth0 смотрит в модем)
в ebtables прописано, что бы dhcp запрос уходил с MAC адресом от IP
10.0.4.1 (IP клиента, запрос которого эмулируем)
Смотрим снифером, да действительно идет dhcp запрос с нужным исходящим
MAC адресом. Но вот ответа на него почему то не приходит.
Чего я не заметил?
Или пакет dhcp-запроса реально никуда не уходит, хотя снифер говорит обратное?
Есть шлюз, с одной стороны которого локальная сеть с пользователями, с другой - два независимых канала к провайдерам.
Каким лучше способом будет переключать трафик с одного канала на канала так, что бы активные соединения, уже открытые пользоватлеями не прерывались (т.е. все established остались на первом канале, а все новые - уже пошли на второй, на которой и переключились)?
Сейчас это делается обыкновенной сменой default gw (точнее изменением метрики на одной из default gw записи в роутинге)