Боги Linux, прошу вашей помощи! (настройка vlan)

Добрый день! В отчаянии. Два дня бьюсь с настройкой VLAN. Имеется шлюз на базе ClearOs 5.2 (CentOs).


Знаю что чайник, но в задачу впился зубами и хочу ее выполнить.


На системнике висит 2 сетевухи с двумя интерфейсами:

eth0 external со статическим ip от провайдера.

eth1 - выход на локальную сеть.


Ситуация такая - есть удаленный объект с видеорегистратором. Провайдер настроил свою сеть и дал ID влана 1726.


На базе физического устройства eth0 которое смотрит на провайдера создаю VLAN интерфейс с настройками в etc/sysconfig/networking-scripts/ifcfg-eth0.1726:

DEVICE=eth0.1726
TYPE="VLAN"
ONBOOT="yes"
BOOTPROTO="static"
IPADDR="10.18.16.12"
NETMASK="255.255.255.0"
VLAN="yes"

Поднимаю интерфейс:

ifup eth0.1726

ip 10.18.16.12 пингуется.

ifconfig говорит что все нормально, интерфейс поднят:

eth0 Link encap:Ethernet HWaddr 00:11:95:F4:ADB
inet addr:172.16.7.206 Bcast:172.16.7.255 Mask:255.255.255.0
inet6 addr: fe80::211:95ff:fef4:addb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2278776 errors:0 dropped:0 overruns:0 frame:0
TX packets:1468014 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2428856847 (2.2 GiB) TX bytes:180862879 (172.4 MiB)
Interrupt:185 Base address:0x6000

eth0.1726 Link encap:Ethernet HWaddr 00:11:95:F4:ADB
inet addr:10.18.16.12 Bcast:10.18.16.255 Mask:255.255.255.0
inet6 addr: fe80::211:95ff:fef4:addb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5162 errors:0 dropped:0 overruns:0 frame:0
TX packets:29 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:276220 (269.7 KiB) TX bytes:2217 (2.1 KiB)

eth1 Link encap:Ethernet HWaddr 00:21:91:8E71
inet addr:192.168.0.5 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::221:91ff:fe8e:d7d1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1471502 errors:0 dropped:0 overruns:0 frame:0
TX packets:1910607 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:188508914 (179.7 MiB) TX bytes:2198595405 (2.0 GiB)
Interrupt:193 Base address:0x8000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:181422 errors:0 dropped:0 overruns:0 frame:0
TX packets:181422 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:80800436 (77.0 MiB) TX bytes:80800436 (77.0 MiB)

Провайдер от себя доступ настроил и сказал пробовать пинговать 10.18.16.14 (wi-fi антенна на здании где установлена система видеонаблюдения), однако пинг не идет. Провайдер тоже меня не видит. Прочитал про похожий случай и что в настройках модуля 802.1q желательно отключить rp фильтр, поставил значение 0.


Так же читал что нужно прописывать правила маршрутизации в ip tables для интерфейса. Прописывать пробовал, все безрезультатно.

iptables -A INPUT -i eth0.1726 -s 10.18.16.12/24 -p icmp --icmp-type echo-request -j ACCEPT
iptables -A OUTPUT -o eth0.1726 -d 10.18.16.12/24 -p icmp --icmp-type echo-request -j ACCEPT

Не получалось.

Потом пробовал

iptables -A FORWARD -i eth0.1726 -j ACCEPT iptables -A FORWARD -o eth0.1726 -j ACCEPT

10.18.16.14 не пингуется.

Возможно правила прописал криво. Так же возникли сомнения что они начинают действовать после перезагрузки firewall.

Перезагружал firewall

/etc/init.d/firewall restart

Но настройки от этого только сбрасываются на прежние. iptable-save помогает только тем - чтобы сохранить настройки в файл.


Текущие правила: # iptables -L -n -v

Chain INPUT (policy DROP 273 packets, 88330 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x12/0x12 state NEW reject-with tcp-reset
10 8566 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW
0 0 DROP all -- eth0 * 127.0.0.0/8 0.0.0.0/0
0 0 DROP all -- eth0 * 169.254.0.0/16 0.0.0.0/0
4287 1647K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
3345 322K ACCEPT all -- eth1 * 0.0.0.0/0 0.0.0.0/0
3 87 ACCEPT icmp -- eth0 * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 ACCEPT icmp -- eth0 * 0.0.0.0/0 0.0.0.0/0 icmp type 3
0 0 ACCEPT icmp -- eth0 * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT icmp -- eth0 * 0.0.0.0/0 0.0.0.0/0 icmp type 11
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp spt:67 dpt:68
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp spt:67 dpt:68
0 0 ACCEPT tcp -- * * 0.0.0.0/0 172.16.7.206 tcp dpt:1875
259 31442 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 state RELATED,ESTABLISHED
1353 1153K ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpts:1024:65535 state RELATED,ESTABLISHED
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
102K 87M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
4803 313K ACCEPT all -- eth1 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- pptp+ * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun+ * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy DROP 5 packets, 559 bytes)
pkts bytes target prot opt in out source destination
4297 1655K ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * pptp+ 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * tun+ 0.0.0.0/0 0.0.0.0/0
3511 1544K ACCEPT all -- * eth1 0.0.0.0/0 0.0.0.0/0
22 638 ACCEPT icmp -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- * eth0 0.0.0.0/0 0.0.0.0/0 udp spt:68 dpt:67
0 0 ACCEPT tcp -- * eth0 0.0.0.0/0 0.0.0.0/0 tcp spt:68 dpt:67
0 0 ACCEPT tcp -- * eth0 172.16.7.206 0.0.0.0/0 tcp spt:1875
1727 206K ACCEPT all -- * eth0 0.0.0.0/0 0.0.0.0/0
Chain drop-lan (0 references)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

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


Может кто-то что-то подскажет? Пусть даже глупою ошибку допустил, но буду безмерно благодарен.

GNU/Linux

1K постов15.5K подписчиков

Добавить пост

Правила сообщества

Все дистрибутивы хороши.

Будьте людьми.

Вы смотрите срез комментариев. Показать все
Автор поста оценил этот комментарий

Собрал всё в кучу, разбирайся по порядку:

1) разреши всё на файрволле. (потом настроишь)

2) с маршрутами не заморачиваяйся - connected-сеть должна работать без них

3) смотри маки/арп на промежуточном оборудовании. ("arp -a" на  линуксах, кажется.)


Если маков/арпа нет, то смотри настройки железок вполне вероятно, что где-то напутали режимы работы access/trunk, опять же странно, что антенна управляется в сервисном влане.


физику уже проверили?

раскрыть ветку (13)
Автор поста оценил этот комментарий

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

iptables -P INPUT ACCEPT

iptables -P OUTPUT ACCEPT


И пинги пошли. Теперь нужно думать над написанием конкретных правил и добавлением их в автозагрузку.


Только вот из локальной сети пинга на 10.18.16.14 так и нет, хотя VLAN интерфейс 10.18.16.12 пингуется.

Что нужно настроить не подскажете?

раскрыть ветку (12)
Автор поста оценил этот комментарий

если правильно понимаю ситуацию, то нужно две вещи обеспечить:

1) Железо из локальной сети должно иметь маршрут на регистратор, а регистратор должен знать где находится ЛВС. (у вас скорее всего 10.18.16.14 не знает маршрута на ЛВС)

2) включить ip forwarding на линукс, чтобы он мог работать как роутер:

"sudo echo 1 > /proc/sys/net/ipv4/ip_forward"

раскрыть ветку (11)
Автор поста оценил этот комментарий

Забыл про маскарад, точка не знает обратного маршрута в локальную подсеть.

раскрыть ветку (10)
Автор поста оценил этот комментарий

А зачем маскарад? Проще маршрут дописать  и производительность будет выше и диагностика в случае чего проще...
P.S.: маршрут, естественно, на регистратор, а не на точку - точке провайдера в локалку клиента ходить по определению незачем.

раскрыть ветку (9)
Автор поста оценил этот комментарий

А не факт, что в регике можно маршруты писать. И исходим из ситуации, что к управлению точкой прова нет доступа.

раскрыть ветку (8)
Автор поста оценил этот комментарий

тогда, конечно, и через маскарад можно, но всё равно не одобряю :)

точку wifi в ЛВС выводить не надо, а маршрут по умолчанию у регика точно есть - как я понял он а connected-сети со шлюзом, так что можно его и указать в качестве 0.0.0.0 Впрочем, это всё домыслы - пусть автор схемку набросает.

раскрыть ветку (7)
Автор поста оценил этот комментарий

Еще хз как точка работает. Если бридж, то правила и маршруты надо писать до камеры. Если роутинг - то до точки. А дальше проброс порта.

Далее, подсетка регика и адрес на влан интерфейсе шлюза из разных диапазонов. Либо на регике адрес менять, либо на шлюзе добавлять айпи на интерфейс.

Имхо, самый простой и правильный вариант - это перенос регика в локалку. А на шлюзе - маршрут до камеры.

раскрыть ветку (6)
Автор поста оценил этот комментарий

Как задумал провайдер 10.18.16.12 был тестовый.

Сейчас поменяли ip на 192.168.0.222 и через ip route add выделили диапазон 192.168.0.192-222/27 на eth0.1726


Камеры и регистратор со шлюза пингуются, "ура" казалось бы.

Но из локальной сети пинг не идет. Пробовал замаскарадить еще раз, той же командой (по сути же ничего не поменялось). Странно...


И еще заметил одну неприятную особенность. iptables через минуту рубится на стандартные, отбрасывая изменения. Вот это вещь неприятная.

раскрыть ветку (5)
Автор поста оценил этот комментарий

А все очень просто, у тебя шлюз с ума сходит. У него на 2 разных интерфейсах висит один и тот же диапазон айпи.

То есть, он считает, что сможет пойти на 192.168.0.200 и через eth1 и через eth0.1726/ это раз.

Посмотри на правило маскарадинга повнимательнее, это два.

Но с одинаковыми сетями на двух разных интерфейсах ничего нормально не будет работать все равно.

Автор поста оценил этот комментарий

Накидай схему с адресацией, будет на порядок проще. Я уже нить потерял как у тебя что должно быть. Но присоединюсь к @BrainFury, не надо на двух разных интерфейсах одну сеть прибивать. Если рисовать сложно, то хоть текстом: адреса камер, адреса регистратора, адреса ЛВС, как это всё соединено со шлюзом. Ощущение, что проблема не в линуксе, а просто ты запутался с проектом.

раскрыть ветку (3)
Автор поста оценил этот комментарий
Ощущение, что проблема не в линуксе, а просто ты запутался с проектом.

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

Распространенная ошибка вин-админов. Либо делать по готовым рецептам, либо крутить все подряд, пока не заработает, без понимания, как оно работает в принципе и чего хочешь добиться, в плане дизайна сети.

раскрыть ветку (2)
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку