forum.opennet.ru - "маршрутизация на CentOS" (28)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"маршрутизация на CentOS"

Форум Открытые системы на сервере (Маршрутизация, NAT / Linux)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"маршрутизация на CentOS"	+/–
Сообщение от Aleks305 (ok) on 21-Апр-11, 13:36
Всем привет! В Linux новичок. Проблема небольшая, но надо как-то решить. Есть три сети 10.0.16.0/24 (eth0), 192.168.30.0/24(eth2), 192.168.10.0/24(eth1). Есть комп с тремя сетевухами с CentOS 5, надо поднять маршрутзацию. Почитал мануалы - вроде бы все легко, но не получилось. заменил в /etc/sysctl.conf net.ipv4.ip_forward =1 сделал echo 1 > /proc/sys/net/ipv4/ip_forward посмотрел [root@shluzproba ~]# cat /proc/sys/net/ipv4/ip_forward 1 обнулил правила iptables iptables --flush Проверил, что правил нет [root@shluzproba ~]# service iptables status Таблица: filter Chain INPUT (policy ACCEPT) num target prot opt source destination Chain FORWARD (policy ACCEPT) num target prot opt source destination Chain OUTPUT (policy ACCEPT) num target prot opt source destination Вроде бы должно уже работать, но нет Пингую хост за интерфейсом eth0 - все ок [root@shluzproba ~]# ping 10.0.16.52 PING 10.0.16.52 (10.0.16.52) 56(84) bytes of data. 64 bytes from 10.200.0.52: icmp_seq=1 ttl=128 time=0.365 ms 64 bytes from 10.200.0.52: icmp_seq=2 ttl=128 time=0.227 ms 64 bytes from 10.200.0.52: icmp_seq=3 ttl=128 time=0.234 ms Пингую хост за интерфейсом eth2 - все ок [root@shluzproba ~]# ping 192.168.30.5 PING 192.168.30.5 (192.168.30.5) 56(84) bytes of data. 64 bytes from 192.168.30.5: icmp_seq=1 ttl=128 time=1.74 ms 64 bytes from 192.168.30.5: icmp_seq=2 ttl=128 time=0.189 ms Пытаюсь с интерфейса eth2 пингануть хост за eth0 [root@shluzproba ~]# ping 10.0.16.52 -I eth2 PING 10.0.16.52 (10.0.16.52) from 192.168.30.1 eth2: 56(84) bytes of data. From 192.168.30.1 icmp_seq=2 Destination Host Unreachable From 192.168.30.1 icmp_seq=3 Destination Host Unreachable From 192.168.30.1 icmp_seq=4 Destination Host Unreachable Команда route выводит [root@shluzproba ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.30.0 * 255.255.255.0 U 0 0 0 eth2 192.168.200.0 * 255.255.255.0 U 0 0 0 eth1 169.254.0.0 * 255.255.0.0 U 0 0 0 eth2 10.0.16.0 * 255.255.255.0 U 0 0 0 eth0 default cr.ld 0.0.0.0 UG 0 0 0 eth0 не пойму, в чем может быть проблема
Ответить \| Правка \| Cообщить модератору

Оглавление

маршрутизация на CentOS, PavelR, 13:44 , 21-Апр-11, (1)

маршрутизация на CentOS, Aleks305, 16:02 , 22-Апр-11, (2)

маршрутизация на CentOS, Aleks305, 20:31 , 22-Апр-11, (3)

маршрутизация на CentOS, PavelR, 20:43 , 22-Апр-11, (4)

маршрутизация на CentOS, Aleks305, 22:58 , 22-Апр-11, (5)

маршрутизация на CentOS, PavelR, 07:21 , 23-Апр-11, (6)

маршрутизация на CentOS, Aleks305, 21:28 , 23-Апр-11, (7)

маршрутизация на CentOS, LSTemp, 03:02 , 25-Апр-11, (8)

маршрутизация на CentOS, Aleks305, 12:29 , 25-Апр-11, (9)

маршрутизация на CentOS, PavelR, 15:08 , 25-Апр-11, (10)

маршрутизация на CentOS, Aleks305, 16:23 , 25-Апр-11, (11)

маршрутизация на CentOS, PavelR, 16:44 , 25-Апр-11, (12)

маршрутизация на CentOS, Aleks305, 16:51 , 26-Апр-11, (13)

маршрутизация на CentOS, PavelR, 17:15 , 26-Апр-11, (14)
маршрутизация на CentOS, Aleks305, 17:57 , 26-Апр-11, (15)
маршрутизация на CentOS, PavelR, 18:58 , 26-Апр-11, (16)
маршрутизация на CentOS, Aleks305, 20:21 , 26-Апр-11, (17)
маршрутизация на CentOS, PavelR, 20:37 , 26-Апр-11, (18)
маршрутизация на CentOS, PavelR, 20:41 , 26-Апр-11, (19)
маршрутизация на CentOS, Aleks305, 20:46 , 26-Апр-11, (20)
маршрутизация на CentOS, PavelR, 21:20 , 26-Апр-11, (21)
маршрутизация на CentOS, Aleks305, 00:09 , 27-Апр-11, (22)
маршрутизация на CentOS, PavelR, 00:29 , 27-Апр-11, (23)
маршрутизация на CentOS, LSTemp, 01:02 , 27-Апр-11, (24)
маршрутизация на CentOS, Aleks305, 22:27 , 27-Апр-11, (25)
маршрутизация на CentOS, Aleks305, 10:36 , 28-Апр-11, (26)
маршрутизация на CentOS, reader, 11:07 , 28-Апр-11, (27)
маршрутизация на CentOS, Aleks305, 14:22 , 28-Апр-11, (28)

Сообщения по теме [Сортировка по времени | RSS]

1. "маршрутизация на CentOS" +/–

Сообщение от PavelR (??) on 21-Апр-11, 13:44

1) Используйте -I IP.ADD.RE.SS <<<--------------- в этом причина.
2) Возможно, также, хост 10.0.16.52 не знает маршрута к сети 192.168.30/24 и не использует ваш хост в качестве шлюза по умолчанию.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "маршрутизация на CentOS" +/–

Сообщение от Aleks305 (ok) on 22-Апр-11, 16:02

> 1) Используйте -I IP.ADD.RE.SS <<<--------------- в этом причина.
> 2) Возможно, также, хост 10.0.16.52 не знает маршрута к сети 192.168.30/24 и
> не использует ваш хост в качестве шлюза по умолчанию.
Спасибо за ответ! возник следующий вопрос по NAT в iptables
ввожу такую команду
iptables -t nat -A POSTROUTING -s 10.200.0.0/16 -o eth2 -j SNAT --to-source 50.0.0.1, где
10.200.0.0/24 - внутренняя сеть
eth2 - внешний интерфейс
50.0.0.1 - внешний адрес eth2
далее смотрю статистику
[root@shluzproba network-scripts]# iptables -L -v -n -t nat
Chain PREROUTING (policy ACCEPT 50915 packets, 8492K bytes)
pkts bytes target     prot opt in     out     source               destination
Chain POSTROUTING (policy ACCEPT 484 packets, 29315 bytes)
pkts bytes target     prot opt in     out     source               destination
    0     0 SNAT       all  --  *      eth2    10.200.0.0/24        0.0.0.0/0           to:50.0.0.1
Chain OUTPUT (policy ACCEPT 373 packets, 22991 bytes)
pkts bytes target     prot opt in     out     source               destination
Я так понимаю, что под правила NAT пакеты из внутренней сети не попадают. Что я делаю не так?
Можно ли просмотреть помимо указанной выше команды таблицу трансляций nat?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "маршрутизация на CentOS" +/–

Сообщение от Aleks305 (ok) on 22-Апр-11, 20:31

up

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "маршрутизация на CentOS" +/–

Сообщение от PavelR (??) on 22-Апр-11, 20:43

> up
ап ? тут что, телепаты сидят ?
первое сообщение и второй вопрос вообще не кореллируют между собой.
Сколько стоит ответ на вопрос "каковы настройки сетевых интерфейсов и таблиц маршрутизации" ? Можно ли воспользоваться "50/50" или "звонком к другу" ?

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "маршрутизация на CentOS" +/–

Сообщение от Aleks305 (ok) on 22-Апр-11, 22:58

