И у нас в воскресенье проблемы с пчелайном были

38-Квадратный Круг >

[img]http://s.lurkmore.to/images/thumb/0/0b/CaptainFacepalm.png/250px-CaptainFacepalm.png[/img]

держись литиум

43-SERGIUSF > Чем картинки вешать, лучше помоги коллегам из Билайн бизнес решить вопрос по заявке 1880438
Будем благодарны!

самое что интересное, раньше когда был случай отсутствия связи несколько дней они сами сделали перерасчет и прислали по этому факту СМС (такая честность, само собой, понравилась). Сейчас звоню, типа нет перерасчета, может у вас там что сломалось? Говорят, это так задумано, теперь надо звонить самому и просить.
Похоже, Билайн начинает конкурировать с ЮТК. Скоро, чтобы переманить клиентов ЮТК начнутся постоянные проблемы со связью и минимальное время дозвона в саппорт не меньше получаса. Сравнительно честное воровство денег уже освоили (тут, правда, я не знаю с кем конкуренция, наверное ребята из отдела сотовой связи научили).

при пересчете на 10 рублей, но все равно смухлевали ;)

Есть тут знатоки TCP/IP на низком уровне? Расскажите, пожалуйста, в каком месте вдруг мог приключиться затык.

Есть железка - D-Link DI-LB604, в которую подключены два внешних канала от Кубинтерсвязь (213.132.72.0/21 AS12543) и Южный Телеком (80.240.48.0/21 AS20895), в LAN порт железки подключен WEB-сервер на IIS, отдающий некий контент по протоколу HTTPS. Много лет всё работало замечательно и без особых проблем, но примерно 3 недели назад часть клиентов перестала заходить на сайт, причём через оба входящих канала. Замена провайдера (способа подключения) на стороне клиента проблему решает. По HTTP клиент всё отлично с нашего сервера получает.

Ни наши провайдеры, ни провайдеры наших клиентов у себя проблемы не наблюдают.

Вот и вопрос, как это исправить? Желательно без изменений на стороне клиента.

Спасибо!

Что-то, думаю, можно сделать на стороне провайдеров или на нашей железке, чтобы Path MTU Discovery заработал как положено. ICMP снаружи на нашей железке не блокирован, traceroute и ping до неё доходят.

Подозревается некий маршрутизатор, находящийся между клиентом и нашей железкой и блокирующий ICMP тип 3 код 4, что мешает клиенту получить ответ от нашего сервера. Как бы убедительно для службы поддержки провайдера клиента его найти...

man traceroute на тему флагов -T и -p

50-lithium > :-) Если бы у клиентов стоял Linux то и вопросов бы не было, там утилит полно. С Windows всё несколько сложнее, к сожалению.

прохождение синов на 443 можно проверит виндовозным телнетом, определить mtu по трассе виндовозным пингом #не думаю что дело в mtu
а также чудный nping входит в состав nmap для винды
и за 3 недели вполне можно было доехать до клиента с нужным буком с нужными утилитами

зы: и этот человек собирался тыкать меня носом - из какой "жопы" в центосе растут зависимости pcre)

52-gloomymen > :-) Если бы всё было так просто:
ping xx.xx.xx.xx проходит
tracert xx.xx.xx.xx проходит
telnet xx.xx.xx.xx 443 проходит
а обмен по https [b]не идёт[/b]. Входящий от клиента видим, а он в ответ ничего не получает.

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

Сейчас вот сижу через проводной Билайн, ping -l 1493 xx.xx.xx.xx не проходит. Сейчас попробую посмотреть на каком из хопов начинается затык.

[em]ping xx.xx.xx.xx проходит[/em]
вотблть, а ping -l 1500 xx.xx.xx.xx проходит?

[em]Входящий от клиента видим, а он в ответ ничего не получает[/em]
а свои ответы вы вилите?
[em]а проблема не на нашей стороне, а на стороне их провайдера[/em]
во первых не факт, что на стороне провайдера, простым сравнением это не установить
во вторых все равно причину искать вам, и, возможно, тыкать носом провайдера, за спасибо
как вариант, можно заручиться неким гарантийным письмом от поставщика, чтобы по окончании разбора полетов, была возможность получить бабла за проведенные работы, тут вам ваш юрист в помощь

вобщем очевидное решение на коленке - днем уменьшайте свой mtu
по ночам ищите врагов)

[em]ping -l 1493 xx.xx.xx.xx не проходит[/em]
это на 3-й неделе изысканий? зачет

Итак, через проводной Билайн картина такова:

Tracing route to XXX-XX-XXX-XX.krasnodar.ugtel.ru [XX.XXX.XX.XXX]
over a maximum of 30 hops:

1 8 ms 8 ms <1 ms 213.132.75.10
2 9 ms 8 ms 8 ms 79.104.204.225
3 9 ms 8 ms 8 ms 195.239.88.89
4 8 ms 8 ms 8 ms 195.239.88.134
5 9 ms 8 ms 8 ms 87.226.227.2
6 78 ms 78 ms 79 ms UGTEL-IX-Krasnodar.ugtel.ru [81.26.131.233]
7 76 ms 78 ms 78 ms 217-52-240-80.krasnodar.ugtel.ru [80.240.52.217]

