Архивировано

Эта тема находится в архиве и закрыта для публикации сообщений.

Dganic

[Воронеж] Блокировка доступа из подсети 10.26.х.х к подсети 10.11.х.х

Рекомендованные сообщения

Примерно где-то полторы недели назад Билайн Воронеж, вот уж не знаю намеренно или нет, закрыл доступ из подсети 10.26.х.х к подсети 10.11.х.х

 

Примеры:

 

Беру себя и ещё одного человека из моей подсети, ип адреса: 10.26.23.78 и 10.26.22.255, основной шлюз у обоих 10.26.16.1

Пингуем два выборочных адреса из подсети 10.11.х.х, за которые точно уверены что они в сети:

[dganic@dga ~]$ ping 10.11.135.240
PING 10.11.135.240 (10.11.135.240) 56(84) bytes of data.
64 bytes from 10.11.135.240: icmp_req=1 ttl=58 time=0.456 ms
64 bytes from 10.11.135.240: icmp_req=2 ttl=58 time=0.369 ms
64 bytes from 10.11.135.240: icmp_req=3 ttl=58 time=0.444 ms
64 bytes from 10.11.135.240: icmp_req=4 ttl=58 time=0.408 ms
64 bytes from 10.11.135.240: icmp_req=5 ttl=58 time=0.414 ms
64 bytes from 10.11.135.240: icmp_req=6 ttl=58 time=0.412 ms
64 bytes from 10.11.135.240: icmp_req=7 ttl=58 time=0.466 ms
^C
--- 10.11.135.240 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6005ms
rtt min/avg/max/mdev = 0.369/0.424/0.466/0.032 ms

 

[dganic@dga ~]$ ping 10.11.0.1
PING 10.11.0.1 (10.11.0.1) 56(84) bytes of data.
64 bytes from 10.11.0.1: icmp_req=1 ttl=59 time=1.36 ms
64 bytes from 10.11.0.1: icmp_req=2 ttl=59 time=1.24 ms
64 bytes from 10.11.0.1: icmp_req=3 ttl=59 time=1.28 ms
64 bytes from 10.11.0.1: icmp_req=4 ttl=59 time=1.31 ms
64 bytes from 10.11.0.1: icmp_req=5 ttl=59 time=2.48 ms
^C
--- 10.11.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 1.242/1.537/2.481/0.474 ms

 

Просканируем на доступность портов:

 

[dganic@dga ~]$ nmap 10.11.135.240