>> up
> ап ? тут что, телепаты сидят ?
> первое сообщение и второй вопрос вообще не кореллируют между собой.
> Сколько стоит ответ на вопрос "каковы настройки сетевых интерфейсов и таблиц маршрутизации"
> ? Можно ли воспользоваться "50/50" или "звонком к другу" ?
извините конечно, может не очень хорошо вопрос задал, мало объяснений дал. Буду исправляться!
схема такая: сеть 10.200.0.0/16 - eth0(10.200.16.54/16) - eth2 (50.0.0.1/24) - хост 50.0.0.5
Схема чисто тестовая,для дальнейшего переноса на реальную сеть.
Роутинг между интерфейсами включил, без iptables хосты из LAN пингуют и пользуются сервисами хоста 50.0.0.5(http,ftp,telnet).
То есть все ок. Но в реальной жизни необходимо натить LAN, ну и другие настройки iptables. Если с цепочками forward, input, output разобрался, то вот с NAT чего-то не получается. Поэтому прошу подсказать, как делать nat внутренней сети.
Таблица маршрутизации:
[root@shluzproba ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
50.0.0.0          *               255.255.255.0   U     0      0        0 eth2
192.168.200.0   *               255.255.255.0   U     0      0        0 eth1
169.254.0.0     *               255.255.0.0     U     0      0        0 eth2
10.200.0.0      *               255.255.0.0     U     0      0        0 eth0
default         cr.ld           0.0.0.0         UG    0      0        0 eth0
Кстати, еще вопрос, не пойму что за сеть  169.254.0.0 на eth2.
eth1 в дальнейшем предполагается выделить под DMZ

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

6. "маршрутизация на CentOS" +/–

Сообщение от PavelR (??) on 23-Апр-11, 07:21

> схема такая: сеть 10.200.0.0/16 - eth0(10.200.16.54/16) - eth2 (50.0.0.1/24) - хост 50.0.0.5
--
> Схема чисто тестовая,для дальнейшего переноса на реальную сеть.
> Роутинг между интерфейсами включил, без iptables хосты из LAN пингуют и пользуются
> сервисами хоста 50.0.0.5(http,ftp,telnet).
из этого делаем вывод, что 5.0.0.5 знает маршрут к 10.200.0.0/16
> То есть все ок. Но в реальной жизни необходимо натить LAN, ну
> и другие настройки iptables. Если с цепочками forward, input, output разобрался,
> то вот с NAT чего-то не получается. Поэтому прошу подсказать, как
> делать nat внутренней сети.
>Chain POSTROUTING (policy ACCEPT 484 packets, 29315 bytes)
> pkts bytes target     prot opt in     out     source               destination
>    0     0 SNAT       all  --  *      eth2    10.200.0.0/24        0.0.0.0/0      to:50.0.0.1
не, это правило в общем-то верное правило, но по отдельности правила мало чего значат. вдруг у вас там в -t filter FORWARD DROP/REJECT стоит ? приводите вывод iptables-save.

а еще есть ip ru sh / ip ro sh (policy routing) - но я полагаю вы им еще не занимались ? :-)
> Таблица маршрутизации:
> [root@shluzproba ~]# route
шлюз по умолчанию у вас как-то в локалку смотрит, хотя это не суть важно в данном случае.
> Кстати, еще вопрос, не пойму что за сеть  169.254.0.0 на eth2.
самоконфигурация интерфейсов. Возможно, за это дело какой-то специальный даймон отвечает.

> eth1 в дальнейшем предполагается выделить под DMZ
------------
в сетях важны не только настройки одного хоста, но и таблицы маршрутов на всех участвующих хостах. Пакеты-то в две стороны ходят. Но вроде как к данному "стенду" отношения не имеет.
откройте для себя волшебный мир tcpdump и научитесь пакетики на интерфейсах ловить. на всех интерфейсах, в крайнем случае - гденть да найдется, если ip_forward включен и маршрутизация сложная.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "маршрутизация на CentOS" +/–

Сообщение от Aleks305 (ok) on 23-Апр-11, 21:28

Спасибо за ответ. Сейчас нет возможности привести вывод конфига iptables. Но если пакеты ходят между хостами, то drop там точно нет.
смущают нулевые счетчики напротив правила nat и то,что нельзя легко посмотреть таблицу трансляций, как например в cisco-роутерах.
С помощью tcpdump возможно как-то увидеть преобразование???
Шлюз по умолчанию действительно известен через локалку, но это нормально, так и задумано.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "маршрутизация на CentOS" +/–

Сообщение от LSTemp (ok) on 25-Апр-11, 03:02

>[оверквотинг удален]
>> ? Можно ли воспользоваться "50/50" или "звонком к другу" ?
> извините конечно, может не очень хорошо вопрос задал, мало объяснений дал. Буду
> исправляться!
> схема такая: сеть 10.200.0.0/16 - eth0(10.200.16.54/16) - eth2 (50.0.0.1/24) - хост 50.0.0.5
> Схема чисто тестовая,для дальнейшего переноса на реальную сеть.
> Роутинг между интерфейсами включил, без iptables хосты из LAN пингуют и пользуются
> сервисами хоста 50.0.0.5(http,ftp,telnet).
> То есть все ок. Но в реальной жизни необходимо натить LAN, ну
> и другие настройки iptables. Если с цепочками forward, input, output разобрался,
> то вот с NAT чего-то не получается. Поэтому прошу подсказать, как
примерно так:
-A POSTROUTING -o внешний_интерфейс_сервера -j SNAT внешний_IP_сервера_на интерфейсе
после этого все пакеты которые приходят из цепочки forward (то есть являются транзитными для данного сервера) будут при покидании интерфейса заменять адрес отправителя на адрес сервака. а при получении  - обратная модификация: адрес получателя (коим в приходящем пакете будет сервак) заменится на адрес в локальной сети и пакет протолкнется в нее.

1) LAN->WAN:
LAN_IP:LAN_PORT->[SNAT]->SERV_IP:SERV_PORT----->DST
связка LAN_IP:LAN_PORT=SERV_IP:SERV_PORT запоминается сетевым фильтром сервака.
2) WAN->LAN
DST----->SERV_IP:SERV_PORT
сервак вспоминает связку, меняет в пакете получателя на LAN_IP:LAN_PORT и форвардит его в локалку.
иногда может немного сбивать с толку, что преобразование явно указывается только в одном направлении движения пакетов. просто обратная операция выполняется автоматически на основе уже существующих данных.
>[оверквотинг удален]
>          255.255.0.0
>    U     0
>    0
> 0 eth0
> default         cr.ld
>         0.0.0.0
>       UG    0
>      0
>   0 eth0
> Кстати, еще вопрос, не пойму что за сеть  169.254.0.0 на eth2.
ну не ленитесь:
http://otvety.google.ru/otvety/thread?tid=058116aff0d47af8
NOZEROCONF=yes в /etc/sysconfig/network? зависит от дистрибутива.
> eth1 в дальнейшем предполагается выделить под DMZ

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

9. "маршрутизация на CentOS" +/–

Сообщение от Aleks305 (ok) on 25-Апр-11, 12:29

Спасибо за ответы!
вроде бы все получилось, но странная вещь происходит. В логах сервера 50.0.0.5 я вижу,что подключение к нему идет с 50.0.0.1(внешний ip шлюза моего), хотя соединенение я инициирую с LAN с хоста 10.200.16.60 - то есть все ок.
Но почему если я с этого сервера(50.0.0.5) пингую хост 10.200.16.60 ответ мне приходит именно с него, то есть с ip 10.200.16.60, а не с пронатеного ip, то есть с 50.0.0.1. Также я подключаюсь легко к web-серверу на 10.200.16.60 c 50.0.0.5.
Может это конечно происходит потому что хосты подключены напрямую к роутеру. Но все равно, не пойму почему происходит nat пакетов обратных, если я инициализирую соединение из Интернет(условно) в LAN.
Таблица iptables сейчас предельно проста
[root@shluzproba ~]# service iptables status
Таблица: filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  10.200.0.0/16        50.0.0.0/24
Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination
Таблица: nat
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination
Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination
1    SNAT       all  --  10.200.16.60         0.0.0.0/0           to:50.0.0.1
Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

10. "маршрутизация на CentOS" +/–

Сообщение от PavelR (??) on 25-Апр-11, 15:08

>  Но почему если я с этого сервера(50.0.0.5) пингую хост 10.200.16.60 ответ
> мне приходит именно с него, то есть с ip 10.200.16.60, а
> не с пронатеного ip, то есть с 50.0.0.1. Также я подключаюсь
> легко к web-серверу на 10.200.16.60 c 50.0.0.5.
--
> Может это конечно происходит потому что хосты подключены напрямую к роутеру. Но
> все равно, не пойму почему происходит nat пакетов обратных, если я
> инициализирую соединение из Интернет(условно) в LAN.
--
=) ну так и должно быть. как-бы "внешний интернет" не должен бы знать вашей внутренней структуры (приватной) сети LAN, и тогда он бы не знал куда стучаться. Но поскольку он знает куда стучаться, то и стучится =) и всё у него получается. Натиться оно и не должно. Линукс в этом плане умный и поступает в принципе-то верно )
Чтобы оно не могло туда достучаться - как раз таки для этого и придуманы файрволлы. Это надо отдельно прописывать в правилах. Без отдельного прописывания - да, провайдер может из физического сегмента вашего подключения пытаться установить связь с вашим внутренним приватным сегментом. всё так и работает, правда не все об этом задумываются  =)  ;-)
--
> Таблица iptables сейчас предельно проста
будет посложнее - будет другая картина )

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