8 107 ms 101 ms 107 ms XXX-XX-XXX-XX.krasnodar.ugtel.ru [XX.XXX.XX.XXX]

9 106 ms 108 ms 97 ms XXX-XX-XXX-XX.krasnodar.ugtel.ru [XX.XXX.XX.XXX]


Trace complete.

Pinging XX.XXX.XX.XXX with [b]1400[/b] bytes of data:

Reply from XX.XXX.XX.XXX: bytes=1400 time=125ms TTL=236
Reply from XX.XXX.XX.XXX: bytes=1400 time=124ms TTL=236
Reply from XX.XXX.XX.XXX: bytes=1400 time=126ms TTL=236
Reply from XX.XXX.XX.XXX: bytes=1400 time=126ms TTL=236

Ping statistics for XX.XXX.XX.XXX:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 124ms, Maximum = 126ms, Average = 125ms

Pinging XX.XXX.XX.XXX with [b]1493[/b] bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for XX.XXX.XX.XXX:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Pinging [b]80.240.52.217[/b] with [b]1493[/b] bytes of data:

Reply from 80.240.52.217: bytes=1493 time=79ms TTL=238
Reply from 80.240.52.217: bytes=1493 time=80ms TTL=238
Reply from 80.240.52.217: bytes=1493 time=79ms TTL=238
Reply from 80.240.52.217: bytes=1493 time=79ms TTL=238

Ping statistics for 80.240.52.217:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 79ms, Maximum = 80ms, Average = 79ms

Как это интерпретировать, не очень понятно.

Пойду качать nping под Винду.

[em]Как это интерпретировать, не очень понятно[/em]
интерпретировать как есть - фрагменты не доходят

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

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

53-Квадратный Круг > именно поэтому для чего-то более менее серьезного предпочтительней шлюз на Linux и обычном железе. Запустил tcpdump или iptables ... -L и смотри что куда ходит. А так... Только хаб в разрыв кабеля и еще одну машину со снифером.

пока до читал до конца увидел что уже сказали, но повторюсь для закрепления.

58-gloomymen > Я вам очень благодарен за диалог, но не могли бы вы уточнить, вы о нашей железке или о 80.240.52.217? Если о нашей, то почему проблема появилась [b]вдруг[/b] и почему не проявляется при смене провайдера у клиента?

nping через l2tp билайна что-то пока не заводится, изучаю.

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

ping -l это ж без заголовков, если не ошибаюсь, что подтвердил быстрый гуглеж и выдал цифру которую надо прибавить, чтоб получить MTU:[quote] Add 28 to that number (IP/ICMP headers) to get the optimal MTU setting. For example, if the largest packet size from ping tests is 1462, add 28 to 1462 to get a total of 1490 which is the optimal MTU setting. [/quote]
отсюда [url]http://help.expedient.net/broadband/mtu_ping_test.shtml[/url]

61-Квадратный Круг > да не во что
чесслово, я не понимаю где тут ваша железка, где клиенты, и что такое 80.240.52.217
63-701054 > +28 это для первого пакета, для фрагментов немного меньше)

64-gloomymen > эээ...завис :) ну проверяют с -f вроде чтоб не фрагментировало

или к тому что бордер снимает df и .... хз че там дальше по дороге

64-gloomymen > Ну считайте, что сейчас я клиент. В приведённом выше трейсе видно, что 80.240.52.217 это ещё провайдер (один из наших), а замаскированный XX.XXX.XX.XXX это наша железка.

63-701054 > И гуглили и читали и... делать то что? Не буду же я всем клиентам рассказывать как им у себя MTU уменьшить. Хочется решить вопрос как положено - полечить что-то, что не пропускает фрагментированные пакеты и/или режет нужные ICMP, сообщающие о необходимости фрагментации.

Как найти это что-то?

все равно не въехал, почему фрагменты не долетают , пойду гуглить, никогда не сталкивался, df мешал при малом MTU было...

65-701054 > это не про ссылку, а про размер оверхеда
ping -l [больше mtu], первый пакет будет +28, следующие фрагменты +20

67-Квадратный Круг > [url]http://www.opennet.ru/base/cisco/df_packet_fragment.txt.html[/url]

А через второго провайдера только до "-l 1472" работает, но при этом https открывается махом. Почему так?

67-Квадратный Круг > мне сложно воспринимать ваши абстракции
ну, считайте что я не в теме, на пальцах пожалуйста, куда 1493 доходят, куда нет, откуда, кто из них кто, и через кого

70-701054 > И это читал, там обходные варианты на стороне клиента или на нашей. Обходные.

выяснить кто чего не пропускает поможет nping

