описываю ситуацию:
подключен по ВПН - все прекрасно... работает без проблем...
переписываю в сетевухе настройки на "авторизаторские" - все робит (сайт кабинета открывается)
переписываю настройки обратно на впн-овские - пароль определяется, коннектится но ничего дальше шлюза не
пингуется...
да, глючит оно. сам был вынужден перейти на авторизатор после того, как впн сломался.
сейчас топологию сети переделывают, отказываются от маршрутизаторов и переводят на коммутаторы. в процессе всплывают проблемы, которые
потихоньку устраняют. переходный период где-то до августа будет, потом устаканится.
причем последние
цифры в ИП и шлюзе совпадают... это правильно? (раньше не обращал внимания)
объясните мне пожалуйста, как компания кабинет может выставить реквизиты удаленно, если вы вбиваете их вручную, а не на автомате!
Причем тут кабинет, если у вас система не изменяет ip адрес
объясните мне пожалуйста, как компания кабинет может выставить реквизиты удаленно, если вы вбиваете их вручную, а не на автомате!
Причем тут кабинет, если у вас система не изменяет ip адрес
в впн:
сервер 10.0.0.1
пользователь 87.224.193.хх
пароль ***********
откуда берется это я не знаю... коннект по впн
происходит, пароль опознается, но пинг дальше шлюза (10.0.0.1 и 87.224.193.1) не идет... страничеи не открываются, почта не робит...
Вы вбиваете одно, в системе ничего не меняется, остается прежнее.
не так... сначала был ВПН - он работал норм... потом я пределал реквизиты сетевух на "авторизаторские" - работает... потом (через две минуты) снова переделал реквизиты
на впн-овские - не работает...
Конфигурирую на интерфейсе (eth0.2) белый IP-адрес, запускаю авторизатор — работает. После этого деконфигурирую его (при этом линк до Вас не падает — Ваш канал воткнут в VLAN-свитч, там тегирован и в транке отправлен на домашний роутер), конфигурирую на
интерфейсе (eth0.2) серый IP-адрес, пишу маршрут от него на 10.0.0.1, поднимаю PPTP, получаю оттуда белый IP-адрес — работает, но на пакеты, отправленные в PPTP-интерфейс (ppp0) ответы прилетают в физический интерфейс (eth0.2).
Баг/фича?
Выдержки из трех консолей:
Исходник:
vladimir@storage:~$ ping 87.224.128.10
PING 87.224.128.10 (87.224.128.10) 56(84) bytes of data.
64 bytes from 87.224.128.10: icmp_seq=1 ttl=56 time=1.41 ms
64 bytes from 87.224.128.10: icmp_seq=2 ttl=56 time=1.26 ms
64 bytes from 87.224.128.10: icmp_seq=3 ttl=56 time=1.45 ms
64 bytes from 87.224.128.10: icmp_seq=4 ttl=56 time=1.37 ms
^C
--- 87.224.128.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3011ms
rtt min/avg/max/mdev = 1.267/1.377/1.457/0.074 ms
vladimir@storage:~$ sudo tcpdump -n -i ppp0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
22:26:52.353760 IP 94.31.252.34 > 87.224.128.10: ICMP echo request, id 55142, seq 1, length 64
22:26:53.357296 IP 94.31.252.34 > 87.224.128.10: ICMP echo request, id 55142, seq 2, length 64
22:26:54.361285 IP 94.31.252.34 > 87.224.128.10: ICMP echo request, id 55142, seq 3, length 64
22:26:55.365283 IP 94.31.252.34 > 87.224.128.10: ICMP echo request, id 55142, seq 4, length 64
vladimir@storage:~$ sudo tcpdump -n -i eth0.2 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.2, link-type EN10MB (Ethernet), capture size 96 bytes
22:26:52.355128 IP 87.224.128.10 > 94.31.252.34: ICMP echo reply, id 55142, seq 1, length 64
22:26:53.358524 IP 87.224.128.10 > 94.31.252.34: ICMP echo reply, id 55142, seq 2, length 64
22:26:54.362707 IP 87.224.128.10 > 94.31.252.34: ICMP echo reply, id 55142, seq 3, length 64
22:26:55.366628 IP 87.224.128.10 > 94.31.252.34: ICMP echo reply, id 55142, seq 4, length 64
P.S. жить не мешает — использую авторизатор, поэтому СТП не тревожу.
ну вот я прямо сейчас (при Вас) поэкспериментирую... ))))
сей момент роблю по авторизатору через роутер (если подключать через сетевуху - картина та же)
в роутере прописаны реквизиты ип 87.224.193.хх маска 255.255.255.0 шлюз 87.224.193.1 днс1, днс2 - ОК...
щас зайду
в панель управления доступом, переключу на впн и пропишу реквизиты впн... о результатах доложу... ))))
после угасания зеленого авторизатора прописал в настройка ван-порта роутера реквизиты впн, законнектился, шлюзы 10.0.0.1 и 87.224.193.1 пингуются... все что дальше (например днс 87.224.197.1) не
пингуется...
могу проделать то же с ноутами, подключая кабовскую витуху к их сетевкам (и меняя маки на мак роутера)... результат будет одночленный... )))))
причем последние цифры в ИП и шлюзе совпадают... это правильно? (раньше не обращал
внимания)
На сколько я понял у Вас настройки сетевой карты меняются некорректно, либо Вы что-то упустили, кабинет тут не причем.
А шлюзы пингуются, потому что МАК-адрес проходит проверку.
Мне кажется, что машину времени ещё не изобрели. Если у Вас не хватает знаний произвести диагностику на месте, стоит приложить все усилия для того, чтобы диагностику мог выполнить сотрудник СТП.
А что, религия что ли мешает позвонить в ТП и прямо в прямом эфире все проделать под их чутким руководством.
Лично я так и делала и туда, и обратно. Тут ведь не телепаты, компьютер Ваш не видят, дистанционно диагностировать не могут.
Мне кажется, что машину времени ещё не изобрели. Если у Вас не хватает знаний произвести диагностику на месте, стоит приложить все усилия для того, чтобы диагностику мог выполнить сотрудник СТП.
мои знания тут не при чем... )))
такие ситуации уже были... после звонка в ТП все начинало работать (чота они там у себя сотворяли)... ))))
просто хотелось бы, что бы все работало без звонков... ))))
Мне кажется, Вы пытаетесь искать черную кошку там, где её, скорее всего, нет. Я более чем уверен, что всё начинало работать потому как было сломано и после звонка починено.
Если оно сломалось вновь, нужно вновь об этом сообщить. Возможно. что и сломалось в другом месте. Возможно, что и
чинили не там.
Внимание! сейчас Вы не авторизованы и не можете подавать сообщения как зарегистрированный пользователь.
Чтобы авторизоваться, нажмите на эту ссылку (после авторизации вы вернетесь на
эту же страницу)