Starting Nmap 5.51 ( http://nmap.org ) at 2012-04-23 02:14 MSK
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 1.22 seconds

 

Хм, ну что же попробуем с ключом -Pn:

 

[dganic@dga ~]$ nmap -Pn 10.11.135.240

Starting Nmap 5.51 ( http://nmap.org ) at 2012-04-23 02:16 MSK
Nmap scan report for 10.11.135.240
Host is up (0.00075s latency).
All 1000 scanned ports on 10.11.135.240 are filtered

Nmap done: 1 IP address (1 host up) scanned in 8.63 seconds

 

Хм, странно открытых портов не видим, хотя их куча! Что же давайте попробуем другой адрес:

 

[dganic@dga ~]$ nmap -Pn 10.11.0.1

Starting Nmap 5.51 ( http://nmap.org ) at 2012-04-23 02:18 MSK
Nmap scan report for 10.11.0.1
Host is up (0.66s latency).
All 1000 scanned ports on 10.11.0.1 are filtered

Nmap done: 1 IP address (1 host up) scanned in 68.73 seconds

 

 

Хм, и в этом случае открытых портов не оказалось, странно.

 

Теперь мы просим другова пользователя Билайн Воронеж с IP 10.35.46.176 и основным шлюзом: 10.35.40.1, просканировать эти адреса на предмет открытых портов:

 

andrew@andrew-note:~$ nmap 10.11.135.240 

Starting Nmap 5.21 ( http://nmap.org ) at 2012-04-23 02:17 MSK
Nmap scan report for 10.11.135.240
Host is up (0.016s latency).
Not shown: 988 closed ports
PORT 	STATE	SERVICE
21/tcp   open 	ftp
22/tcp   open 	ssh
53/tcp   open 	domain
81/tcp   open 	hosts2-ns
111/tcp  open 	rpcbind                                                                                                                                                               		
1723/tcp open 	pptp                                                                                                                                                                      	
2049/tcp open 	nfs                                                                                                                                                                   		
3306/tcp open 	mysql                                                                                                                                                                 		
7000/tcp filtered afs3-fileserver
8081/tcp open 	blackice-icecap
8291/tcp filtered unknown
9091/tcp open 	unknown

Nmap done: 1 IP address (1 host up) scanned in 1.46 seconds

 

Все порты доступны как положено.

 

andrew@andrew-note:~$ nmap 10.11.0.1 

Starting Nmap 5.21 ( http://nmap.org ) at 2012-04-23 02:22 MSK
Warning: 10.11.0.1 giving up on port because retransmission cap hit (10).
Nmap scan report for 10.11.0.1
Host is up (0.0079s latency).
Not shown: 992 closed ports
PORT  	STATE	SERVICE
21/tcp	open 	ftp
23/tcp	open 	telnet
259/tcp   filtered esro-gen
2007/tcp  filtered dectalk
4899/tcp  filtered radmin
5200/tcp  filtered unknown
16018/tcp filtered unknown
27715/tcp filtered unknown

Nmap done: 1 IP address (1 host up) scanned in 233.54 seconds

 

И тут доступны.

 

Для верности прошу этого пользователя просканировать и мои порты, вдруг лично меня заблокировали:

 

andrew@andrew-note:~$ nmap 10.26.23.78 

Starting Nmap 5.21 ( http://nmap.org ) at 2012-04-23 02:20 MSK
Nmap scan report for 10.26.23.78
Host is up (0.021s latency).
Not shown: 995 closed ports
PORT 	STATE SERVICE
22/tcp   open  ssh
53/tcp   open  domain
80/tcp   open  http
111/tcp  open  rpcbind
2049/tcp open  nfs

Nmap done: 1 IP address (1 host up) scanned in 0.47 seconds

 

Проверяю сам доступность портов у произвольного пользователя:

[dganic@dga ~]$ nmap 10.64.78.206

Starting Nmap 5.51 ( http://nmap.org ) at 2012-04-23 02:31 MSK
Nmap scan report for 10.64.78.206
Host is up (0.0074s latency).
Not shown: 992 filtered ports
PORT 	STATE  SERVICE
22/tcp   open   ssh
80/tcp   open   http
1119/tcp closed bnetgame
1121/tcp closed rmpp
5222/tcp open   xmpp-client
5280/tcp open   xmpp-bosh
7777/tcp closed cbt
9000/tcp closed cslistener

Nmap done: 1 IP address (1 host up) scanned in 5.32 seconds

 

Всё отлично, финансовой блокировки не было никогда, сеть блокировать не за что. Так в чем же причина блокировки доступа из одной подсети к другой?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Покажите

 

traceroute 10.11.135.240

traceroute -T 10.11.135.240

 

от себя и от другого пользователя (у которого порты сканятся), из windows можно сделать tracetcp (см. атачмент).

tracetcp.zip

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Покажите

 

traceroute 10.11.135.240

traceroute -T 10.11.135.240

 

от себя и от другого пользователя (у которого порты сканятся), из windows можно сделать tracetcp (см. атачмент).

 

Пока вот сделал только от себя:

 

[dganic@dga ~]$ traceroute 10.11.135.240
traceroute to 10.11.135.240 (10.11.135.240), 30 hops max, 52 byte packets
1  * * 10.26.16.1 (10.26.16.1)  0.557 ms !X
2  * 10.26.16.1 (10.26.16.1)  0.549 ms !X *
3  10.26.16.1 (10.26.16.1)  0.567 ms !X *  0.612 ms !X

 

!X (communication administratively prohibited) - как бы намекает что это сделано намеренно.

 

 

С не заблокированного компьютера:

 

traceroute to 10.11.135.240 (10.11.135.240), 30 hops max, 60 byte packets
1  10.64.72.1 (10.64.72.1)  5.793 ms  5.974 ms  6.499 ms
2  * * *
3  * * *
4  * * *
5  * * *
6  10.11.135.240 (10.11.135.240)  10.074 ms * *

 

 

 

 

Интересно на этом форуме вообще реально добиться решения проблемы, или опять идти на Хабр и писать Екатерине Турцевой, чтобы она пнула кого-либо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не по порядку, ну да ладно...

 

1. nmap 10.11.0.1 = ping 127.0.0.1 :)

asr1.voronezh#telnet 10.11.0.1

Trying 10.11.0.1 ... Open

login : *********

password :

Welcome to the Alcatel-Lucent OmniSwitch 6000

 

2. 10.11.128.0/21 - подсеть для клиентов с заблокированными локальными ресурсами

Black_1 10.11.128.1 255.255.248.0

 

3. Почему с других подсетей доступна залоченная подсеть - вопрос...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не по порядку, ну да ладно...

 

1. nmap 10.11.0.1 = ping 127.0.0.1 :)

asr1.voronezh#telnet 10.11.0.1

Trying 10.11.0.1 ... Open

login : *********

password :

Welcome to the Alcatel-Lucent OmniSwitch 6000

 

2. 10.11.128.0/21 - подсеть для клиентов с заблокированными локальными ресурсами

Black_1 10.11.128.1 255.255.248.0

 

3. Почему с других подсетей доступна залоченная подсеть - вопрос...

 

 

хм и вправду погорячился я. Но с железкой у вас там что-то точно не так.

Во первых пользователю 10.11.135.240 не за что резать порты, у него нет фин. блокировки, во вторых он не испытывает проблемы с доступом к локале и другие пользователи к нему, кроме моей подсети.

В общем может хоть ребутнёте железку? может станет всё на свои места. А то страсти какие-то опять с вашим ботом порторезчиком :) Ох помню по натерпелись мы с ним при запуске его у нас в городе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тогда да, на какой-то железке явно косяк, раз она не обрабатывает acl как надо. Осталось понять какую именно железку надо лечить)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тогда да, на какой-то железке явно косяк, раз она не обрабатывает acl как надо. Осталось понять какую именно железку надо лечить)

 

А разве много вариантов? Либо мою, либо товарища.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Приветствую.

Я тот самый 10.11.135.240.

Со всей ответственностью заявляю - ваша порторезка уже достала.

Это уже не первый раз, когда она капает на мозги.

Зашёл в личный кабинет - баланс положительный.

Статус: "Активен"

Интернет: "Сервис подключен"

Номер договора:2261655

 

VPN поднимал - работает.

Apr 26 21:10:05 lampserv pppd[368]: pppd 2.4.5 started by root, uid 0
Apr 26 21:10:05 lampserv pppd[368]: Serial connection established.
Apr 26 21:10:05 lampserv pppd[368]: Using interface ppp1
Apr 26 21:10:05 lampserv pppd[368]: Connect: ppp1 <--> /dev/pts/2
Apr 26 21:10:09 lampserv pppd[368]: CHAP authentication succeeded
Apr 26 21:10:09 lampserv pppd[368]: CHAP authentication succeeded
Apr 26 21:10:09 lampserv pppd[368]: local  IP address 95.30.100.168
Apr 26 21:10:09 lampserv pppd[368]: remote IP address 194.186.120.142

 

Но DHCP упорно выдаёт один и тот же адрес (у себя старые лизы очищал, коннектор на некоторое время выдёргивал):

# ifup vlan3
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Added VLAN with VID == 3 to IF -:eth0:-
Internet Systems Consortium DHCP Client 4.1.1-P1
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/vlan3/00:1c:c0:fa:a4:3d
Sending on   LPF/vlan3/00:1c:c0:fa:a4:3d
Sending on   Socket/fallback
DHCPDISCOVER on vlan3 to 255.255.255.255 port 67 interval 3
DHCPOFFER from 10.11.128.1                                                                          
DHCPREQUEST on vlan3 to 255.255.255.255 port 67                                                     
DHCPACK from 10.11.128.1                                                                            
bound to 10.11.135.240 -- renewal in 273183 seconds.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сменил.

Без особых изменений (за исключением получения нового IP из той же подсети):

# ifup vlan3
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Added VLAN with VID == 3 to IF -:eth0:-
Internet Systems Consortium DHCP Client 4.1.1-P1
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/vlan3/00:2c:ca:de:a4:3c
Sending on   LPF/vlan3/00:2c:ca:de:a4:3c
Sending on   Socket/fallback
DHCPDISCOVER on vlan3 to 255.255.255.255 port 67 interval 5
DHCPOFFER from 10.11.128.1
DHCPREQUEST on vlan3 to 255.255.255.255 port 67
DHCPACK from 10.11.128.1
bound to 10.11.135.102 -- renewal in 284969 seconds.

С бубном сплясать? =)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Slonoboy,

На решение проблемы можно рассчитывать?

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если только еще раз вытащить кабель и в течение минуты-двух поднять впн :)

 

 

