LINUX.ORG.RU
ФорумAdmin

Виртуальная сеть и маршруты.

 , ,


0

1

Доброго всем дня.

Ситуация такая:

Есть сервер с внешним белым адресом (пусть будет 2.3.4.5). На нем я поднимаю tun интерфейс (пусть будет tunS). Этот интерфейс имеет адрес 10.0.0.1

Подключаются к 2.3.4.5 клиенты и каждому я выдаю ip адрес из заданного интервала (192.168.1.2-192.168.1.100 с маской в 24 бита).

Теперь клиент.

Подключается, регистрируется и получает адрес, например 192.168.0.2/24. У клиента тоже есть tun (пусть будет tunC) интерфейс, которому я назначаю этот адрес и маску. + я добавляю маршрут на 10.0.0.1 на этот девайс «route add -host 10.0.0.1 dev tunC»

Все кажется вполне работает. Клиент видит сервер, может сходить на его ресурсы и тд.

Но клиенты не видят друг друга.

Если я не сервере добавлю маршрут «route add -net 192.168.1.0/24 dev tunS» то все друг друга начинают видеть, я могу с одного клиента увидеть файлы другого и тд.

Но при пинге я получаю примерно следующее:

$ ping 192.168.1.3
PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data.
64 bytes from 192.168.1.3: icmp_seq=1 ttl=63 time=112 ms
From 10.0.0.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.1.3)
64 bytes from 192.168.1.3: icmp_seq=2 ttl=63 time=101 ms
From 10.0.0.1: icmp_seq=3 Redirect Host(New nexthop: 192.168.1.3)
64 bytes from 192.168.1.3: icmp_seq=3 ttl=63 time=100 ms

Если серверу на tunS повесить адрес из этого же диапазона (например 192.168.1.1), то ситуация не меняется.

Что вполне, мне кажется, логичным. Ошибка пропадает, если я клиентам не прописывают маршрут на 10.0.0.1. Понятно, что при этом я не вижу сервер.

Так вот где б почитать как правильно сделать подобную схему (объединения клиентов в одну сеть), чтоб они и друг друга видели и видели сервер?



Последнее исправление: seryoga (всего исправлений: 1)

Ответ на: комментарий от hills_of_eternity

нет.

Своё пишу, чтоб разобраться.

В общем-то хочу просто объединить пару железок в одну сеть виртуальную. Чтоб с работы так раз ... и в домашний ноут и в домашний NAS. Или с телефона, если под андроид осилю что-то собрать, лол.

Вот оно уже в принципе работает, кроме совершенного непонимания мной маршрутизации в этой схеме и как следствие косяков с Redirect Host(New nexthop: 192.168.1.3)

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

да да. Мне хост вполне резонно говорит, что через него не надо соседу орать, если в одной подсети все. Я пробовал клиентам раздавать адреса с маской в 32 и на сервере прописывать маршруты на них, по мере поступления клиентов. Но вообще все перестало работать.

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

Получается, ты пытаешься отправлять пакеты в сеть 192.168.1.0/24 по маршруту через 10.0.0.0? А там форвардинг нормально настроен? Что трассировка покажет?

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

А там форвардинг нормально настроен?

вот я и не знаю, за этим и спрашиваю.

Сейчас у меня:

Мой адрес — 192.168.1.2, домашний ноут — 192.168.1.3; пинг идет с редиректом;

$ ping 192.168.1.3
PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data.
64 bytes from 192.168.1.3: icmp_seq=1 ttl=63 time=100 ms
From 10.0.0.1: icmp_seq=2 Redirect Host(New nexthop: 192.168.1.3)

часть таблицы с маршрутами

...............
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 tunC
10.0.0.1        0.0.0.0         255.255.255.255 UH        0 0          0 tunC

трейс вывглядит так:

$ tracepath 192.168.0.3
 1?: [LOCALHOST]                                         pmtu 1500
 1:  10.0.0.1                                            51.332ms 
 1:  10.0.0.1                                            74.668ms 
 2:  192.168.1.3                                         172.272ms reached
     Resume: pmtu 1500 hops 2 back 2 

Вот что на стороне сервера; маршрут прописан только так:

192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 tunS

сам tunS

tunS      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.0.0.1  P-t-P:10.0.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING  MTU:1500  Metric:1
          RX packets:138491 errors:0 dropped:0 overruns:0 frame:0
          TX packets:138244 errors:0 dropped:8 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:106948772 (106.9 MB)  TX bytes:107056961 (107.0 MB)

Понимаю, что где-то что-то не так...

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

А, еще.

В принципе я пакет с icmp рекдиректом могу дропнуть и это даже работает, но это костыль и заметание проблемы, имхо.

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

В общем решил так:

На сервере к интерфейсу venet0 (это вообще vps у time4vpn он где-то в виртуалке крутится) прибил адрес 192.168.1.1 (алиас на venet0:2 ) Клиенты же получают с 192.168.1.2 - ...

и у клиентов теперь нет маршрута на 10.0.0.1 им вообще про него знать не обязательно. Они теперь прекрасно видят 192.168.1.1.

Пинги идут нормально. Файлы качаются, видео с малиинки смотрится :)

Не знаю на сколько это правильно, но вроде работает.

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

сам пишу.

Знаю, что их много, мне просто интересно.

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

Это правильный вариант.

В твоём случае была проблема, что пакет уходил на один адрес, а возвращался совсем с другого.

itn ★★★
()

Всем спасибо. вроде работает.

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

в схеме с прибитым IP на другом интерфейсе не работал trace. То есть виртуальный интерфейс уменьшал TTL, но так как маршрута на адрес 10.0.0.1 уже не было, система делала вот так:

 1?: [LOCALHOST]                                         pmtu 1500
 1:  no reply
 2:  192.168.1.3                                         399.548ms reached
     Resume: pmtu 1500 hops 2 back 2 

Решил путем увеличения ttl на стороне сервера (Когда получаю пакет от клиент). Теперь идет вот так:

1?: [LOCALHOST]                                         pmtu 1500
 1:  192.168.1.3                                         107.797ms reached
 1:  192.168.1.3                                         160.681ms reached
     Resume: pmtu 1500 hops 1 back 1 

вроде все правильно, но цифры почему-то сильно расходятся. ping до 192.168.1.3 примерно равен как раз 107ms (пинг для сервера идет ~55ms). То есть трейс первым же хопом получил нужный адрес. А зачем он второй запрос сделал и почему цифра отличается так странно (как будто запрос только до сервера дошел)?

seryoga
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.