Использование vpn-туннеля в одной подсети

на ПК1 шлюзом по умолчанию должен быть указан ПК2 (vpn-интерфейс), на ПК2, соответственно, должен быть настроет NAT.

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

надо заменить маршрут к подсети на маршрут к хосту, а затем написать маршрут к подсети через туннель. Хотя логичнее ( и проще ) сделать туннель в отдельной подсети.

Поднимаете средствами openvpn на обоих машинах интерфейсы с отдельной подсетью и обращаетесь друг к другу через него (решается через /etc/hosts||dns||dnsmasq). Имхо, в пределах одного широковещательного домена это должно работать без доп. настроек, если коммутаторы специально не режут такое поведение.

А все-таки до чего нас довел IPv4... На уме одни NATы с туннелями. IPSec может работать и в транспортном режиме, т.е. никаких изменений в маршрутизации не требуется.

Если тебе нужно в исключительно разрезе HTTP, то есть офигенная штука под названием reverse-proxy. Настраивается тривиально. Реализация любая: nginx, apache, lighthttpd. Только не забудь поднять TLS с аутентификацией по клиентским сертификатам.

Допустим у ПК1 ip eth0 = 192.168.1.1, а tun1 = 192.168.2.1, ПК2 ip eth0 = 192.168.1.2, а tun2 = 192.168.2.2. Шлюз в сети 192.168.1.10 Может ошибаюсь где, только осваиваю роутинг.

route на ПК1 (192.168.1.1):

Destination Gateway Genmask Flags Metric Ref Use Iface

192.168.2.1 * 255.255.255.255 UH 0 0 0 tun1

192.168.1.0 * 255.255.255.0 U 1 0 0 eth0

link-local * 255.255.0.0 U 1000 0 0 eth0

default 192.168.2.2 0.0.0.0 UG 0 0 0 lo

не знаю, почему в последний эксперимент при добавлении дефолтного шлюза (добавляла sudo route add default gw x.x.x.x) запись про новый шлюз опрелилилась для интерфейса lo ????? И так и не поняла, что означает мифическая * в поле Gateway

route на ПК2 (192.168.1.2):

Destination Gateway Genmask Flags Metric Ref Use Iface

192.168.2.2 * 255.255.255.255 UH 0 0 0 tun2

192.168.1.0 * 255.255.255.0 U 1 0 0 eth0

link-local * 255.255.0.0 U 1000 0 0 eth0

default 192.168.1.10 0.0.0.0 UG 0 0 0 eth0

Все равно при запросе на сервер ПК1 обращается к серверу напрямую, tracepath это тоже подтверждает.

Команду route нужно забыть. Есть команда ip. «ip route show», «ip route add»

Звёздочка означает, что машрут не через gateway, а напрямую, на интерфейсе.

Понятно, что с такими маршрутами при запросе на сервер 192.168.1.10 трафик пойдёт напрямую. Либо добавить маршрут для этого ip-адреса через ПК2:

ip route add 192.168.1.10 via 192.168.2.1 dev tun0

либо вобще убрать маршрут на всю локальную сеть, оставив только маршрут до 192.168.1.2 (чтобы тунель работал).

ip route add 192.168.1.2 dev eth0

ip route del 192.168.1.0/24 dev eth0

Спасибо, попробую. Я вот думаю, что может у меня конфликтуют конфиги с network manager.

http://anonymus88.livejournal.com/21061.html

короч ипсек в транспортном режиме - это то, что тебе нужно

> Хочу, чтоб мои соседи по сети не видели трафика с моей машины ПК1 на другую ПК2

А с чего вдруг они его вообще должны видеть? Свич aka коммутатор не рассылает Ethernet-пакеты всем подряд, а только адресатам. Кто контролирует свич? Непонятно, почему все в этом треде полезли в IP, когда все на L2 разруливается

Разобралась с роутингом, заработало!
Вот только вижу wireshark'ом трафик в открытом виде. Т.е. чего-то оно не шифрует.
Вот частично конфиги (те строчки, которые к шифрованию относятся), какие параметры я не дописала?

/server.conf:

port 1194
proto tcp
tls-server
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
tls-auth /etc/openvpn/keys/ta.key 0
cipher DES-EDE3-CBC ...

***
/client.conf:
dev tun
tls-client
remote xxx.xxx.xxx.xxx
proto tcp
port 1194
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client.crt
key /etc/openvpn/keys/client.key
tls-auth /etc/openvpn/keys/ta.key 1
cipher DES-EDE3-CBC ...

Туннель поднимается и никаких вроде «плохих» записей в логах. Странно???

Вы уверены, что пакеты не шифруются? Если запускаете wireshark на машине с openvpn-тунелем, нужно смотреть пакеты на интерфейсе eth0 (udp port 1194), а не на tun0 интерфейсе.

С интерфейса eth0 на машине с openvpn-тунелем я вообще не вижу этого трафика, может так и должно быть??? Хотя физически tun0 работает через eth0. Может wireshark четко разделяет интерфейсы не самостоятельно (не по железу), а берет, то что система ему дала?

Трафик должен быть виден, правда не udp, а tcp port 1194. Wireshark-ом не пользовался, но

tcpdump -i eth0 -n -nn tcp and port 1194

должен показывать пакеты при прохождении траффика по тунелю.

Спасибо огромное, у меня все получилось :) Правда, трафик из туннеля в шифрованном виде все равно вижу после туннеля, с eth0 не видно. А если хочу увидеть трафик внутри туннеля, надо слушать tun, но там он естественно еще открытый.