Если проблема заключается в блокировке локалки у отдельного пользователя - вот разбираюсь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если только еще раз вытащить кабель и в течение минуты-двух поднять впн :)

 

 

Если проблема заключается в блокировке локалки у отдельного пользователя - вот разбираюсь.

 

 

Но DHCP упорно выдаёт один и тот же адрес (у себя старые лизы очищал, коннектор на некоторое время выдёргивал):

# ifup vlan3
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Added VLAN with VID == 3 to IF -:eth0:-
Internet Systems Consortium DHCP Client 4.1.1-P1
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/vlan3/00:1c:c0:fa:a4:3d
Sending on   LPF/vlan3/00:1c:c0:fa:a4:3d
Sending on   Socket/fallback
DHCPDISCOVER on vlan3 to 255.255.255.255 port 67 interval 3
DHCPOFFER from 10.11.128.1                                                                          
DHCPREQUEST on vlan3 to 255.255.255.255 port 67                                                 	
DHCPACK from 10.11.128.1                                                                            
bound to 10.11.135.240 -- renewal in 273183 seconds.

 

 

Сменил.

Без особых изменений (за исключением получения нового IP из той же подсети):

# ifup vlan3
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Added VLAN with VID == 3 to IF -:eth0:-
Internet Systems Consortium DHCP Client 4.1.1-P1
Copyright 2004-2010 Internet Systems Consortium.
All rights reserved.
For info, please visit [url="https://www.isc.org/software/dhcp/"]https://www.isc.org/software/dhcp/[/url]