11. "маршрутизация на CentOS" +/–

Сообщение от Aleks305 (ok) on 25-Апр-11, 16:23

>> Таблица iptables сейчас предельно проста
> будет посложнее - будет другая картина )
в cisco когда настраиваешь nat,если пытаешься пингануть внутренний ip какой-нить, ответ приходит от ip внешнего. Вот по этому я и призадумался...
настроил проброс порта с внутренней машины на внешней ip-шлюза. Для этого понадобилось 2 команды:
[root@shluzproba ~]# iptables -t nat -A PREROUTING -d 50.0.0.1 -p tcp --dport 80 -j DNAT --to-destination 10.200.16.60:80
iptables -A FORWARD -i eth2 -d 10.200.16.60 -p tcp --dport 80 -o eth0 -j ACCEPT
Без второй команды по http://50.0.0.1 соединение не устанавливалось. За то потом доступ к web можно получить и по http://50.0.0.1 и http://10.200.16.60.
Но это похоже те же грабли, которые описаны в прошлом сообщении

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "маршрутизация на CentOS" +/–

Сообщение от PavelR (??) on 25-Апр-11, 16:44

>[оверквотинг удален]
> приходит от ip внешнего. Вот по этому я и призадумался...
> настроил проброс порта с внутренней машины на внешней ip-шлюза. Для этого понадобилось
> 2 команды:
> [root@shluzproba ~]# iptables -t nat -A PREROUTING -d 50.0.0.1 -p tcp --dport
> 80 -j DNAT --to-destination 10.200.16.60:80
>  iptables -A FORWARD -i eth2 -d 10.200.16.60 -p tcp --dport 80
> -o eth0 -j ACCEPT
> Без второй команды по http://50.0.0.1 соединение не устанавливалось. За то потом доступ
> к web можно получить и по http://50.0.0.1 и http://10.200.16.60.
> Но это похоже те же грабли, которые описаны в прошлом сообщении
по-видимому, циска обрабатывает пакеты попакетно, а линукс - с учетом информации об соединении.
решить проблему излишней доступности можно так:
1) проверка -m conntrack ! --ctstate DNAT + DROP всего что не прошло, или наоборот =)
2) -j DROP до ната, либо в -t nat либо в -t mangle (это надо уточнить)

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "маршрутизация на CentOS" +/–

Сообщение от Aleks305 (ok) on 26-Апр-11, 16:51

Продолжаю дальнейшее тестирование.
Установили openvpn для подключения удаленных клиентов:
Файл конфигурации сервера openvpn
local 50.0.0.1
port 1194
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/vpnserver.crt
key /etc/openvpn/vpnserver.key
dh /etc/openvpn/dh1024.pem
server 192.168.100.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/ipp.txt
push "route 10.200.0.0 255.255.0.0"
push "redirect-gateway"
push "dhcp-option DNS 10.200.4.96"
push "dhcp-option DNS 10.200.4.97"
client-to-client
keepalive 10 120
cipher AES-128-CBC   # AES
comp-lzo
user nobody
group nobody
persist-key
persist-tun
log /etc/openvpn/openvpn.log
verb 3
Правила iptables
*filter
:INPUT DROP [216986:21628284]
:FORWARD ACCEPT [272:17116]
:OUTPUT ACCEPT [19505:4280978]
:aleks - [0:0]
-A INPUT -d 50.0.0.1 -i eth2 -p udp -m udp --dport 1194 -j ACCEPT #разрешаю подключение из нета для подключения к openvpn
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT #разрешаю входящий трафик на шлюз из LAN, который инициирован исходящим из шлюза
-A INPUT -i tun0 -p icmp -j ACCEPT #разрешаю входящий icmp на шлюз для vpn-клиентов
-A FORWARD -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT # возвращается из Интернет трафик, который инициирован пользователями LAN
-A FORWARD -s 10.200.16.60 -d 50.0.0.5 -o eth2 -j ACCEPT # разрешаю пользовательский трафик из LAN(а именно с единственного хоста)
-A FORWARD -d 10.200.16.60 -i eth2 -o eth0 -p tcp -m tcp --dport 80 -j ACCEPT #для проброса порта через шлюз в инет
-A FORWARD -i tun0 -o eth0 -j ACCEPT # разрешаю трафик VPN-пользователей в LAN
-A FORWARD -j DROP
COMMIT
# Completed on Tue Apr 26 19:33:56 2011
# Generated by iptables-save v1.3.5 on Tue Apr 26 19:33:56 2011
*nat
:PREROUTING ACCEPT [372396:53664802]
:POSTROUTING ACCEPT [3246:203479]
:OUTPUT ACCEPT [3066:193693]
-A PREROUTING -d 50.0.0.1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.200.16.60:80  # dnat для проброса web-сервера наружу
-A POSTROUTING -s 10.200.16.60 -o eth2 -j SNAT --to-source 50.0.0.1 # nat LAN
COMMIT
Сервер запускается - все в порядке. Клиент подключается - вроде бы тоже все в порядке...но не все
Возникли следующие вопросы:
1) Почему клиент получает адрес 192.168.100.6/30 с шлюзом 192.168.100.5, причем 192.168.100.5 - не пингуется, а пингуется 192.168.100.1
2) Так и должно быть если tun0 при формировании получает 2 ip?
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:192.168.100.1  P-t-P:192.168.100.2  Mask:255.255.255.255
3) Как установить шлюз по умолчанию для клиента 192.168.0.1 а не 192.168.0.5,которого фактически нет
Смотрю таблицу маршрутизации хоста netstat -nr
Вижу,что подсеть 10.200.0.0/16 хост получает(см. конфиг сервера) gateway для данной сети 192.168.100.5.
Я так понимаю,что вся проблема из-за этого 192.168.100.5
Подскажите , пожалуйста!

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "маршрутизация на CentOS" +/–

Сообщение от PavelR (??) on 26-Апр-11, 17:15

> Продолжаю дальнейшее тестирование.
> Установили openvpn для подключения удаленных клиентов:
> Сервер запускается - все в порядке. Клиент подключается - вроде бы тоже
> все в порядке...но не все
> Возникли следующие вопросы:
> 1) Почему клиент получает адрес 192.168.100.6/30 с шлюзом 192.168.100.5, причем 192.168.100.5
> - не пингуется, а пингуется 192.168.100.1
> 2) Так и должно быть если tun0 при формировании получает 2 ip?
Вы не только пишите на форум, но еще и читайте его иногда.
Парой дней ранее отвечали уже на идентичный вопрос.
Используйте tap (L2 encap) а не tun (L3 IP-IP туннель).

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "маршрутизация на CentOS" +/–

Сообщение от Aleks305 (ok) on 26-Апр-11, 17:57

>[оверквотинг удален]
>> Установили openvpn для подключения удаленных клиентов:
>> Сервер запускается - все в порядке. Клиент подключается - вроде бы тоже
>> все в порядке...но не все
>> Возникли следующие вопросы:
>> 1) Почему клиент получает адрес 192.168.100.6/30 с шлюзом 192.168.100.5, причем 192.168.100.5
>> - не пингуется, а пингуется 192.168.100.1
>> 2) Так и должно быть если tun0 при формировании получает 2 ip?
> Вы не только пишите на форум, но еще и читайте его иногда.
> Парой дней ранее отвечали уже на идентичный вопрос.
> Используйте tap (L2 encap) а не tun (L3 IP-IP туннель).
Не пойму, а почему я не могу использовать tun. В чем причина? Почему не получается с ним?

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

16. "маршрутизация на CentOS" +/–

Сообщение от PavelR (??) on 26-Апр-11, 18:58

>[оверквотинг удален]
>>> все в порядке...но не все
>>> Возникли следующие вопросы:
>>> 1) Почему клиент получает адрес 192.168.100.6/30 с шлюзом 192.168.100.5, причем 192.168.100.5
>>> - не пингуется, а пингуется 192.168.100.1
>>> 2) Так и должно быть если tun0 при формировании получает 2 ip?
>> Вы не только пишите на форум, но еще и читайте его иногда.
>> Парой дней ранее отвечали уже на идентичный вопрос.
>> Используйте tap (L2 encap) а не tun (L3 IP-IP туннель).
> Не пойму, а почему я не могу использовать tun. В чем причина?
> Почему не получается с ним?
Всё получается и работает в строгом соответствии с тем, что вы запросили.
Только вы хотите не этого, а как сделать так, чтобы получалось так как вы хотите - ответ: используйте tap.
Насколько я понимаю - у вас всё работает.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

17. "маршрутизация на CentOS" +/–

Сообщение от Aleks305 (ok) on 26-Апр-11, 20:21