69-gloomymen > усе, понял, ...надо иногда играться разбором , забывается все...
+70 там статься старая, но очень толковая, дальше что искать станет предельно понятно после прочтения

вообще-то тут уже достаточно понаписали, для дальнейшего, самостоятельного плавания)
и знания low-level tcp/ip тут не при чем, по крайней мере я таковыми похвастать не могу) но разрулить подобное при имеющихся вполне можно
разве что lithium, со своим фундаментализмом потянет на low-level эксперта)

72-gloomymen > Хорошо, попытаюсь на пальцам. Я сейчас дома и подключен через проводной Билайн:
Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : beeline
Description . . . . . . . . . . . : Realtek RTL8102E/RTL8103E Family PCI-E Fast Ethernet NIC
Physical Address. . . . . . . . . : 00-00-00-00-00-00
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 10.29.0.7
Subnet Mask . . . . . . . . . . . : 255.255.248.0
Default Gateway . . . . . . . . . : 10.29.0.1
DHCP Server . . . . . . . . . . . : 213.132.75.23
DNS Servers . . . . . . . . . . . : 213.132.75.23 213.132.75.24
Lease Obtained. . . . . . . . . . : 12 марта 2013 г. 19:23:05
Lease Expires . . . . . . . . . . : 25 марта 2013 г. 20:32:06

PPP adapter Beeline Internet:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
Physical Address. . . . . . . . . : 00-53-45-00-00-00
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 128.70.16.129
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 128.70.16.129
DNS Servers . . . . . . . . . . . : 213.132.64.107 213.132.64.108

В нашу железку приходят два IP от двух разных провайдеров AA.AA.AA.AA и BB.BB.BB.BB

Tracing route to AA.AA.AA.AA over a maximum of 30 hops

1 2 ms 4 ms 4 ms 10.29.0.1
2 8 ms <1 ms 7 ms 172.16.80.46
3 8 ms 8 ms 8 ms 172.16.80.30
4 8 ms 2 ms 6 ms 172.23.80.17
5 8 ms <1 ms 7 ms 172.16.80.2
6 8 ms <1 ms 7 ms 172.16.128.202
7 8 ms 8 ms 8 ms 213.132.64.68
8 * 8 ms 8 ms AA.AA.AA.AA
9 8 ms 8 ms 8 ms AA.AA.AA.AA

Trace complete.

До AA.AA.AA.AA работает ping -l 1472 включительно и сервер по HTTPS открывается.

Трейс до BB.BB.BB.BB

Tracing route to BB.BB.BB.BB.krasnodar.ugtel.ru [BB.BB.BB.BB]
over a maximum of 30 hops:

1 8 ms 8 ms <1 ms 213.132.75.10
2 9 ms 8 ms 8 ms 79.104.204.225
3 9 ms 8 ms 8 ms 195.239.88.89
4 8 ms 8 ms 8 ms 195.239.88.134
5 9 ms 8 ms 8 ms 87.226.227.2
6 78 ms 78 ms 79 ms UGTEL-IX-Krasnodar.ugtel.ru [81.26.131.233]
7 76 ms 78 ms 78 ms 217-52-240-80.krasnodar.ugtel.ru [80.240.52.217]

8 107 ms 101 ms 107 ms BB.BB.BB.BB.krasnodar.ugtel.ru [BB.BB.BB.BB]

9 106 ms 108 ms 97 ms BB.BB.BB.BB.krasnodar.ugtel.ru [BB.BB.BB.BB]


Trace complete.

До BB.BB.BB.BB работает ping -l 1493 включительно и сервер по HTTPS не открывается.

Для примера, nping --tr BB.BB.BB.BB работает, а nping --tr AA.AA.AA.AA нет. Это и в трейсах выще видно по первому хопу...

упс, не прочитал, что у вас сайт...хм дык не в MTU может дело, если уж нечем снифать(sic!), в первую очередь я б проверял железяку д-линка, просто перевесив серв на один канал, на которм не работает https и поглядев что будет.

Нет, AA.AA.AA.AA через Билайн проверять толку мало, ибо AA.AA.AA.AA от Кубинтерсвязи и поэтому маршрутизация идёт через их внутренние маршрутизаторы с серыми IP.

Tracing route to AA.AA.AA.AA over a maximum of 30 hops

1 2 ms 4 ms 4 ms 10.29.0.1
2 8 ms <1 ms 7 ms 172.16.80.46
3 8 ms 8 ms 8 ms 172.16.80.30
4 8 ms 2 ms 6 ms 172.23.80.17
5 8 ms <1 ms 7 ms 172.16.80.2
6 8 ms <1 ms 7 ms 172.16.128.202
7 8 ms 8 ms 8 ms 213.132.64.68
8 * 8 ms 8 ms AA.AA.AA.AA

79-701054 > Понимаете, смена провайдера у клиента, ровно как и прописывание у него стороннего прокси проблему решает, т.е. проблема не в железяке и не в сервере за ней. Да и клиенты других провайдеров продолжают успешно работать по обоим нашим внешним IP.