Listening on LPF/vlan3/00:2c:ca:de:a4:3c
Sending on   LPF/vlan3/00:2c:ca:de:a4:3c
Sending on   Socket/fallback
DHCPDISCOVER on vlan3 to 255.255.255.255 port 67 interval 5
DHCPOFFER from 10.11.128.1
DHCPREQUEST on vlan3 to 255.255.255.255 port 67
DHCPACK from 10.11.128.1
bound to 10.11.135.102 -- renewal in 284969 seconds.

С бубном сплясать? =)

 

Давно было сделано, да и вы писали что проблема в одной из ваших железок, но проблема что-то так и не решилась.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Прошло около двух недель, какая либо работа по поиску неисправности и её устранению вообще ведется?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С железками все ок, работают как надо.

Свитч и номер порта, в котором висит мак Lampus'a, определился, но почему-то не пришла привязка по логину. Здесь остается только ждать когда одуплится система...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С железками все ок, работают как надо.

Свитч и номер порта, в котором висит мак Lampus'a, определился, но почему-то не пришла привязка по логину. Здесь остается только ждать когда одуплится система...

 

Что за система и когда она по вашему должна одупллится? Что-то больше чем за 2 недели она так и не одуплилась, что наводит на нехорошие мысли.

А вы стандратные "выключить и включить" пробовали? Может тогда одуплится..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Slonoboy user_popup.png

Сколько ещё будем ждать когда одуплится система? Год? два? Или может разобраться в чем проблема?

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поднимаем еще раз впн. Но только не на пару минут как раньше, а на пару часов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поднимаем еще раз впн. Но только не на пару минут как раньше, а на пару часов.

 

Было что-то сделано или это так, на случай мож прокатит?

 

May 18 20:15:30 lampserv pppd[19211]: Serial connection established.
May 18 20:15:30 lampserv pppd[19211]: Using interface ppp1
May 18 20:15:30 lampserv pppd[19211]: Connect: ppp1 <--> /dev/pts/3
May 18 20:15:32 lampserv pppd[19211]: CHAP authentication succeeded
May 18 20:15:32 lampserv pppd[19211]: CHAP authentication succeeded
May 18 20:15:32 lampserv pppd[19211]: local IP address 95.30.0.22
May 18 20:15:32 lampserv pppd[19211]: remote IP address 194.186.120.142
May 18 22:40:36 lampserv pppd[19211]: Terminating on signal 15
May 18 22:40:36 lampserv pppd[19211]: Connect time 145.1 minutes.
May 18 22:40:36 lampserv pppd[19211]: Sent 21260 bytes, received 65443 bytes.
May 18 22:40:36 lampserv pppd[19211]: Child process pptp 10.255.255.236 --nolaunchpppd (pid 19212) terminated with signal 15
May 18 22:40:36 lampserv pppd[19211]: Modem hangup
May 18 22:40:36 lampserv pppd[19211]: Connection terminated.
May 18 22:40:36 lampserv pppd[19211]: Exit.

 