> Всё получается и работает в строгом соответствии с тем, что вы запросили.
Что-то получается, но не все. Мне хотелось бы давать удаленным пользователям доступ к ресурсам LAN. На данный момент с tun не удается пользователю с хоста 50.0.0.5 получить доступ к 10.200.16.60

> Только вы хотите не этого, а как сделать так, чтобы получалось так
> как вы хотите - ответ: используйте tap.
А для чего тогда используется tun?
Мне казалось, что решение по удаленному доступу с tun тоже работает. Просто, насколько я понял, подсеть VPN(192.168.100.0/24) разбивается на подсети /30, начиная с 192.168.100.4/30.
Почему на клиенте gateway устанавливается 192.168.100.5/30, сам хост получает 192.168.100.6/30.

> Насколько я понимаю - у вас всё работает.
Не работает, так не могу достучаться ни до шлюза 192.168.100.5, ни до хоста 10.200.16.60.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "маршрутизация на CentOS" +/–

Сообщение от PavelR (??) on 26-Апр-11, 20:37

>> Всё получается и работает в строгом соответствии с тем, что вы запросили.
> Что-то получается, но не все. Мне хотелось бы давать удаленным пользователям доступ
> к ресурсам LAN. На данный момент с tun не удается пользователю
> с хоста 50.0.0.5 получить доступ к 10.200.16.60
Я не вижу проблем удаленному пользователю получить доступ с использованием tun, кроме некорректной настройки маршрутизатора.
Маршрутизацию и прохождение пакетов по интерфейсам можно легко отладить используя tcpdump.
> Мне казалось, что решение по удаленному доступу с tun тоже работает. Просто,
> насколько я понял, подсеть VPN(192.168.100.0/24) разбивается на подсети /30, начиная с
> 192.168.100.4/30.
> Почему на клиенте gateway устанавливается 192.168.100.5/30, сам хост получает 192.168.100.6/30.
Почитайте документацию по openvpn + есть такой сайт, http://google.ru -  ну просто улетный сайт, рекомендую.
>> Насколько я понимаю - у вас всё работает.
> Не работает, так не могу достучаться ни до шлюза 192.168.100.5, ни до
> хоста 10.200.16.60.
Файрволл открыть не пробовали ?

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

19. "маршрутизация на CentOS" +/–

Сообщение от PavelR (??) on 26-Апр-11, 20:41

> Почитайте документацию по openvpn.
Специально для новичков обычно делают раздел FAQ.
Чтобы не сильно утруждать вас поисками, даю прямую ссылку:
http://openvpn.net/index.php/open-source/faq/77-server/273-q...

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

20. "маршрутизация на CentOS" +/–

Сообщение от Aleks305 (ok) on 26-Апр-11, 20:46

>>> Всё получается и работает в строгом соответствии с тем, что вы запросили.
>> Что-то получается, но не все. Мне хотелось бы давать удаленным пользователям доступ
>> к ресурсам LAN. На данный момент с tun не удается пользователю
>> с хоста 50.0.0.5 получить доступ к 10.200.16.60
> Я не вижу проблем удаленному пользователю получить доступ с использованием tun, кроме
> некорректной настройки маршрутизатора.
> Маршрутизацию и прохождение пакетов по интерфейсам можно легко отладить используя tcpdump.
Я тоже все больше и больше склоняюсь к тому, чтобы попробовать отладить работу с помощью tcpdump, просто опыта работы с Linux мало.
>> Мне казалось, что решение по удаленному доступу с tun тоже работает. Просто,
>> насколько я понял, подсеть VPN(192.168.100.0/24) разбивается на подсети /30, начиная с
>> 192.168.100.4/30.
>> Почему на клиенте gateway устанавливается 192.168.100.5/30, сам хост получает 192.168.100.6/30.
> Почитайте документацию по openvpn + есть такой сайт, http://google.ru -  ну
> просто улетный сайт, рекомендую.
А вы думаете я ничего не читаю? я уже кучу мануалов перерыл, openvpn.net тоже уже постоянно в браузере висит.
>>> Насколько я понимаю - у вас всё работает.
>> Не работает, так не могу достучаться ни до шлюза 192.168.100.5, ни до
>> хоста 10.200.16.60.
> Файрволл открыть не пробовали ?
Полностью не отключал - надо попробовать. Я просто приводил правила в одном из предыдущих сообщений, думал что их достаточно будет.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

21. "маршрутизация на CentOS" +/–

Сообщение от PavelR (??) on 26-Апр-11, 21:20

> А вы думаете я ничего не читаю? я уже кучу мануалов перерыл,
> openvpn.net тоже уже постоянно в браузере висит.
В факе все задаваемые вами вопросы относительно "device tun" _разжеваны_.
>> Файрволл открыть не пробовали ?
> Полностью не отключал - надо попробовать. Я просто приводил правила в одном
> из предыдущих сообщений, думал что их достаточно будет.
ну вообще говоря вы их от сообщения к сообщению "слегка меняете", это во-первых, а во-вторых, приводите "слегка странно", собирая кусками, а не приводите полный вывод команды.
Если не умеете работать с файрволлами - значит сначала все разрешаем, а потом начинаем закрывать, "пока не сломается". У вас там комментами всё откомментарено, а вот коммента "разрешаю трафик к VPN-пользователям из LAN" - нету.
Вообще iptables "налеплен", так не делается. тот же lo интерфейс "слегка закрыт"...
-A FORWARD -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT
рекомендую заменить на  правило без учета интерфейса, тогда под него будут подпадать все пакеты, идущие в ответ на некое разрешающее правило:
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

Тогда можно писать:
#
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
# разрешаю трафик VPN-пользователей в LAN, ответные пакеты пройдут автоматически
# Note: трафик от лан к впн-пользователям не разрешается, только инициированный впн-пользователем!!
-A FORWARD -i tun0 -o eth0 -j ACCEPT
#разрешаю пользовательский трафик из LAN(а именно с единственного хоста) / ответный пройдет автоматически
-A FORWARD -s 10.200.16.60 -d 50.0.0.5 -o eth2 -j ACCEPT
#для проброса порта через шлюз в инет / и ответный тоже будет разрешен автоматически, а не будет подпадать под предыдущее правило.
Т.е. без предыдущего правила доступ по 80 порту к 16.60 будет, а вот сама 16.60 в инет сходить не сможет
-A FORWARD -d 10.200.16.60 -i eth2 -o eth0 -p tcp -m tcp --dport 80 -j ACCEPT
# Ну и на сладкое
-A FORWARD -j DROP
----------
Я вот понять не могу, с какого перепугу вы беретесь одновременно две задачи решать ? впн-ы и файрволл ? По одной надо, неужели понять это сложно, что вероятность закосячить множится ?

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

22. "маршрутизация на CentOS" +/–

Сообщение от Aleks305 (ok) on 27-Апр-11, 00:09

> -A FORWARD -d 10.200.16.60 -i eth2 -o eth0 -p tcp -m tcp --dport 80 -j ACCEPT
Здесь не понял, зачем -m tcp нужно?ведь можно и без него обойтись -p tcp --dport 80
> Я вот понять не могу, с какого перепугу вы беретесь одновременно две
> задачи решать ? впн-ы и файрволл ? По одной надо, неужели
> понять это сложно, что вероятность закосячить множится ?
В пух и прах меня)))спасибо, полезно
Наверное, характер такой, потому и берусь сразу и файрвол и vpn. Понимаю, что надо как Вы указываете...а вот так получается.
Спасибо за ответы вообщем!!!выручаете!Завтра буду продолжать - надо добить!

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

23. "маршрутизация на CentOS" +/–

Сообщение от PavelR (??) on 27-Апр-11, 00:29

>> -A FORWARD -d 10.200.16.60 -i eth2 -o eth0 -p tcp -m tcp --dport 80 -j ACCEPT
> Здесь не понял, зачем -m tcp нужно?ведь можно и без него обойтись
> -p tcp --dport 80
да, действительно. Я не пишу -m, модули сами грузятся. Но это было из ваших же правил скопировано, а у вас - из вывода iptables-save :-)
Если глянуть ман, то получается что -m нужен не всегда, в частном случае есть -p, и его значение сдублирует -m.

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

24. "маршрутизация на CentOS" +/–

Сообщение от LSTemp (ok) on 27-Апр-11, 01:02

>> -A FORWARD -d 10.200.16.60 -i eth2 -o eth0 -p tcp -m tcp --dport 80 -j ACCEPT
> Здесь не понял, зачем -m tcp нужно?ведь можно и без него обойтись
> -p tcp --dport 80
можно. хуже в любом случае не будет.
>> Я вот понять не могу, с какого перепугу вы беретесь одновременно две
>> задачи решать ? впн-ы и файрволл ? По одной надо, неужели
>> понять это сложно, что вероятность закосячить множится ?
> В пух и прах меня)))спасибо, полезно
> Наверное, характер такой, потому и берусь сразу и файрвол и vpn. Понимаю,
> что надо как Вы указываете...а вот так получается.
> Спасибо за ответы вообщем!!!выручаете!Завтра буду продолжать - надо добить!

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

