Добрый вечер!

Есть в датацентре сервер с linux. К нему будут подключаться несколько пользователей для получения доступа к общим файлам с машин под windows(требудется постоянный и динамический доступ, то есть вариант с синхронизацией не подходит). Необходимо решение этой задачи, то есть сетевой файловый протокол, который будет доступен как в linux, так и в windows(пусть даже установкой дополнительного софта под windows). Есть вариант использовать NFS или SMB, но хотелось бы рассмотреть варианты, которые имеют функционал кэширования и контроля ошибок или потерь связи.

Добрый вечер!

Есть ноутбук с WI-FI(802.11g). При подключении к беспроводной сети наблюдаются потери пакетов(>40%) между ноутбуком и точкой доступа. Вначале думал, что виновата точка доступа, попробовал с другой, потери остались. Попробовал эту же конфигурацию под win - потери отсутствуют, то есть проблема в конфигурировании. Настройка WI-FI на ноуте осуществляется с помощью iwconfig wlan0 essid test mode managed txpower 15.

Добрый день! В фирме для работы с заказчиком нужен личный кабинет, в который заходит пользователь, используя логин и пароль, а затем там оставляет сообщения с возможностью прикрепить файлы, а сотрудники фирмы отвечают. Есть ли какие-то решения, на базе которых это можно сделать. Или лучше реализовать с 0?

День добрый!

Есть безлимитный канал в интернет, есть 1000 пользователей.
Будем считать, что канал нужно просто делить между пользователями.
Правила для каждого пользователя добавляются так:

...

cl=30

...

for i in `seq 1 96`; do
    tc class add dev $DEV parent 1:1 classid 1:$cl htb rate 16kbit ceil 256kbit burst 1600 cburst 1600 prio 5
    tc qdisc add dev $DEV parent 1:$cl handle $cl: sfq perturb 0
    tc filter add dev $DEV parent 1: protocol ip prio 5 u32 match ip dst 11.0.230.$i flowid 1:$cl
    let cl=cl+1
done

...

ICMP выделяются в отдельный цировый поток.

По вечерам, когда активно одноврменно большое кол-во пользователей, задержки (ICMP) начинают сильно расти (с 16 до 200мс). Можно предположить, что виновата загрузка канала, но в то же время, если ceil указать равным емкости канала и разрешить доступ всего 10-20 пользователям, такой проблемы нет. То есть виноват htb.

Есть какие-либо идеи, как побороть эту проблему? Железный шейпер купить возможности нет.

>>>

Добрый день! Кто/что может быть в этом виноват? С других серверов всё ок.

IP truncated-ip - 1280 bytes missing! 89.108.16.24.30044 > 10.67.1.214.52344: UDP, length 1401
IP truncated-ip - 1280 bytes missing! 89.108.16.24.30043 > 10.67.1.213.52343: UDP, length 1401
IP truncated-ip - 1280 bytes missing! 89.108.16.24.30042 > 10.67.1.212.52342: UDP, length 1401
IP truncated-ip - 1280 bytes missing! 89.108.16.24.30042 > 10.67.1.212.52342: UDP, length 1401
IP truncated-ip - 1280 bytes missing! 89.108.16.24.30042 > 10.67.1.212.52342: UDP, length 1401
IP truncated-ip - 1280 bytes missing! 89.108.16.24.30044 > 10.67.1.214.52344: UDP, length 1401

>>>

Добрый день! Возможно ли на одном интерфейсе использовать несколько разных МАС-адресов одновременно. Или в любом случае придётся использовать виртуализацию?

>>>

Доброй ночи! Появилась необходимость выполнять прозрачное проксирование для пользователей пяти подсетей А.B.C.0/24. Необходимо, чтобы src-адрес не менялся. Например, у пользователя на VPN адрес 80.81.112.16, то и src-адрес у squid должен быть 80.81.112.16.

>>>

Доброе утро!

Между машинами GW1 и GW2 поднят OpenVPN-туннель. На GW2 настроен нат PPTP в сторону GW1. То есть пользовтель,
который подключается к GW2 по PPTP, на самом деле подключается к GW1.

GW1 =========== GW2 <====== USER
      OpenVPN         PPTP

Если пинговать GW2 с GW1 через туннель, то задержки в пределах нормы (GW1 и GW2 сильно удалены друг от друга и между ними много роутеров):

PING 172.21.0.11 (172.21.0.11) 56(84) bytes of data.
64 bytes from 172.21.0.11: icmp_seq=1 ttl=64 time=6.96 ms
64 bytes from 172.21.0.11: icmp_seq=2 ttl=64 time=8.84 ms
64 bytes from 172.21.0.11: icmp_seq=3 ttl=64 time=6.70 ms
64 bytes from 172.21.0.11: icmp_seq=4 ttl=64 time=7.23 ms

Если пинговать пользователя с GW1, то получаем следующее:

PING 12.0.177.23 (12.0.177.23) 56(84) bytes of data.
64 bytes from 12.0.177.23: icmp_seq=1 ttl=128 time=113 ms
64 bytes from 12.0.177.23: icmp_seq=2 ttl=128 time=110 ms
64 bytes from 12.0.177.23: icmp_seq=3 ttl=128 time=49.5 ms
64 bytes from 12.0.177.23: icmp_seq=4 ttl=128 time=92.7 ms

