LINUX.ORG.RU
решено ФорумAdmin

Железка не авторизуется через tacacs+

 , ,


0

2

В общем, вот. Оно не работает и не работало, стоит задача понять: почему.

Centos 6.3
tac_plus version F5.0.0a1
selinux disabled
В iptables правило подключение разрешает, в tcpdump, запущенном на сервере, видны попытки достучаться до tacacs по правильным портам, а ответа от сервера никакого нет.
Сам такакс неуиноуат: запущенный с разными debug level, он ничего не видит!
В логах в /var/log grep-ом ничего не видать по айпишнику стучащейся железки.
Стучится железка из сетки 192.168.*.* в сетку с внешним ip, допустим, хотя эта инфа уже совсем неинтересна, так как с сетью на вид всё хорошо, всё пингуется, на другие железки можно спокойно ходить.

НЕПОНЯТНОУ. Прошу помощи.



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

В iptables правило подключение разрешает, в tcpdump, запущенном на сервере, видны попытки достучаться до tacacs по правильным портам, а ответа от сервера никакого нет.

Точно проблема не в файрволе? tcpdump работает ДО iptables, то есть если ты таки режешь что-то на INPUT, в tcpdump этого видно НЕ будет.

Покажи iptables-save и выхлоп tcpdump при стуке

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

Ничего не попутал. В tcpdump не будет видно режешь ли ты что-то файрволом или нет - пакеты ВСЕГДА будут приходить

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

Извините. Вы так сформулировали что можно понять обратное.
Вот в этой формулировке все верно.

В tcpdump не будет видно режешь ли ты что-то файрволом или нет - пакеты ВСЕГДА будут приходить

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

Не вижу смысла показывать вывод iptables-save, потому что с выключенным iptables то же самое.

Вот такого типа пакеты tcpdump видит, белый айпишник и порт цензурю

16:06:52.326730 IP 192.168.10.2.52154 > x.x.x.x.p: Flags [S], seq 2973885100, win 4128, options [mss 536], length 0
16:06:54.326350 IP 192.168.10.2.52154 > x.x.x.x.p: Flags [S], seq 2973885100, win 4128, options [mss 536], length 0
По два пакета шлет на первый интерфейс, потом на второй, потом опять на первый, и нет никакого ответа.

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

Там два интерфейса, такакс слушает с обоих, и так же на оба интерфейса пробует достучаться злополучная циска.

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

Окей, а теперь покажи таблицу маршрутизации. Может у тебя там rp_filter шалит - запрос приходит с одного интерфейса, а ответ на этот адрес должен пойти с другого - по умолчанию такое поведение режется. Причем не файрволом - т.к. с точки зрения системы это не forward трафик.

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