25. "маршрутизация на CentOS" +/–

Сообщение от Aleks305 (ok) on 27-Апр-11, 22:27

Сегодня все получилось - действительно проблема оказалась в файрволе, обратные пакеты из LAN к VPN-клиенту дропались...а так все ок. Начал смотреть дополнительные опции openvpn и появился вопрос по openvpn-auth-pam.so
Если мы в серверном конфиге пропишем
plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login,
то как и где нам добавлять пользователей vpn?
или просто нужно через useradd добавить пользователей?

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

26. "маршрутизация на CentOS" +/–

Сообщение от Aleks305 (ok) on 28-Апр-11, 10:36

> Сегодня все получилось - действительно проблема оказалась в файрволе, обратные пакеты из
> LAN к VPN-клиенту дропались...а так все ок. Начал смотреть дополнительные опции
> openvpn и появился вопрос по openvpn-auth-pam.so
> Если мы в серверном конфиге пропишем
> plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login,
> то как и где нам добавлять пользователей vpn?
> или просто нужно через useradd добавить пользователей?
up

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

27. "маршрутизация на CentOS" +/–

Сообщение от reader (ok) on 28-Апр-11, 11:07

> Сегодня все получилось - действительно проблема оказалась в файрволе, обратные пакеты из
> LAN к VPN-клиенту дропались...а так все ок. Начал смотреть дополнительные опции
> openvpn и появился вопрос по openvpn-auth-pam.so
> Если мы в серверном конфиге пропишем
> plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login,
> то как и где нам добавлять пользователей vpn?
> или просто нужно через useradd добавить пользователей?
да

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

28. "маршрутизация на CentOS" +/–

Сообщение от Aleks305 (ok) on 28-Апр-11, 14:22