Почему задержки настолько велики? Шейпинг не используется.

>>>

Доброй ночи! На днях смотрел трэйсы и обратил внимание на зедержки, которые вносят наши сервера - в нашей фирме пакет проходит несколько маршрутизаторов, прежде чем попадает к провайдеру. Стал размышлять о задержках, которые вносит каждый хоп. Попинговал один шлюз с другого, они смонтированы в одной стойке и обнаружил задержки в ~0.4 мс. Чем определяется это время с точки зрения системы? Настройками частоты таймера в ядре? Появилось стойкое желание это время уменьшить. или в таком случае стоит смотреть в сторону RTOS?

# ping 192.168.2.100
PING 192.168.2.100 (192.168.2.100) 56(84) bytes of data.
64 bytes from 192.168.2.100: icmp_seq=1 ttl=64 time=0.479 ms
64 bytes from 192.168.2.100: icmp_seq=2 ttl=64 time=0.406 ms
64 bytes from 192.168.2.100: icmp_seq=3 ttl=64 time=0.467 ms
64 bytes from 192.168.2.100: icmp_seq=4 ttl=64 time=0.401 ms
64 bytes from 192.168.2.100: icmp_seq=5 ttl=64 time=0.455 ms

>>>

Доброй ночи! Для маршрутизации трафика используется несколько серверов. Главным шлюзом является машина А. На машине B и C default_route указан через машину A.

На машине А сделано так:
$IPTABLES -t nat -A POSTROUTING -p all -s В -j SNAT --to-source $INET_IP
$IPTABLES -t nat -A POSTROUTING -p all -s С -j SNAT --to-source $INET_IP
echo "1" > /proc/sys/net/ipv4/ip_forward

Смотрим трэйс с машины В и видим:
traceroute to ya.ru (213.180.204.8), 64 hops max, 40 byte packets
 1  192.168.2.2 (192.168.2.2)  0 ms  0 ms  0 ms
 2  10.0.0.89 (10.0.0.89)  15 ms  16 ms  17 ms
 3  10.0.1.1 (10.0.1.1)  16 ms  17 ms  13 ms
 4  ххх.ru (х.х.х.х)  12 ms  15 ms  15 ms

С машины С в трэйсе первые два хопа закрыты:
traceroute to ya.ru (213.180.204.8), 30 hops max, 38 byte packets
 1  192.168.2.2 (192.168.2.2)  0.572 ms  0.409 ms  0.447 ms
 2  * * *
 3  * * *
 4  ххх.ru (х.х.х.х)  11.863 ms  12.597 ms  18.606 ms

Долго пытался найти причину, но ответа так и не нашёл. На В и С правил в файерволле нет. На машине А присутствуют только два правила, которые я привёл выше. Может кто подскажет?

>>>

Поставлен маршрутизатор, задача которого соединять две сети, а точнее сеть и сервер доступа: eth0 смотрит в сеть(сеть 172.16.0.0/24, IP: 172.16.0.1), eth1 в сторону сервера, на котором поднят pptpd(сеть 192.168.2.1/24, IP: 192.168.2.2, IP сервера с pptpd 192.168.2.1). На маршрутизаторе сделано следующее:

iptables -t nat -A PREROUTING -p ALL -d 172.16.0.1 -j DNAT --to-destination 192.168.2.1 iptables -t nat -A POSTROUTING -p ALL -d 192.168.2.1 -j SNAT --to-source 192.168.2.2

TCP работает без проблем, то есть все TCP-коннекты, которые попадают на 172.16.0.1, на самом деле пробрасываются в сторону 192.168.2.1. Протоколы ICMP и GRE не работают, поэтому подключиться к pptpd не удаётся. Что можно сделать?

Пропатчил ядро для исопльзования imq. Интерфейс отлично поднимается:

# ifconfig imq0 imq0 Link encap:UNSPEC HWaddr UP RUNNING NOARP MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:30 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Также пропатчены iptables в ядре и пользовательский iptables. Создаю правило: iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0

Нулевой эффект. Куда копать?

Сложилась такая ситуация:

клиенты коннектились через pptp, затем делался для них NAT:

iptables -t nat -A POSTROUTING -p ALL -s $VPN_IP_RANGE -j MASQUERADE -o tun0

всё, что по 80му порту, прокидывалось через прозрачный прокси: iptables -t nat -A PREROUTING -p tcp --dport 80 -s $VPN_IP_RANGE -j REDIRECT --to-port 3128

появился второй канал(tun1). юзеров с определённых IPов надо пускать через него. Но их тоже надо пускать через прокси, чтобы сделать delay pools. Как такое можно реализовать? Если нельзя, то какие можно использовать шейперы? Поискал, ничего дельного не нашёл, что могла бы в зависимости от нагрузки на полосу ограничивать скорость.

У нас доступ в интернет осуществляется через спутник, defaultroute - tun0. Для некоторых задач потребовали, чтобы трафик с определённых ip направлялся по наземному каналу(через гейт), для чего я сделал след правило: iptables -t nat -A POSTROUTING -p icmp -s $VPN_IP_RANGE2 -o eth1 -j SNAT --to-source 192.168.1.1. Но оно не даёт желаемого результата. В чём я ошибаюсь?