On Thu, Apr 13, 2017 at 01:52:26AM +0300, Alexander Sheiko wrote:
> ОК - попробуйте зацепиться за l2tp сервер виндовым клиентом из этой же
> сети
Ставить ради этого винду так не хочется
> и, потом, ещё и с другого провайдера.
Попытаюсь..
___
freebsd
13.04.2017 13:49, Irina Liakh пишет:
>> С другой стороны, tcpdump -s0 про входящие TCP-пакеты на ng0 говорит cksum
>> 0x8bd2 (correct),
>> а это значит, что контрольная сумма у него сходится. Я склонен верить
>> tcpdump-у в этом вопросе,
> Кстати да, как так получается, что tcpdump говорит "cksu
On Thu, Apr 13, 2017 at 01:06:30AM +0300, Vladislav V. Prodan wrote:
> 2017-04-13 0:31 GMT+03:00 Irina Liakh :
>
> > Результат тот же самый, включая счетчики bad checksum в "netstat -sp tcp"
> > и "netstat -sp udp".
> >
>
> Заменить сетевую карту и патч-корд есть возможность?
Но ведь все остальн
On Thu, Apr 13, 2017 at 10:07:07AM +0700, Eugene Grosbein wrote:
> 12.04.2017 23:32, Eugene Grosbein пишет:
>
> 65 discarded for bad checksums
> >>>
> >>> Этот счетчик растёт в то время, когда выполняются попытки установить
> >>> TCP-соедиение
> >>> через туннель?
> >>
> >> Да. Синхронно с
12.04.2017 23:32, Eugene Grosbein пишет:
65 discarded for bad checksums
>>>
>>> Этот счетчик растёт в то время, когда выполняются попытки установить
>>> TCP-соедиение
>>> через туннель?
>>
>> Да. Синхронно с приходящими SYN ACK пакетами.
>> Аналогично растет вот это:
>>
>> # netstat -sp ud
Каким образом можно провести механическую и электрическую диагностику
разъема 8P8C, а также патч-корда UTP программным способом из PC ? :)
Причем одна из сторон патч-корда нам не подконтрольна.
13 апреля 2017 г., 1:43 пользователь Anton Sayetsky
написал:
> 13 апр. 2017 г. 1:30 пользователь "Vlad
В письме от Чтв, 13 Апр 2017, 00:01 Irina Liakh пишет:
> Ничего не поменялось.
> Результат тот же самый, включая счетчики bad checksum в "netstat -sp tcp" и
> "netstat -sp udp".
ОК - попробуйте зацепиться за l2tp сервер виндовым клиентом из этой же
сети и, потом, ещё и с другого провайдера. Ips
13 апр. 2017 г. 1:30 пользователь "Vladislav V. Prodan"
написал:
Сетевые карты vr никогда стабильностью и безупречной работой не отличались.
Да и всегда существует проблема статики и КЗ у "медных" сетевых плат.
А кто-то говорил, что сетевухи на чипе VIA Rhine хорошие? Тем не менее, я
не вижу осн
13 апреля 2017 г., 1:09 пользователь Anton Sayetsky
написал:
>
>
> 13 апр. 2017 г. 1:07 пользователь "Vladislav V. Prodan" <
> ad...@support.od.ua> написал
>
> Заменить сетевую карту и патч-корд есть возможность?
>
> А ещё шамана позвать в бубен постучать.
>
У вас необычные фантазии, с LOR'a наб
13 апр. 2017 г. 1:07 пользователь "Vladislav V. Prodan"
написал
Заменить сетевую карту и патч-корд есть возможность?
А ещё шамана позвать в бубен постучать.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/free
2017-04-13 0:31 GMT+03:00 Irina Liakh :
> Результат тот же самый, включая счетчики bad checksum в "netstat -sp tcp"
> и "netstat -sp udp".
>
Заменить сетевую карту и патч-корд есть возможность?
--
Vladislav V. Prodan
System & Network Administrator
support.od.ua
_
On Thu, Apr 13, 2017 at 12:16:32AM +0700, Eugene Grosbein wrote:
> выгрузить pf и ещё раз попробовать c ipfw nat - всё должно работать.
# kldstat
Id Refs AddressSize Name
1 19 0x8020 1fa7c38 kernel
21 0x82221000 1fe5a3 zfs.ko
31 0x8242000
On Wed, Apr 12, 2017 at 11:17:04PM +0300, Alexander Sheiko wrote:
>
> Покажите pfctl -s states в момент установленного туннеля.
all udp :57871 (192.168.12.2:54002) -> :1701
MULTIPLE:MULTIPLE
> Попробуйте поменять:
>
> nat on vr0 inet from 192.168.12.0/24 to any -> (vr0:0)
>
> на
>
> na
В письме от Чтв, 13 Апр 2017, 00:15 Irina Liakh пишет:
> # pfctl -s nat
Покажите pfctl -s states в момент установленного туннеля.
Попробуйте поменять:
nat on vr0 inet from 192.168.12.0/24 to any -> (vr0:0)
на
nat pass on vr0 inet from 192.168.12.0/24 to any -> (vr0:0)
--
WBR, Alexander She
On Wed, Apr 12, 2017 at 09:39:26PM +0300, Alexander Sheiko wrote:
> Покажите, как именно НАТите.
>
> Сам по себе pfnat с l2tp дружит, по крайней мере на опёнке работает как
> часы. Может проблема с правилами, а может специфика фри.
# pfctl -s nat
nat on vr0 inet from 192.168.12.0/24 to any -> (vr
В письме от Срд, 12 Апр 2017, 22:35 Irina Liakh пишет:
> # pfctl -s rules
Покажите, как именно НАТите.
Сам по себе pfnat с l2tp дружит, по крайней мере на опёнке работает как
часы. Может проблема с правилами, а может специфика фри.
--
WBR, Alexander Sheiko
___
13.04.2017 2:35, Irina Liakh пишет:
>> Если ядро GENERIC, то есть вывод kldstat на роутере в то время,
>> когда туннель через него установлен.
> # kldstat
> Id Refs AddressSize Name
> 1 15 0x8020 1fa7c38 kernel
> 21 0x82221000 1fe5a3 zfs.ko
> 31
On Wed, Apr 12, 2017 at 07:59:38PM +0300, Oleg V. Nauman wrote:
> И wifi роутер с NAT ?
У меня роутером FreeBSD с внутренним и внешним эзернетами.
Это когда через NAT подключаюсь.
Когда напрямую - через wifi роутер, мне неподвластный.
___
freebsd mailin
On Wed, Apr 12, 2017 at 11:52:19PM +0700, Eugene Grosbein wrote:
> Теперь насчет него, всё те же вопросы: ядро GENERIC?
Да.
Система FreeBSD 11.0-RELEASE-p2
> Что в loader.conf и в sysctl.conf?
В loader.conf пусто, в sysctl.conf только про acpi.
> Какая внешняя сетевая (имя драйвера)?
vr0
> Вывод
On Wednesday 12 April 2017 21:00:21 Irina Liakh wrote:
> On Wed, Apr 12, 2017 at 10:27:06PM +0700, Eugene Grosbein wrote:
> > 13.04.2017 0:43, Irina Liakh пишет:
> > > tcpdump вдогонку показывала,
> >
> > Но без командной строки (без аргументов), а это важно.
> > Нужна полная команда и её вывод по
13.04.2017 2:07, Irina Liakh пишет:
> Пробовались ipfw и pf - результат одинаковый (только на счетчики bad checksum
> не смотрела
> во время эксперимента с ipfw).
> Портит не по причине моих рук? Значит, send-pr?
Рано, роутер с NAT тоже легко неправильно настроить.
Теперь насчет него, всё те же
On Wed, Apr 12, 2017 at 07:39:25PM +0300, Vladislav V. Prodan wrote:
> Или сетевая карта (в виртуалке).
не виртуальная машина, обычная)
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd
On Wed, Apr 12, 2017 at 11:32:10PM +0700, Eugene Grosbein wrote:
> 13.04.2017 1:48, Irina Liakh пишет:
> > On Wed, Apr 12, 2017 at 11:11:27PM +0700, Eugene Grosbein wrote:
> >>> 65 discarded for bad checksums
> >>
> >> Этот счетчик растёт в то время, когда выполняются попытки установить
> >> TCP
12 апреля 2017 г., 19:32 пользователь Eugene Grosbein
написал:
> Ну вот и ответ - NAT портит пакеты l2tp при трансляции и не портит PPtPGRE.
>
Или сетевая карта (в виртуалке).
--
Vladislav V. Prodan
System & Network Administrator
support.od.ua
__
13.04.2017 1:48, Irina Liakh пишет:
> On Wed, Apr 12, 2017 at 11:11:27PM +0700, Eugene Grosbein wrote:
>>> 65 discarded for bad checksums
>>
>> Этот счетчик растёт в то время, когда выполняются попытки установить
>> TCP-соедиение
>> через туннель?
>
> Да. Синхронно с приходящими SYN ACK пакетам
On Wed, Apr 12, 2017 at 11:11:27PM +0700, Eugene Grosbein wrote:
> > 65 discarded for bad checksums
>
> Этот счетчик растёт в то время, когда выполняются попытки установить
> TCP-соедиение
> через туннель?
Да. Синхронно с приходящими SYN ACK пакетами.
Аналогично растет вот это:
# netstat -sp
13.04.2017 1:30, Irina Liakh пишет:
> 65 discarded for bad checksums
Этот счетчик растёт в то время, когда выполняются попытки установить
TCP-соедиение
через туннель?
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/
On Wed, Apr 12, 2017 at 10:49:24PM +0700, Eugene Grosbein wrote:
> TCP с другими хостам - не с гугло-DNS - через туннель работает или тоже нет?
Перепробовала несколько разных сервисов (по TCP) на разных серверах -
все ведут себя аналогично.
То же самое с разными DNS-серверами (по UDP).
___
On Wed, Apr 12, 2017 at 10:49:24PM +0700, Eugene Grosbein wrote:
> В студию вывод команд uptime и netstat -sp tcp
# uptime
7:05PM up 8:26, 7 users, load averages: 0.40, 0.36, 0.29
# netstat -sp tcp
tcp:
47279 packets sent
21066 data packets (4318440 bytes)
12 апреля 2017 г., 3:38 пользователь Irina Liakh написал:
> Машина находится в LAN и NAT'ится ближайшим хопом - сервером, имеющим выход
> к VPN-серверу.
>
Машина в виртуалке? Какой драйвер сетевухи?
--
Vladislav V. Prodan
System & Network Administrator
support.od.ua
___
13.04.2017 1:00, Irina Liakh пишет:
> "-p" же не принципиально?
В данном случае не должно быть, но tcpdump лучше всегда запускать с -p, за
исключением
тех случаев, когда есть особая причина использовать promiscuous mode.
TCP с другими хостам - не с гугло-DNS - через туннель работает или тоже не
Может, это окажется полезным: если в настройках изменить исключительно
тип линка (в mpd.conf вместо l2tp поставить pptp), то все работает.
___
freebsd mailing list
freebsd@uafug.org.ua
http://mailman.uafug.org.ua/mailman/listinfo/freebsd
On Wed, Apr 12, 2017 at 10:27:06PM +0700, Eugene Grosbein wrote:
> 13.04.2017 0:43, Irina Liakh пишет:
>
> > tcpdump вдогонку показывала,
>
> Но без командной строки (без аргументов), а это важно.
> Нужна полная команда и её вывод подряд. Не забыть ключи tcpdump -vnps0 и -i.
# tcpdump -i ng0 -nv
13.04.2017 0:43, Irina Liakh пишет:
>> Надо добавть вывод команд ifconfig, ipfw show, tcpdump - со всеми
>> аргументами,
>> даже если кажется, что это не нужно - на самом деле, нужно.
> На клиенте ipfw, pf и ipfilter не загружены, на сервере с NAT'ом
> загружен только pf с nat rules, фильтрующих
On Wed, Apr 12, 2017 at 09:37:37PM +0700, Eugene Grosbein wrote:
> Стандартная ошибка - художественное изложение своими словами проделанной
> диагностики и полное отсутствие по-настоящему необходимых деталей.
> Не надо так.
угу.
> Надо добавть вывод команд ifconfig, ipfw show, tcpdump - со всеми а
12.04.2017 7:38, Irina Liakh пишет:
> Добрый день всем!
>
> Помогите, пожалуйста, разобраться, или подскажите, если это всем давно
> известно)
>
> Есть mpd, настроен как клиент, тип линка - l2tp. IPSEC не задействован.
> Машина находится в LAN и NAT'ится ближайшим хопом - сервером, имеющим выход
On Wed, Apr 12, 2017 at 04:04:35PM +0300, Oleg V. Nauman wrote:
> SYN+ACK похож на правду, значит еще один вариант - смотреть а не уходит ли
> ACK мимо туннеля или вообще через "левый" интерфейс.
Посмотрела "для очистки совести" - не уходит.
Видимо, дело не в "левом" интерфейсе, т.к. в случае DN
On Wednesday 12 April 2017 16:17:52 Irina Liakh wrote:
> On Wed, Apr 12, 2017 at 01:10:56PM +0300, Oleg V. Nauman wrote:
> > Неплохо бы увидеть вывод tcpdump -nvv на обоих сторонах туннеля в это
> > момент.
> Серверная сторона туннеля мне не доступна. Доступны только клиентская
> и сервер-роутер,
On Wed, Apr 12, 2017 at 01:10:56PM +0300, Oleg V. Nauman wrote:
>
> Неплохо бы увидеть вывод tcpdump -nvv на обоих сторонах туннеля в это момент.
Серверная сторона туннеля мне не доступна. Доступны только клиентская
и сервер-роутер, который маскарадит клиентскую машину и роутит ее к VPN-серверу.
On Wednesday 12 April 2017 15:00:43 Irina Liakh wrote:
> On Wed, Apr 12, 2017 at 12:20:23PM +0300, roman wrote:
> > Либо пакеты приходят на клиент "поврежденные" (crc), поэтому
> > отбрасываются клиентом. Растут ли дропы на интерфейсе на клиенте?
>
> Не растут. Кстати, UDP sum ok:
>
> 12:35:11.99
On Wed, Apr 12, 2017 at 12:20:23PM +0300, roman wrote:
> Либо пакеты приходят на клиент "поврежденные" (crc), поэтому
> отбрасываются клиентом. Растут ли дропы на интерфейсе на клиенте?
Не растут. Кстати, UDP sum ok:
12:35:11.991026 IP (tos 0x0, ttl 64, id 13540, offset 0, flags [none], proto
U
On 12.04.17 11:01, skeletor wrote:
12.04.17 03:38, Irina Liakh пишет:
Добрый день всем!
Помогите, пожалуйста, разобраться, или подскажите, если это всем давно
известно)
Есть mpd, настроен как клиент, тип линка - l2tp. IPSEC не задействован.
Машина находится в LAN и NAT'ится ближайшим хопом -
On Wed, Apr 12, 2017 at 11:38:20AM +0300, Oleg V. Nauman wrote:
> Часы убежали вперед.
Спасибо :) Спрошу почему так.
> > On Wed, Apr 12, 2017 at 10:57:12AM +0300, Alexander Bolshakov wrote:
> > > Поведение очень похоже на ошибки а локальном файерволе (входящие пакеты в
> > > линии присутствуют).
On Wednesday 12 April 2017 13:27:42 Irina Liakh wrote:
Часы убежали вперед.
> On Wed, Apr 12, 2017 at 10:57:12AM +0300, Alexander Bolshakov wrote:
> > Поведение очень похоже на ошибки а локальном файерволе (входящие пакеты в
> > линии присутствуют). Я бы пересмотрел все правила ещё раз или откры
On Wed, Apr 12, 2017 at 10:57:12AM +0300, Alexander Bolshakov wrote:
>
> Поведение очень похоже на ошибки а локальном файерволе (входящие пакеты в
> линии присутствуют). Я бы пересмотрел все правила ещё раз или открыл бы хост
> полностью на время эксперимента...
Это при отключенном файерволе на
12.04.17 03:38, Irina Liakh пишет:
Добрый день всем!
Помогите, пожалуйста, разобраться, или подскажите, если это всем давно
известно)
Есть mpd, настроен как клиент, тип линка - l2tp. IPSEC не задействован.
Машина находится в LAN и NAT'ится ближайшим хопом - сервером, имеющим выход
к VPN-сервер
Поведение очень похоже на ошибки а локальном файерволе (входящие пакеты в линии
присутствуют). Я бы пересмотрел все правила ещё раз или открыл бы хост
полностью на время эксперимента...
--
Отправлено из Mail.Ru для Android среда, 12 апреля 2017г., 10:49 +03:00 от
Irina Liakh sp...@itl.ua :
>O
On Wed, Apr 12, 2017 at 06:29:29AM +0300, Vladislav V. Prodan wrote:
> 12 апреля 2017 г., 3:38 пользователь Irina Liakh написал:
>
> > Добрый день всем!
> >
> > Помогите, пожалуйста, разобраться, или подскажите, если это всем давно
> > известно)
> >
>
> Смотреть с каким MTU поднялся туннель на о
48 matches
Mail list logo