без изменений.

 

В ручном режиме разблокировать никак нельзя?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поднимаем еще раз впн. Но только не на пару минут как раньше, а на пару часов.

 

Было что-то сделано или это так, на случай мож прокатит?

 

May 18 20:15:30 lampserv pppd[19211]: Serial connection established.
May 18 20:15:30 lampserv pppd[19211]: Using interface ppp1
May 18 20:15:30 lampserv pppd[19211]: Connect: ppp1 <--> /dev/pts/3
May 18 20:15:32 lampserv pppd[19211]: CHAP authentication succeeded
May 18 20:15:32 lampserv pppd[19211]: CHAP authentication succeeded
May 18 20:15:32 lampserv pppd[19211]: local IP address 95.30.0.22
May 18 20:15:32 lampserv pppd[19211]: remote IP address 194.186.120.142
May 18 22:40:36 lampserv pppd[19211]: Terminating on signal 15
May 18 22:40:36 lampserv pppd[19211]: Connect time 145.1 minutes.
May 18 22:40:36 lampserv pppd[19211]: Sent 21260 bytes, received 65443 bytes.
May 18 22:40:36 lampserv pppd[19211]: Child process pptp 10.255.255.236 --nolaunchpppd (pid 19212) terminated with signal 15
May 18 22:40:36 lampserv pppd[19211]: Modem hangup
May 18 22:40:36 lampserv pppd[19211]: Connection terminated.
May 18 22:40:36 lampserv pppd[19211]: Exit.

 

без изменений.

 

В ручном режиме разблокировать никак нельзя?

 

 

Ап ап ап!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

На всякий случай заявка № 129524332 , может всё же Билайн решится починить своё оборудование когда либо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Такс, номер моей заявки 129736515

А теперь можно в подробностях принцип работы вашей порторезки.

Может мне нужно сделать некие дополнительные движения в плане настройки маршрутов и/или iptables.

Ибо при поднятии VPN у меня через него прописаны маршруты только до определённых хостов, дабы трафик зря не утекал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подведем промежуточный итог:

Идет уже 4 месяц присутствие проблемы, а Билайн так и не смог/не захотел разобраться в проблеме и устранить её.

Вот так работает Билайн, интересно что должно произойти что-бы проблему всё же устранили?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Все на том же самом месте как и было 4 месяца назад, Билайн реально заботится о своих пользователях! =)

Передаю привет Сергею Вислобокову, который уже которую неделю уверяет что проблемой занимаются технические специалисты, но при вопросе какие конкретно, технично уходит от ответа:

Здравствуйте!

 

Приношу Вам свои извинения за задержку с ответом.

 

Вопрос, связанный с работой услуг на базе Интернет еще остается открытым.

Технические специалисты работают над его решением.

 

Благодарю Вас за понимание и еще раз извините за доставленные неудобства.

Всего Вам наилучшего.

 

Сергей Вислобоков,

Дирекция по обслуживанию клиентов.

E-mail: pomogite@beeline.ru

 

И кто их врать-то учит?

 

Несомненным позором является то, что в компании с мировым именем работаю специалисты которые за 4 месяца не могут решить проблему. Отсюда сразу возникают вопросы надежности такой компании как "Вымпелком"

 

 

@Slonoboy,

Как-то прокомментируете ситуацию?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С середины апреля прошло только 2 месяца, а не 4 :)

 

Попробуем упросить привязать логин к порту вручную... Обычно это делать отказываются, так как все работает на автомате.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Один глюк на несколько тысяч абонентов. Кажется - вполне корректно ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Глюк должен исправляться оперативно (тем более при единичных случаях).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Slonoboy,

Проблема была выявлена гораздо раньше написания топика. Так что прошло уже достаточно времени, что бы на неё среагировать.

Проблемы с порторезкой были всегда и не только в единичных случаях, здесь не надо лукавить. Да и к тому же проблема тут не типичная, абонент находится в заблокированном диапазоне, но доступ закрыт только из определенных подсетей.

Ещё мне понравилась ваша техподдержка которая закрывает заявки после неудачной попытки дозвонится до абонента, это точно верх профессионализма.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах