LINUX.ORG.RU
решено Форум — Admin  

Нет соединения по VLAN

 , ,


0

1

Добрый день! Я довольно зеленый в этом деле... 2 дня бьюсь с настройкой VLAN на базе ClearOs 5.2

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

На базе физического устройства 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"

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

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.11, однако пинг не идет. Прочитал про похожий случай и что в настройках модуля желательно отключить rp фильтр, поставил значение 0.

Так же читал что нужно прописывать в правилах ip tables. Прописывать пробовал, все безрезультатно. Текущие правила: # 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

Как быть? Может я неверно прописывал правила в iptables? Что еще может блокировать Vlan? Провайдер говорит с его стороны все нормально.

В iptables пробовал прописывать: 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

Потом перезагружал firewall /etc/init.d/firewall restart

Однако настройки сбрасывались не прежние...

Результата не было. Провайдер не видит меня, я не вижу его.



Последнее исправление: Anti4it (всего исправлений: 1)
← Загрузка GRUB'ом из матрёшки блочных устройств
Помогите разобраться с правильным «туннелированием» трафика →
Ответ на: комментарий от Anti4it

Запусти захват пакетов на интерфейсе смотрящем в сторону провайдера и убедись, что vlan тэг навешивается на исходящие фреймы: 

tcpdump -i eth0 -n -e '(vlan 1726)'
Если увидишь хоть какие-то захваченные данные, то значит тег вешается и и можешь идти к провайдеру который «тебя не видит» и капать ему на мозг этими логами.

BOOBLIK ★★★★
()
Ответ на: комментарий от BOOBLIK

Хорошо, завтра попробую на работе. Сейчас уже дома.

Кстати, может ли быть проблема в /etc/sysctl.conf Со строкой net.ipv4.ip_forward = 0?

Читал что для организации передачи данных между интерфейсами параметр должен быть = 1.

Или это роли не играет?

Anti4it
() автор топика
Ответ на: комментарий от Anti4it

Ну ты же пока что пытаешься всего лишь пингануть 10.18.16.11, который как я понял сидит в том же вилане на удаленном объекте. Никакой передачи трафика между интерфейсами (если пинговать с самой машины с clearos) не происходит и не должно. Пока что у вас судя по всему нет L2 связности.

BOOBLIK ★★★★
()

В аппаратуре провайдера порт какого типа? Транк, куда провайдер добавляет vlan1276? Или акцессный c дефолтным vlan1276? А то может быть зря мучаешься.

imul ★★★★★
()
Ответ на: комментарий от Anti4it

id vlan = 1726, везде в настройках он и прописан.

Тогда всё должно работать. Одно но. Помнится в RH где-то ещё был выбор, как должен VLAN-интерфейс именоваться. eth0.1726 - это просто имя, а VLAN ID может оказаться и не 1726, если не тот тип имени выбран (выдавалась ли там ошибка при несоответствии - не помню тоже). Точнее про RH не скажу - сильно давно было. Но и да, tcpdump покажет. ip_forward для собственного трафика сервера не при чём, rp фильтр не при чём, если вход и выход одним каналом. iptables к VLAN тоже никаким боком, мешать может только просто как с обычным интерфейсом. iptables можно просто отключить на время опытов.

AS ★★★★★
()
Ответ на: комментарий от imul

Или акцессный c дефолтным vlan1276? А то может быть зря мучаешься.

А какой тогда смысл клиенту что-то про VLAN-ы рассказывать? Хотя всякое может быть...

AS ★★★★★
()
Ответ на: комментарий от AS

Ну нам вот краснодарский ростелеком зачем-то рассказывал. Думали транк, а оказался акцесс. А так ты прав абсолютно. Но, краснодарский ростелеком люди странные, у них в трассировке между двумя серыми айпи белые проскакивают.

imul ★★★★★
()
Ответ на: комментарий от AS

eth0.1726 - это просто имя, а VLAN ID может оказаться и не 1726

Anti4it
Это можно в /proc/net/vlan/ посмотреть, там создаётся каталог с номером vlan.

imul ★★★★★
()
Ответ на: комментарий от imul

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

Сам голову сломал. По мануалам вроде все просто было, а теперь 2 дня мучаюсь. Провайдер говорит что что-то блокирует, скорее всего firewall. Но в iptables правила создавал как писал выше. Пинга нет...

Anti4it
() автор топика
Ответ на: комментарий от AS

iptables разве отключается окончательно? Искал в сети информацию по этому поводу, натыкался только на сброс настроек 

Можно также использовать команды iptables для того, чтобы остановить файрвол и удалить все правила:
# iptables -F
# iptables -X
# iptables -t nat -F
# iptables -t nat -X
# iptables -t mangle -F
# iptables -t mangle -X
# iptables -P INPUT ACCEPT
# iptables -P OUTPUT ACCEPT
# iptables -P FORWARD ACCEPT
Anti4it
() автор топика
Ответ на: комментарий от Anti4it

По мануалам вроде все просто было, а теперь 2 дня мучаюсь.

По факту всё, действительно, просто. Либо какая-то мелочь в глаза не бросается, либо у провайдера косяк. Можешь попробовать на втором компьютере (если есть) то же самое сделать (с другим IP, разумеется, но тем же VLAN ID) и их напрямую соединить (кроссовером, скорее всего; хотя сейчас сетевые карты с авто-MDI-X уже не редкость).

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от Anti4it

Искал в сети информацию по этому поводу, натыкался только на сброс настроек

Ну да. Если правил нет, то, считай, отключен.

AS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Загрузка GRUB'ом из матрёшки блочных устройств
Admin
Помогите разобраться с правильным «туннелированием» трафика →