Просмотр полной версии : [linux] Debian & ADSL.
Вобщем, описываю суть проблемы. Есть модем ADSL и есть машина с двумя сетевыми интерфейсами. Доступны 12 штук ip адресов, которые можно назначать сетевухе.
Если сетевухе назначить 1 ip (любой из 12), то есть работает на ура и все машины nat'ом выпускаются в инет замечательно. Но! Если прописать адрес алиасом
ifconfig eth1:0 x.x.x.99 netmask 255.255.255.240
то через этот алиас никто в инет не выпускается. Хотя адрес извне пингуется. В чем может быть косяк?
eth1 Link encap:Ethernet HWaddr 00:02:B3:D8:B6:9F
inet addr:x.x.x.98 Bcast:x.x.x.255 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:11854 errors:0 dropped:0 overruns:0 frame:0
TX packets:14433 errors:0 dropped:0 overruns:117 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3289385 (3.1 MiB) TX bytes:2944211 (2.8 MiB)
Interrupt:23 Base address:0xd000
eth1:0 Link encap:Ethernet HWaddr 00:02:B3:D8:B6:9F
inet addr:x.x.x.99 Bcast:x.x.x.255 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:23 Base address:0xd000
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
x.x.x.96 0.0.0.0 255.255.255.240 U 0 0 0 eth1
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 x.x.x.97 0.0.0.0 UG 0 0 0 eth1
iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
iptables -L -n -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- 192.168.0.201 0.0.0.0/0 to:x.x.x.98
SNAT all -- 192.168.0.64 0.0.0.0/0 to:x.x.x.98
SNAT all -- 192.168.0.28 0.0.0.0/0 to:x.x.x.98
SNAT all -- 192.168.0.204 0.0.0.0/0 to:x.x.x.98
SNAT all -- 192.168.0.212 0.0.0.0/0 to:x.x.x.99
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Попробовал по совету Stellar'а поставить алиасу маску 255.255.255.255 (как во фрибсд), но это нисколько не помогло. Фигня Осталась таже самая.
tcpdump -i eth1:0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1:0, link-type EN10MB (Ethernet), capture size 96 bytes
18:38:50.583737 IP x.x.x.99 > ns.mtu.ru: icmp 40: echo request seq 41225
18:38:50.602161 IP ns.mtu.ru > x.x.x.99: icmp 40: echo reply seq 41225
18:38:51.908258 IP x.x.x.99 > ns.mtu.ru: icmp 40: echo request seq 41481
18:38:51.926828 IP ns.mtu.ru > x.x.x.x: icmp 40: echo reply seq 41481
18:38:52.909535 IP x.x.x.99 > ns.mtu.ru: icmp 40: echo request seq 41737
18:38:52.927249 IP ns.mtu.ru > x.x.x.99: icmp 40: echo reply seq 41737
18:38:53.910758 IP x.x.x.99 > ns.mtu.ru: icmp 40: echo request seq 41993
18:38:53.929759 IP ns.mtu.ru > x.x.x.99: icmp 40: echo reply seq 41993
В то время, как с нормального выхода в инет.
tcpdump -i eth1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
18:40:57.716288 IP ns.mtu.ru > mail.akeeper.ru: icmp 64: echo reply seq 1
18:40:58.716930 IP mail.akeeper.ru > ns.mtu.ru: icmp 64: echo request seq 2
18:40:58.736729 IP ns.mtu.ru > mail.akeeper.ru: icmp 64: echo reply seq 2
При этом, .99 из инета нормально пингуется. И этому есть отражение в tcpdump'е, то есть карта его слышит.
Надеюсь, что завтра shaman добавит подробностей этого... хм... шаманства. Так как парились мы с ним напару. Но что убивает больше всего - в какой-то момент всё вдруг нормально заработало. Почему заработало и почему перестало - не понимаю. :cry: :cry: :cry:
2akeeper: фаза луны сменилась :D
2akeeper: эта фраза всегда произносится когда что-то или работает или не работает с бухты-барахты. Ядро менять не пробовали ?
Собственно вот еще одна подробность.
Если сетевухе назначается 1 ip (любой), то все остальные ip из инета не пингуются (что вполне естестенно)
НО! Если поставить алиасом еще один ip (тоже любой), то из инета основной ip пингуется нормально, а при пинге всей остальной подсети получаем петлю:
Трассировка маршрута к x.x.x.100 с максимальным числом прыжков 30
1 <10 мс <10 мс <10 мс 192.168.99.1
2 <10 мс 10 ms <10 мс 81.195.73.81
3 40 ms 30 ms 40 ms 81.195.63.2
4 60 ms 61 ms 50 ms 5.5.5.4
5 60 ms 60 ms 60 ms 10.230.2.114
6 70 ms 80 ms 70 ms 5.5.5.4
7 80 ms 70 ms 81 ms 10.230.2.114
8 80 ms 90 ms 80 ms 5.5.5.4
9 90 ms 100 ms 90 ms 10.230.2.114
10 110 ms 101 ms 100 ms 5.5.5.4
11 100 ms 110 ms 101 ms 10.230.2.114
Причем петля начинается там, где должен был бы ответить adsl-модем.
Кстати, сейчас как раз наблюдается эта кортина.
Дальше.
Не нравиться мне, что у маршрута по умолчанию метрика 0.
И напоследок - кто-нибудь объяснит, что такое seq?
2akeeper: эта фраза всегда произносится когда что-то или работает или не работает с бухты-барахты. Ядро менять не пробовали ?
Во-первых, на основном шлюзе (откуда начались "танцы"), аналогичная схема с выделенкой от другого провайдера, работает идеально. Во-вторых, после шлюза с слакварью я перенес эту функцию (временно) на компьютер с дебианом. Результатом сначала было то, что все заработало. Но... почему-то перестало и картина стала аналогичной первому шлюзу.
2akeeper man iproute2 ???
2akeeper: в linux так просто ничего не бывает...
Вполне возможно, что в нем как нибудь хитро прописана маршрутизация. Учитывай что прописанная там маршрутизация обычным route не отображается :wacko:
2akeeper: в linux так просто ничего не бывает...
Вполне возможно, что в нем как нибудь хитро прописана маршрутизация. Учитывай что прописанная там маршрутизация обычным route не отображается :wacko:
И ты хочешь сказать, что мне для работы с алиасами надо поднимать iproute2??? :alive:
2akeeper: а ты че думал :) С ее помощь еще не такое можно делать! :)
2akeeper: а ты че думал :) С ее помощь еще не такое можно делать! :)
На фиг iproute2! Он не при чем.
2akeeper: а ты че думал :) С ее помощь еще не такое можно делать! :)
Да я ничего не говорю, просто первый раз слышу, что для работы с алиасами сетевой карты, нужны какие-то дополнительные сервисы. Раньше никогда не видел такой нужды. :dontknow:
те вопросы ко мне, что ты кинул:
1. ну касательно модема я тебе уже сказал, что если у тебя алиасы доступны - то какие могут быть вопросы по канальной части...мне не ясно.
2. вообще за тему - странно, по идее нату обычно говорится с какого ip он будет обращаться и оно работает. может имеет смысл обновить его или задать вопрос касательно такой странности в mailist соответствующих разработчиков.
желаю удачи
хм а линукс вообще оптимально выбран для таких задач?
тем паче дистр дебиана изначально вроде не самый оптимальный для сетевых вопросов...нет? оно ориентированов в сторону субд оракл по своей сути (вспоминая как появлялся дебиан)
Может быть и не оптимально, но не вижу причин, чем такое решение плохо. Тем паче, что дебиан здесь фигурирует как альтернатива стандартному (для меня стандартному) шлюзу на слакваре. В любом случае, спасибо.
2McUrex: какой нах... оракл ??? Там дебианами в списке сертифицированных и не пахнет.
2sauron: это теперь не пахнет, а раньше они с сусекой пытались конкурировать именно в этом поле.
да и вообще, поспокойней уже пора бы быть, молодой человек :)
Между тем, я так и не придумал, как решить этот косяк. Вернее, я так и не понял в чем же собственно этот косяк укрылся.
2akeeper: я же объяснил ;)
2akeeper: я же объяснил ;)
Ты имеешь в виду ttl?
Уху. Ну откуда еще эта магия ленор может творится ?
Уху. Ну откуда еще эта магия ленор может творится ?
Вот это я и пытаюсь понять.
Вот еще кусок, специально для Sauron'а.
tcpdump: listening on eth1:0, link-type EN10MB (Ethernet), capture size 96 bytes
13:39:20.988367 IP (tos 0x0, ttl 127, id 1549, offset 0, flags [none], length: 60) x.x.x.99 > ns.mtu.ru: icmp 40: echo request seq 256
13:39:21.007556 IP (tos 0x0, ttl 58, id 30060, offset 0, flags [none], length: 60) ns.mtu.ru > x.x.x.99: icmp 40: echo reply seq 256
Отсюда видно, что TTL тут не при делах, так как оно нормальное.
В догонку. Если модем не при делах, то есть работает нормально, то почему ни один сервис не отвечает с этих адресов, хотя у меня из локали - отвечают даже на этих ip'ах? И почему некоторые ip в алиасах вообще не пингуются (shaman может привести пример странной петли)? Ничего не понимаю... закрадывается крамольная мысль, что здесь явно что-то не так.
Так, гусары - спакуха, ща вы тут найдете в мту-интел проблемы в маршрутизацей таким тихим сапом :)
1. Оставьте в покое вы эти алиасы.
Нат по своей сути никак с алиасами на сетевой плате не связан, во всяком случае в его классическом понимании. Задачей ната, основной и единственной - является подмена src или dst ip адреса - все. В твоем случае алиасы не нужны вааще ибо со стороны оконечной железки на твой интерфейс прописан статичный маршрут жестким макарием. Но и наличие алиасов. с другой стороны тебе, по идее, конечно ничем мешаться не могут. Нат же должен вообще с левой сетью на src (что неплохо бы попробывать) работать.
2. Выводов всеговышеналитого следует, что нат не выполняет своих ф-ий:
а) есть какая то фича с snat-ом, возможно есть какие то конфиги куда надо прописывать конкретно map/bimap сеть/маска -> src-ip/маска
б) snat в принципе не работает. или его нет у тебя (читай не умеет).
енто мои имхи, ибо пинять на ошибки в конфигах, настройках видимо, по истечении уже не первого часа времени, надеюсь, неприемлимо
Понимаешь ли, что не дает мне покоя. Оставим нат в покое - я просто поднимаю на интерфейсе другие адреса (алиасами разумеется) и сканирую их nmap'ом на предмет сервисов висящих. Сервисы от меня есть. Тоже сканирование из интернета показывает, что даже если адрес существует, то сервисов на нем нет. Почему? Нат тут уже совсем не при делах.
а) или перезапустить сервисы, дабы те нашли новые интерфейсы
б) или уже рассказать сервисам о том, что теперь они еще и на новых интерфейсах должны работать...
Если не это, то алиасов нет, ну или совсем ось выкинуть нах - 3.14пец...
Со "своей" стороны, я так понимаю, что ты алиасы не поднимаешь?
И вообще что такое "своя" сторона?!
Чего то запутался, алиасы твои из интернета есть или их нет? Дай посмотреть...
Чего там за история с отбором ip адресов у тебя - скока у тебя чего кто забирал/давал, мож и недодали чего внатуре (или я не так понял)?
Значит так. По поводу сервисов и интерфейсов - из локальной сети я могу использовать любой алиас и сервисы будут отзываться. Видать потому что дело до модема не доходит, а останавливается (логично) на самом шлюзе. То есть не это.
Локальная сеть это и есть своя сторона.
По поводу алиасов из интернета пингуются через раз и как-то выборочно, если я их поднимаю. Грубо говоря .99 да, .100 нет, .101 да... но ни на одном из них нет ни одного сервиса (из локальной сети - есть).
История с отбором. Понимаешь ли, какое-то время назад, когда точка.ру у нас только появилась - всё это нормально работало. И основные адреса и алиасы. Потом какое-то время не использовалась точка.ру совсем. Сейчас когда стала использоваться - появилась эта история. Может у нас их отобрали, когда мы на другой тариф перешли?
Грубо говоря .99 да, .100 нет, .101 да... но ни на одном из них нет ни одного сервиса (из локальной сети - есть).
Все адреса выше 99 - петля, и никогда не пинговались нормально.
На 99 адресе нет ни одного сервиса.
Бля, ну стало быть нет там нифига - вот она и не пашет!
Ща погляжу куда статик написан и все будет понятно!
2McUrex: эээ а тогда при тех же настройках и том же железе и ядре у другого прова работает ? :horr: :fear:
2Sauron: читай тред - было сказано - что алиасы доступны и работают. После этого и было мной сказано что дело не в связи, если с алиасами есть проблема тогда надо разбираться со связью никто никого не выгораживал. Так что нехрена пустозвонством заниматься, если копишь трафик, то и копи его на mp3search.ru или еще там каком zadorno.com.
2McUrex: выполнены подобные же настройки но у другого прова. И все работает. Это было первым что мне сказали когда я начал валить вину на ядро и .т.п.
PS я потом кто-то мне заявляет:
Да и вообще, поспокойней уже пора бы быть, молодой человек :)
2Sauron: Хм... Я могу еще раз свое заявление повторить, а что это изменит, если ты и во второй раз поришь чего-то. Причем тут другой провайдер? Какие нах настройки, какое ядро?! :) Читать ты не начнешь по теме все равно, обсуждать вопрос тоже...на фига оно мне - хочешь сказать что провайдер гнилой, идите к другим - их много :)
Да кстати, все починили и все заработало :))
Да кстати, все починили и все заработало :))
Большое тебе человеческое спасибо! Я уж начал думать, что пора менять квалификацию на дворника... :roll: Ура!
2Sauron: Хм... Я могу еще раз свое заявление повторить, а что это изменит, если ты и во второй раз поришь чего-то. Причем тут другой провайдер? Какие нах настройки, какое ядро?! :) Читать ты не начнешь по теме все равно, обсуждать вопрос тоже...на фига оно мне - хочешь сказать что провайдер гнилой, идите к другим - их много :)
Ой да фиг с ним. Каждый не в ту сторону просто смотрит и все. А что не по теме ??? Значит меня не туда направили рыть заемлю лопатой.
PS не понял одного кто и как починил.
Дано: При перенастройке канала при его физическом переезде, по всей видимости, по каким то причинам была указана неправильная маска для статического маршрута в сторону akeeper-ского терминирующего устройства, в данном случае Linux/Debian. Со стороны "Клиента" ( :) ) была указаны не достоверные показания деффиктовки сетевой проблемы, а именно было сообщено, что алиасные адреса, поднимаемые на интерфейсе - доступны. Как только было по 6ому витку выяснено, что всетаки алиасные адреса не работают - стало ясно куда копать и ситуация решилась исправлением маски маршрута.
Вывод: Виноват дежинжерен провайдера, который неправильно указал маску маршрута.
ЗЫ: Если бы было сказано что алиасы не работаю сразу так же через 3 минуты вопрос был бы снят (грязно оправдываясь) :)
2McUrex: я пинал akeeper'а к прову. :) Хотя симптомы похожи :)
vBulletin® v3.8.0, Copyright ©2000-2012, Jelsoft Enterprises Ltd. Перевод: zCarot