LINUX.ORG.RU

OpenVpn интересные моменты

 


0

2

Хотел бы проконсультироваться у профи(я любитель если что). Возможна ли такая ситуация при работе туннеля OpenVPN. В общем сервер и клиент настроены и работают. Клиент настроен на пуск всего трафика через шлюз openvnp опцией redirect-gateway def1.

Оператор интернета мегафон и он везде пихает свои страницы если что, например 404. Меня смущает ситуация, когда я захожу на сайт(на свой) по http не защищенному протоколу и там ошибка 404 при работающем туннеле, мне мегафон сует свою страницу , хотя на мой взгляд должна открыться страница 404 сайта(в данном случае дефолтная 404 nginx) и мегафон вообще не должен это все видеть.

В общем исходя из вышесказанного появляются ряд вопросов: Я гоню и так должно быть? Или настроено что-то неправильно?

Я не профессионал, но очевидно, что так быть не должно. Для начала банально посмотрите, с какого IP было подключение к серверу. Если с ip клиента, то, вероятно, трафик идет не через vpn.

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

Вот я тоже так думаю. Тем более что по https отрывается страница сайта и мегафон ни хрена не видит. Короче косяк. Попробую запушить эту опцию с сервера, как раньше было. Хотя в документации эта опция значится как клиентская. вот конфиг клиента

windows-driver wintun

client
auth-nocache

#On exit/restart, send exit signal to server/remote. n = # of retries, default=1. udp only
explicit-exit-notify 1

;block-ipv6
redirect-gateway def1 #block-local
dhcp-option DNS 8.8.8.8
dhcp-option DNS 8.8.4.4
block-outside-dns

dev tun1
proto udp
remote myip 1196

nobind
persist-key
persist-tun

auth SHA512
cipher AES-256-GCM
data-ciphers CHACHA20-POLY1305:AES-256-GCM:AES-128-GCM
;CHACHA20-POLY1305:AES-256-GCM:AES-128-GCM
 
reneg-sec 3600
hand-window 15
tran-window 600

remote-cert-tls server
tls-client
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
;TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256

keepalive 10 43
ping-timer-rem

verb 6
mute 20
float

далее сертификаты

конфиг сервера

port 1196
proto udp
auth-nocache
topology subnet
# non windows, only udp, better for cpu
fast-io
 
# tun L3, tap L2. Используйте tap если нужен мост и объедините полученный tap в режиме моста с вашим ethernet интерфейсом.
dev tun1

ca /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/server.crt
key /etc/openvpn/certs/server.key
dh /etc/openvpn/certs/dh.pem
crl-verify /etc/openvpn/certs/crl.pem
 
# Виртуальная сеть, которая будет установлена между клиентом и сервером. Закоментируйте эту строку, если вы используете ethernet мост. 
server 10.10.1.0 255.255.255.0

 
ifconfig-pool-persist /etc/openvpn/ccd/ipp.txt
client-config-dir /etc/openvpn/ccd 
tmp-dir /etc/openvpn/ccd 

client-to-client
max-clients 10

keepalive 10 43

ping-timer-rem
# Allow remote to change its IP address/port, such as through DHCP (this is the default if --remote is not used)
float
#In UDP server mode send [RESTART] command on exit/restart to connected clients. n = 1 - reconnect to same server, 2 - advance to next server, default=1.
explicit-exit-notify 2

#Renegotiate data channel key after at most max seconds (default 3600) and at least min seconds (default is 90% of max for servers, and equal to max for clients). reneg-sec max [min]
reneg-sec 0
#Handshake Window the TLS-based key exchange must finalize within n seconds of handshake initiation by any peer (default 60 seconds).
hand-window 15
#Transition window our old key can live this many seconds after a new a key renegotiation begins (default 3600 seconds). 
tran-window 600

# Включаем TLS
remote-cert-tls client
tls-crypt /etc/openvpn/certs/tls.key 
tls-server
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

# шифрование
auth SHA512
cipher AES-256-GCM
data-ciphers CHACHA20-POLY1305:AES-256-GCM:AES-128-GCM

# сжатие asym no yes
;allow-compression asym 
 
# Назначаем пользователя и группу для работы с OpenVPN
user nobody
group nogroup
daemon
 
# Не перечитывать ключи после получения SIGUSR1 или ping-restart. Не переоткрывать TUN\TAP устройство, после получения SIGUSR1 или ping-restart
persist-key 
persist-tun
 
# Write operational status to file every n seconds.  Choose the status file format version number. Currently, n can be 1, 2, or 3 (default=1).
status /var/log/openvpn/server_status.log 60
status-version 3

# "log" будет обрезать файл журнала при запуске OpenVPN. log-append" будет добавляться. Использовать один или другой (но не оба).
log /var/log/openvpn/server.log
 
# уровень логирования. 0 ничего, 4 для получения общих сведений, 5 и 6 для отладки проблем соединения, 9 максимум.
verb 6
# Запрещает повтор сообщений.  Не более 20 идущих друг за другом сообщений одного типа будут направлены в лог. 
mute 20

mio_linux ()

Я не специалист по сетям, но слышал про vpn kill switch, это настройка которая блокирует соединение компа с инетом вообще, если соединение с vpn нестабильно или оборвано. Также слышал что некоторые провайдеры vpn допускают ip leak, dns leak, возможно можно погуглить онлайн-проверки своего vpn на эти утечки.

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

нужно не подходить ко всему, что оно тебе «должно», а взять и проверить самому.

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

Я доступно объяснил? )

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

Если «да» означает, что расположен там же, то трафик от тебя до твоего сайта не будет ходить через впн. Openvpn добавляет в таблицу маршрутизации два маршрута: default через туннель, и маршрут до адреса впн-сервера через обычный интернет.

Думаю, тут можно либо купить отдельный адрес для впн-сервера и подключаться на него, либо поднять dns сервер на впс, который будет отдавать для твоего сайта «внутритуннельные» адреса, а все остальные запросы форвардить гуглу.

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

dhcp-option DNS 8.8.8.8 dhcp-option DNS 8.8.4.4 block-outside-dns должно быть все норм

Нет. Запрос уходит гуглу, а провайдер перехватывает запрос и отвечает сам. Далее приходит ответ от гугла, но на него уже никто не смотрит.

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

По уму стоит настроить у себя так, чтобы только опенвпн мог ходить через провайдера и только на определённый адрес и на определённый порт (на котором впн сервер слушает). Точных команд не скажу, но суть такая:

  • создать отдельного пользователя для опенвпн.
  • маркировать трафик опенвпн пользователя и заворачивать его в отдельную таблицу маршрутизации, где default - шлюз провайдера.
  • в своей таблице в качестве default должен быть впн туннель.
  • дополнительно в фаерволе запретить для опенвпн пользователя любой трафик, кроме как на ип и порт впн сервера.

Если нет сильно умных NetworkManager’ов, то такая схема ещё и защитит от потенциальных утечек трафика в обход впн, в том числе и при обрыве впн соединения.

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