>> Сегодня все получилось - действительно проблема оказалась в файрволе, обратные пакеты из
>> LAN к VPN-клиенту дропались...а так все ок. Начал смотреть дополнительные опции
>> openvpn и появился вопрос по openvpn-auth-pam.so
>> Если мы в серверном конфиге пропишем
>> plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login,
>> то как и где нам добавлять пользователей vpn?
>> или просто нужно через useradd добавить пользователей?
> да
да уже получилось...

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "маршрутизация на CentOS"	+/–
Сообщение от PavelR (??) on 21-Апр-11, 13:44
1) Используйте -I IP.ADD.RE.SS <<<--------------- в этом причина. 2) Возможно, также, хост 10.0.16.52 не знает маршрута к сети 192.168.30/24 и не использует ваш хост в качестве шлюза по умолчанию.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "маршрутизация на CentOS"	+/–
	Сообщение от Aleks305 (ok) on 22-Апр-11, 16:02
	> 1) Используйте -I IP.ADD.RE.SS <<<--------------- в этом причина. > 2) Возможно, также, хост 10.0.16.52 не знает маршрута к сети 192.168.30/24 и > не использует ваш хост в качестве шлюза по умолчанию. Спасибо за ответ! возник следующий вопрос по NAT в iptables ввожу такую команду iptables -t nat -A POSTROUTING -s 10.200.0.0/16 -o eth2 -j SNAT --to-source 50.0.0.1, где 10.200.0.0/24 - внутренняя сеть eth2 - внешний интерфейс 50.0.0.1 - внешний адрес eth2 далее смотрю статистику [root@shluzproba network-scripts]# iptables -L -v -n -t nat Chain PREROUTING (policy ACCEPT 50915 packets, 8492K bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 484 packets, 29315 bytes) pkts bytes target prot opt in out source destination 0 0 SNAT all -- * eth2 10.200.0.0/24 0.0.0.0/0 to:50.0.0.1 Chain OUTPUT (policy ACCEPT 373 packets, 22991 bytes) pkts bytes target prot opt in out source destination Я так понимаю, что под правила NAT пакеты из внутренней сети не попадают. Что я делаю не так? Можно ли просмотреть помимо указанной выше команды таблицу трансляций nat?
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "маршрутизация на CentOS"	+/–
	Сообщение от Aleks305 (ok) on 22-Апр-11, 20:31
	up
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	4. "маршрутизация на CentOS"	+/–
	Сообщение от PavelR (??) on 22-Апр-11, 20:43
	> up ап ? тут что, телепаты сидят ? первое сообщение и второй вопрос вообще не кореллируют между собой. Сколько стоит ответ на вопрос "каковы настройки сетевых интерфейсов и таблиц маршрутизации" ? Можно ли воспользоваться "50/50" или "звонком к другу" ?
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "маршрутизация на CentOS"	+/–
	Сообщение от Aleks305 (ok) on 22-Апр-11, 22:58
	>> up > ап ? тут что, телепаты сидят ? > первое сообщение и второй вопрос вообще не кореллируют между собой. > Сколько стоит ответ на вопрос "каковы настройки сетевых интерфейсов и таблиц маршрутизации" > ? Можно ли воспользоваться "50/50" или "звонком к другу" ? извините конечно, может не очень хорошо вопрос задал, мало объяснений дал. Буду исправляться! схема такая: сеть 10.200.0.0/16 - eth0(10.200.16.54/16) - eth2 (50.0.0.1/24) - хост 50.0.0.5 Схема чисто тестовая,для дальнейшего переноса на реальную сеть. Роутинг между интерфейсами включил, без iptables хосты из LAN пингуют и пользуются сервисами хоста 50.0.0.5(http,ftp,telnet). То есть все ок. Но в реальной жизни необходимо натить LAN, ну и другие настройки iptables. Если с цепочками forward, input, output разобрался, то вот с NAT чего-то не получается. Поэтому прошу подсказать, как делать nat внутренней сети. Таблица маршрутизации: [root@shluzproba ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 50.0.0.0 * 255.255.255.0 U 0 0 0 eth2 192.168.200.0 * 255.255.255.0 U 0 0 0 eth1 169.254.0.0 * 255.255.0.0 U 0 0 0 eth2 10.200.0.0 * 255.255.0.0 U 0 0 0 eth0 default cr.ld 0.0.0.0 UG 0 0 0 eth0 Кстати, еще вопрос, не пойму что за сеть 169.254.0.0 на eth2. eth1 в дальнейшем предполагается выделить под DMZ
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	6. "маршрутизация на CentOS"	+/–
	Сообщение от PavelR (??) on 23-Апр-11, 07:21
	> схема такая: сеть 10.200.0.0/16 - eth0(10.200.16.54/16) - eth2 (50.0.0.1/24) - хост 50.0.0.5 -- > Схема чисто тестовая,для дальнейшего переноса на реальную сеть. > Роутинг между интерфейсами включил, без iptables хосты из LAN пингуют и пользуются > сервисами хоста 50.0.0.5(http,ftp,telnet). из этого делаем вывод, что 5.0.0.5 знает маршрут к 10.200.0.0/16 > То есть все ок. Но в реальной жизни необходимо натить LAN, ну > и другие настройки iptables. Если с цепочками forward, input, output разобрался, > то вот с NAT чего-то не получается. Поэтому прошу подсказать, как > делать nat внутренней сети. >Chain POSTROUTING (policy ACCEPT 484 packets, 29315 bytes) > pkts bytes target prot opt in out source destination > 0 0 SNAT all -- * eth2 10.200.0.0/24 0.0.0.0/0 to:50.0.0.1 не, это правило в общем-то верное правило, но по отдельности правила мало чего значат. вдруг у вас там в -t filter FORWARD DROP/REJECT стоит ? приводите вывод iptables-save. а еще есть ip ru sh / ip ro sh (policy routing) - но я полагаю вы им еще не занимались ? :-) > Таблица маршрутизации: > [root@shluzproba ~]# route шлюз по умолчанию у вас как-то в локалку смотрит, хотя это не суть важно в данном случае. > Кстати, еще вопрос, не пойму что за сеть 169.254.0.0 на eth2. самоконфигурация интерфейсов. Возможно, за это дело какой-то специальный даймон отвечает. > eth1 в дальнейшем предполагается выделить под DMZ ------------ в сетях важны не только настройки одного хоста, но и таблицы маршрутов на всех участвующих хостах. Пакеты-то в две стороны ходят. Но вроде как к данному "стенду" отношения не имеет. откройте для себя волшебный мир tcpdump и научитесь пакетики на интерфейсах ловить. на всех интерфейсах, в крайнем случае - гденть да найдется, если ip_forward включен и маршрутизация сложная.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	7. "маршрутизация на CentOS"	+/–
	Сообщение от Aleks305 (ok) on 23-Апр-11, 21:28
	Спасибо за ответ. Сейчас нет возможности привести вывод конфига iptables. Но если пакеты ходят между хостами, то drop там точно нет. смущают нулевые счетчики напротив правила nat и то,что нельзя легко посмотреть таблицу трансляций, как например в cisco-роутерах. С помощью tcpdump возможно как-то увидеть преобразование??? Шлюз по умолчанию действительно известен через локалку, но это нормально, так и задумано.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	8. "маршрутизация на CentOS"	+/–
	Сообщение от LSTemp (ok) on 25-Апр-11, 03:02
	>[оверквотинг удален] >> ? Можно ли воспользоваться "50/50" или "звонком к другу" ? > извините конечно, может не очень хорошо вопрос задал, мало объяснений дал. Буду > исправляться! > схема такая: сеть 10.200.0.0/16 - eth0(10.200.16.54/16) - eth2 (50.0.0.1/24) - хост 50.0.0.5 > Схема чисто тестовая,для дальнейшего переноса на реальную сеть. > Роутинг между интерфейсами включил, без iptables хосты из LAN пингуют и пользуются > сервисами хоста 50.0.0.5(http,ftp,telnet). > То есть все ок. Но в реальной жизни необходимо натить LAN, ну > и другие настройки iptables. Если с цепочками forward, input, output разобрался, > то вот с NAT чего-то не получается. Поэтому прошу подсказать, как примерно так: -A POSTROUTING -o внешний_интерфейс_сервера -j SNAT внешний_IP_сервера_на интерфейсе после этого все пакеты которые приходят из цепочки forward (то есть являются транзитными для данного сервера) будут при покидании интерфейса заменять адрес отправителя на адрес сервака. а при получении - обратная модификация: адрес получателя (коим в приходящем пакете будет сервак) заменится на адрес в локальной сети и пакет протолкнется в нее. 1) LAN->WAN: LAN_IP:LAN_PORT->[SNAT]->SERV_IP:SERV_PORT----->DST связка LAN_IP:LAN_PORT=SERV_IP:SERV_PORT запоминается сетевым фильтром сервака. 2) WAN->LAN DST----->SERV_IP:SERV_PORT сервак вспоминает связку, меняет в пакете получателя на LAN_IP:LAN_PORT и форвардит его в локалку. иногда может немного сбивать с толку, что преобразование явно указывается только в одном направлении движения пакетов. просто обратная операция выполняется автоматически на основе уже существующих данных. >[оверквотинг удален] > 255.255.0.0 > U 0 > 0 > 0 eth0 > default cr.ld > 0.0.0.0 > UG 0 > 0 > 0 eth0 > Кстати, еще вопрос, не пойму что за сеть 169.254.0.0 на eth2. ну не ленитесь: http://otvety.google.ru/otvety/thread?tid=058116aff0d47af8 NOZEROCONF=yes в /etc/sysconfig/network? зависит от дистрибутива. > eth1 в дальнейшем предполагается выделить под DMZ
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	9. "маршрутизация на CentOS"	+/–
	Сообщение от Aleks305 (ok) on 25-Апр-11, 12:29
	Спасибо за ответы! вроде бы все получилось, но странная вещь происходит. В логах сервера 50.0.0.5 я вижу,что подключение к нему идет с 50.0.0.1(внешний ip шлюза моего), хотя соединенение я инициирую с LAN с хоста 10.200.16.60 - то есть все ок. Но почему если я с этого сервера(50.0.0.5) пингую хост 10.200.16.60 ответ мне приходит именно с него, то есть с ip 10.200.16.60, а не с пронатеного ip, то есть с 50.0.0.1. Также я подключаюсь легко к web-серверу на 10.200.16.60 c 50.0.0.5. Может это конечно происходит потому что хосты подключены напрямую к роутеру. Но все равно, не пойму почему происходит nat пакетов обратных, если я инициализирую соединение из Интернет(условно) в LAN. Таблица iptables сейчас предельно проста [root@shluzproba ~]# service iptables status Таблица: filter Chain INPUT (policy ACCEPT) num target prot opt source destination Chain FORWARD (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- 10.200.0.0/16 50.0.0.0/24 Chain OUTPUT (policy ACCEPT) num target prot opt source destination Таблица: nat Chain PREROUTING (policy ACCEPT) num target prot opt source destination Chain POSTROUTING (policy ACCEPT) num target prot opt source destination 1 SNAT all -- 10.200.16.60 0.0.0.0/0 to:50.0.0.1 Chain OUTPUT (policy ACCEPT) num target prot opt source destination
	Ответить \| Правка \| ^ к родителю #8 \| Наверх \| Cообщить модератору


	10. "маршрутизация на CentOS"	+/–
	Сообщение от PavelR (??) on 25-Апр-11, 15:08
	> Но почему если я с этого сервера(50.0.0.5) пингую хост 10.200.16.60 ответ > мне приходит именно с него, то есть с ip 10.200.16.60, а > не с пронатеного ip, то есть с 50.0.0.1. Также я подключаюсь > легко к web-серверу на 10.200.16.60 c 50.0.0.5. -- > Может это конечно происходит потому что хосты подключены напрямую к роутеру. Но > все равно, не пойму почему происходит nat пакетов обратных, если я > инициализирую соединение из Интернет(условно) в LAN. -- =) ну так и должно быть. как-бы "внешний интернет" не должен бы знать вашей внутренней структуры (приватной) сети LAN, и тогда он бы не знал куда стучаться. Но поскольку он знает куда стучаться, то и стучится =) и всё у него получается. Натиться оно и не должно. Линукс в этом плане умный и поступает в принципе-то верно ) Чтобы оно не могло туда достучаться - как раз таки для этого и придуманы файрволлы. Это надо отдельно прописывать в правилах. Без отдельного прописывания - да, провайдер может из физического сегмента вашего подключения пытаться установить связь с вашим внутренним приватным сегментом. всё так и работает, правда не все об этом задумываются =) ;-) -- > Таблица iptables сейчас предельно проста будет посложнее - будет другая картина )
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	11. "маршрутизация на CentOS"	+/–
	Сообщение от Aleks305 (ok) on 25-Апр-11, 16:23
	>> Таблица iptables сейчас предельно проста > будет посложнее - будет другая картина ) в cisco когда настраиваешь nat,если пытаешься пингануть внутренний ip какой-нить, ответ приходит от ip внешнего. Вот по этому я и призадумался... настроил проброс порта с внутренней машины на внешней ip-шлюза. Для этого понадобилось 2 команды: [root@shluzproba ~]# iptables -t nat -A PREROUTING -d 50.0.0.1 -p tcp --dport 80 -j DNAT --to-destination 10.200.16.60:80 iptables -A FORWARD -i eth2 -d 10.200.16.60 -p tcp --dport 80 -o eth0 -j ACCEPT Без второй команды по http://50.0.0.1 соединение не устанавливалось. За то потом доступ к web можно получить и по http://50.0.0.1 и http://10.200.16.60. Но это похоже те же грабли, которые описаны в прошлом сообщении
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	12. "маршрутизация на CentOS"	+/–
	Сообщение от PavelR (??) on 25-Апр-11, 16:44
	>[оверквотинг удален] > приходит от ip внешнего. Вот по этому я и призадумался... > настроил проброс порта с внутренней машины на внешней ip-шлюза. Для этого понадобилось > 2 команды: > [root@shluzproba ~]# iptables -t nat -A PREROUTING -d 50.0.0.1 -p tcp --dport > 80 -j DNAT --to-destination 10.200.16.60:80 > iptables -A FORWARD -i eth2 -d 10.200.16.60 -p tcp --dport 80 > -o eth0 -j ACCEPT > Без второй команды по http://50.0.0.1 соединение не устанавливалось. За то потом доступ > к web можно получить и по http://50.0.0.1 и http://10.200.16.60. > Но это похоже те же грабли, которые описаны в прошлом сообщении по-видимому, циска обрабатывает пакеты попакетно, а линукс - с учетом информации об соединении. решить проблему излишней доступности можно так: 1) проверка -m conntrack ! --ctstate DNAT + DROP всего что не прошло, или наоборот =) 2) -j DROP до ната, либо в -t nat либо в -t mangle (это надо уточнить)
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	13. "маршрутизация на CentOS"	+/–
	Сообщение от Aleks305 (ok) on 26-Апр-11, 16:51
	Продолжаю дальнейшее тестирование. Установили openvpn для подключения удаленных клиентов: Файл конфигурации сервера openvpn local 50.0.0.1 port 1194 proto udp dev tun ca /etc/openvpn/ca.crt cert /etc/openvpn/vpnserver.crt key /etc/openvpn/vpnserver.key dh /etc/openvpn/dh1024.pem server 192.168.100.0 255.255.255.0 ifconfig-pool-persist /etc/openvpn/ipp.txt push "route 10.200.0.0 255.255.0.0" push "redirect-gateway" push "dhcp-option DNS 10.200.4.96" push "dhcp-option DNS 10.200.4.97" client-to-client keepalive 10 120 cipher AES-128-CBC # AES comp-lzo user nobody group nobody persist-key persist-tun log /etc/openvpn/openvpn.log verb 3 Правила iptables filter :INPUT DROP [216986:21628284] :FORWARD ACCEPT [272:17116] :OUTPUT ACCEPT [19505:4280978] :aleks - [0:0] -A INPUT -d 50.0.0.1 -i eth2 -p udp -m udp --dport 1194 -j ACCEPT #разрешаю подключение из нета для подключения к openvpn -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT #разрешаю входящий трафик на шлюз из LAN, который инициирован исходящим из шлюза -A INPUT -i tun0 -p icmp -j ACCEPT #разрешаю входящий icmp на шлюз для vpn-клиентов -A FORWARD -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT # возвращается из Интернет трафик, который инициирован пользователями LAN -A FORWARD -s 10.200.16.60 -d 50.0.0.5 -o eth2 -j ACCEPT # разрешаю пользовательский трафик из LAN(а именно с единственного хоста) -A FORWARD -d 10.200.16.60 -i eth2 -o eth0 -p tcp -m tcp --dport 80 -j ACCEPT #для проброса порта через шлюз в инет -A FORWARD -i tun0 -o eth0 -j ACCEPT # разрешаю трафик VPN-пользователей в LAN -A FORWARD -j DROP COMMIT # Completed on Tue Apr 26 19:33:56 2011 # Generated by iptables-save v1.3.5 on Tue Apr 26 19:33:56 2011 nat :PREROUTING ACCEPT [372396:53664802] :POSTROUTING ACCEPT [3246:203479] :OUTPUT ACCEPT [3066:193693] -A PREROUTING -d 50.0.0.1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 10.200.16.60:80 # dnat для проброса web-сервера наружу -A POSTROUTING -s 10.200.16.60 -o eth2 -j SNAT --to-source 50.0.0.1 # nat LAN COMMIT Сервер запускается - все в порядке. Клиент подключается - вроде бы тоже все в порядке...но не все Возникли следующие вопросы: 1) Почему клиент получает адрес 192.168.100.6/30 с шлюзом 192.168.100.5, причем 192.168.100.5 - не пингуется, а пингуется 192.168.100.1 2) Так и должно быть если tun0 при формировании получает 2 ip? tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:192.168.100.1 P-t-P:192.168.100.2 Mask:255.255.255.255 3) Как установить шлюз по умолчанию для клиента 192.168.0.1 а не 192.168.0.5,которого фактически нет Смотрю таблицу маршрутизации хоста netstat -nr Вижу,что подсеть 10.200.0.0/16 хост получает(см. конфиг сервера) gateway для данной сети 192.168.100.5. Я так понимаю,что вся проблема из-за этого 192.168.100.5 Подскажите , пожалуйста!
	Ответить \| Правка \| ^ к родителю #12 \| Наверх \| Cообщить модератору


	14. "маршрутизация на CentOS"	+/–
	Сообщение от PavelR (??) on 26-Апр-11, 17:15
	> Продолжаю дальнейшее тестирование. > Установили openvpn для подключения удаленных клиентов: > Сервер запускается - все в порядке. Клиент подключается - вроде бы тоже > все в порядке...но не все > Возникли следующие вопросы: > 1) Почему клиент получает адрес 192.168.100.6/30 с шлюзом 192.168.100.5, причем 192.168.100.5 > - не пингуется, а пингуется 192.168.100.1 > 2) Так и должно быть если tun0 при формировании получает 2 ip? Вы не только пишите на форум, но еще и читайте его иногда. Парой дней ранее отвечали уже на идентичный вопрос. Используйте tap (L2 encap) а не tun (L3 IP-IP туннель).
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	15. "маршрутизация на CentOS"	+/–
	Сообщение от Aleks305 (ok) on 26-Апр-11, 17:57
	>[оверквотинг удален] >> Установили openvpn для подключения удаленных клиентов: >> Сервер запускается - все в порядке. Клиент подключается - вроде бы тоже >> все в порядке...но не все >> Возникли следующие вопросы: >> 1) Почему клиент получает адрес 192.168.100.6/30 с шлюзом 192.168.100.5, причем 192.168.100.5 >> - не пингуется, а пингуется 192.168.100.1 >> 2) Так и должно быть если tun0 при формировании получает 2 ip? > Вы не только пишите на форум, но еще и читайте его иногда. > Парой дней ранее отвечали уже на идентичный вопрос. > Используйте tap (L2 encap) а не tun (L3 IP-IP туннель). Не пойму, а почему я не могу использовать tun. В чем причина? Почему не получается с ним?
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	16. "маршрутизация на CentOS"	+/–
	Сообщение от PavelR (??) on 26-Апр-11, 18:58
	>[оверквотинг удален] >>> все в порядке...но не все >>> Возникли следующие вопросы: >>> 1) Почему клиент получает адрес 192.168.100.6/30 с шлюзом 192.168.100.5, причем 192.168.100.5 >>> - не пингуется, а пингуется 192.168.100.1 >>> 2) Так и должно быть если tun0 при формировании получает 2 ip? >> Вы не только пишите на форум, но еще и читайте его иногда. >> Парой дней ранее отвечали уже на идентичный вопрос. >> Используйте tap (L2 encap) а не tun (L3 IP-IP туннель). > Не пойму, а почему я не могу использовать tun. В чем причина? > Почему не получается с ним? Всё получается и работает в строгом соответствии с тем, что вы запросили. Только вы хотите не этого, а как сделать так, чтобы получалось так как вы хотите - ответ: используйте tap. Насколько я понимаю - у вас всё работает.
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	17. "маршрутизация на CentOS"	+/–
	Сообщение от Aleks305 (ok) on 26-Апр-11, 20:21
	> Всё получается и работает в строгом соответствии с тем, что вы запросили. Что-то получается, но не все. Мне хотелось бы давать удаленным пользователям доступ к ресурсам LAN. На данный момент с tun не удается пользователю с хоста 50.0.0.5 получить доступ к 10.200.16.60 > Только вы хотите не этого, а как сделать так, чтобы получалось так > как вы хотите - ответ: используйте tap. А для чего тогда используется tun? Мне казалось, что решение по удаленному доступу с tun тоже работает. Просто, насколько я понял, подсеть VPN(192.168.100.0/24) разбивается на подсети /30, начиная с 192.168.100.4/30. Почему на клиенте gateway устанавливается 192.168.100.5/30, сам хост получает 192.168.100.6/30. > Насколько я понимаю - у вас всё работает. Не работает, так не могу достучаться ни до шлюза 192.168.100.5, ни до хоста 10.200.16.60.
	Ответить \| Правка \| ^ к родителю #16 \| Наверх \| Cообщить модератору


	18. "маршрутизация на CentOS"	+/–
	Сообщение от PavelR (??) on 26-Апр-11, 20:37
	>> Всё получается и работает в строгом соответствии с тем, что вы запросили. > Что-то получается, но не все. Мне хотелось бы давать удаленным пользователям доступ > к ресурсам LAN. На данный момент с tun не удается пользователю > с хоста 50.0.0.5 получить доступ к 10.200.16.60 Я не вижу проблем удаленному пользователю получить доступ с использованием tun, кроме некорректной настройки маршрутизатора. Маршрутизацию и прохождение пакетов по интерфейсам можно легко отладить используя tcpdump. > Мне казалось, что решение по удаленному доступу с tun тоже работает. Просто, > насколько я понял, подсеть VPN(192.168.100.0/24) разбивается на подсети /30, начиная с > 192.168.100.4/30. > Почему на клиенте gateway устанавливается 192.168.100.5/30, сам хост получает 192.168.100.6/30. Почитайте документацию по openvpn + есть такой сайт, http://google.ru - ну просто улетный сайт, рекомендую. >> Насколько я понимаю - у вас всё работает. > Не работает, так не могу достучаться ни до шлюза 192.168.100.5, ни до > хоста 10.200.16.60. Файрволл открыть не пробовали ?
	Ответить \| Правка \| ^ к родителю #17 \| Наверх \| Cообщить модератору


	19. "маршрутизация на CentOS"	+/–
	Сообщение от PavelR (??) on 26-Апр-11, 20:41
	> Почитайте документацию по openvpn. Специально для новичков обычно делают раздел FAQ. Чтобы не сильно утруждать вас поисками, даю прямую ссылку: http://openvpn.net/index.php/open-source/faq/77-server/273-q...
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	20. "маршрутизация на CentOS"	+/–
	Сообщение от Aleks305 (ok) on 26-Апр-11, 20:46
	>>> Всё получается и работает в строгом соответствии с тем, что вы запросили. >> Что-то получается, но не все. Мне хотелось бы давать удаленным пользователям доступ >> к ресурсам LAN. На данный момент с tun не удается пользователю >> с хоста 50.0.0.5 получить доступ к 10.200.16.60 > Я не вижу проблем удаленному пользователю получить доступ с использованием tun, кроме > некорректной настройки маршрутизатора. > Маршрутизацию и прохождение пакетов по интерфейсам можно легко отладить используя tcpdump. Я тоже все больше и больше склоняюсь к тому, чтобы попробовать отладить работу с помощью tcpdump, просто опыта работы с Linux мало. >> Мне казалось, что решение по удаленному доступу с tun тоже работает. Просто, >> насколько я понял, подсеть VPN(192.168.100.0/24) разбивается на подсети /30, начиная с >> 192.168.100.4/30. >> Почему на клиенте gateway устанавливается 192.168.100.5/30, сам хост получает 192.168.100.6/30. > Почитайте документацию по openvpn + есть такой сайт, http://google.ru - ну > просто улетный сайт, рекомендую. А вы думаете я ничего не читаю? я уже кучу мануалов перерыл, openvpn.net тоже уже постоянно в браузере висит. >>> Насколько я понимаю - у вас всё работает. >> Не работает, так не могу достучаться ни до шлюза 192.168.100.5, ни до >> хоста 10.200.16.60. > Файрволл открыть не пробовали ? Полностью не отключал - надо попробовать. Я просто приводил правила в одном из предыдущих сообщений, думал что их достаточно будет.
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	21. "маршрутизация на CentOS"	+/–
	Сообщение от PavelR (??) on 26-Апр-11, 21:20
	> А вы думаете я ничего не читаю? я уже кучу мануалов перерыл, > openvpn.net тоже уже постоянно в браузере висит. В факе все задаваемые вами вопросы относительно "device tun" _разжеваны_. >> Файрволл открыть не пробовали ? > Полностью не отключал - надо попробовать. Я просто приводил правила в одном > из предыдущих сообщений, думал что их достаточно будет. ну вообще говоря вы их от сообщения к сообщению "слегка меняете", это во-первых, а во-вторых, приводите "слегка странно", собирая кусками, а не приводите полный вывод команды. Если не умеете работать с файрволлами - значит сначала все разрешаем, а потом начинаем закрывать, "пока не сломается". У вас там комментами всё откомментарено, а вот коммента "разрешаю трафик к VPN-пользователям из LAN" - нету. Вообще iptables "налеплен", так не делается. тот же lo интерфейс "слегка закрыт"... -A FORWARD -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT рекомендую заменить на правило без учета интерфейса, тогда под него будут подпадать все пакеты, идущие в ответ на некое разрешающее правило: -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT Тогда можно писать: # -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT # разрешаю трафик VPN-пользователей в LAN, ответные пакеты пройдут автоматически # Note: трафик от лан к впн-пользователям не разрешается, только инициированный впн-пользователем!! -A FORWARD -i tun0 -o eth0 -j ACCEPT #разрешаю пользовательский трафик из LAN(а именно с единственного хоста) / ответный пройдет автоматически -A FORWARD -s 10.200.16.60 -d 50.0.0.5 -o eth2 -j ACCEPT #для проброса порта через шлюз в инет / и ответный тоже будет разрешен автоматически, а не будет подпадать под предыдущее правило. Т.е. без предыдущего правила доступ по 80 порту к 16.60 будет, а вот сама 16.60 в инет сходить не сможет -A FORWARD -d 10.200.16.60 -i eth2 -o eth0 -p tcp -m tcp --dport 80 -j ACCEPT # Ну и на сладкое -A FORWARD -j DROP ---------- Я вот понять не могу, с какого перепугу вы беретесь одновременно две задачи решать ? впн-ы и файрволл ? По одной надо, неужели понять это сложно, что вероятность закосячить множится ?
	Ответить \| Правка \| ^ к родителю #20 \| Наверх \| Cообщить модератору


	22. "маршрутизация на CentOS"	+/–
	Сообщение от Aleks305 (ok) on 27-Апр-11, 00:09
	> -A FORWARD -d 10.200.16.60 -i eth2 -o eth0 -p tcp -m tcp --dport 80 -j ACCEPT Здесь не понял, зачем -m tcp нужно?ведь можно и без него обойтись -p tcp --dport 80 > Я вот понять не могу, с какого перепугу вы беретесь одновременно две > задачи решать ? впн-ы и файрволл ? По одной надо, неужели > понять это сложно, что вероятность закосячить множится ? В пух и прах меня)))спасибо, полезно Наверное, характер такой, потому и берусь сразу и файрвол и vpn. Понимаю, что надо как Вы указываете...а вот так получается. Спасибо за ответы вообщем!!!выручаете!Завтра буду продолжать - надо добить!
	Ответить \| Правка \| ^ к родителю #21 \| Наверх \| Cообщить модератору


	23. "маршрутизация на CentOS"	+/–
	Сообщение от PavelR (??) on 27-Апр-11, 00:29
	>> -A FORWARD -d 10.200.16.60 -i eth2 -o eth0 -p tcp -m tcp --dport 80 -j ACCEPT > Здесь не понял, зачем -m tcp нужно?ведь можно и без него обойтись > -p tcp --dport 80 да, действительно. Я не пишу -m, модули сами грузятся. Но это было из ваших же правил скопировано, а у вас - из вывода iptables-save :-) Если глянуть ман, то получается что -m нужен не всегда, в частном случае есть -p, и его значение сдублирует -m.
	Ответить \| Правка \| ^ к родителю #22 \| Наверх \| Cообщить модератору


	24. "маршрутизация на CentOS"	+/–
	Сообщение от LSTemp (ok) on 27-Апр-11, 01:02
	>> -A FORWARD -d 10.200.16.60 -i eth2 -o eth0 -p tcp -m tcp --dport 80 -j ACCEPT > Здесь не понял, зачем -m tcp нужно?ведь можно и без него обойтись > -p tcp --dport 80 можно. хуже в любом случае не будет. >> Я вот понять не могу, с какого перепугу вы беретесь одновременно две >> задачи решать ? впн-ы и файрволл ? По одной надо, неужели >> понять это сложно, что вероятность закосячить множится ? > В пух и прах меня)))спасибо, полезно > Наверное, характер такой, потому и берусь сразу и файрвол и vpn. Понимаю, > что надо как Вы указываете...а вот так получается. > Спасибо за ответы вообщем!!!выручаете!Завтра буду продолжать - надо добить!
	Ответить \| Правка \| ^ к родителю #22 \| Наверх \| Cообщить модератору


	25. "маршрутизация на CentOS"	+/–
	Сообщение от Aleks305 (ok) on 27-Апр-11, 22:27
	Сегодня все получилось - действительно проблема оказалась в файрволе, обратные пакеты из LAN к VPN-клиенту дропались...а так все ок. Начал смотреть дополнительные опции openvpn и появился вопрос по openvpn-auth-pam.so Если мы в серверном конфиге пропишем plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login, то как и где нам добавлять пользователей vpn? или просто нужно через useradd добавить пользователей?
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	26. "маршрутизация на CentOS"	+/–
	Сообщение от Aleks305 (ok) on 28-Апр-11, 10:36
	> Сегодня все получилось - действительно проблема оказалась в файрволе, обратные пакеты из > LAN к VPN-клиенту дропались...а так все ок. Начал смотреть дополнительные опции > openvpn и появился вопрос по openvpn-auth-pam.so > Если мы в серверном конфиге пропишем > plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login, > то как и где нам добавлять пользователей vpn? > или просто нужно через useradd добавить пользователей? up
	Ответить \| Правка \| ^ к родителю #25 \| Наверх \| Cообщить модератору


	27. "маршрутизация на CentOS"	+/–
	Сообщение от reader (ok) on 28-Апр-11, 11:07
	> Сегодня все получилось - действительно проблема оказалась в файрволе, обратные пакеты из > LAN к VPN-клиенту дропались...а так все ок. Начал смотреть дополнительные опции > openvpn и появился вопрос по openvpn-auth-pam.so > Если мы в серверном конфиге пропишем > plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login, > то как и где нам добавлять пользователей vpn? > или просто нужно через useradd добавить пользователей? да
	Ответить \| Правка \| ^ к родителю #25 \| Наверх \| Cообщить модератору


	28. "маршрутизация на CentOS"	+/–
	Сообщение от Aleks305 (ok) on 28-Апр-11, 14:22
	>> Сегодня все получилось - действительно проблема оказалась в файрволе, обратные пакеты из >> LAN к VPN-клиенту дропались...а так все ок. Начал смотреть дополнительные опции >> openvpn и появился вопрос по openvpn-auth-pam.so >> Если мы в серверном конфиге пропишем >> plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login, >> то как и где нам добавлять пользователей vpn? >> или просто нужно через useradd добавить пользователей? > да да уже получилось...
	Ответить \| Правка \| ^ к родителю #27 \| Наверх \| Cообщить модератору