2

Я использую компьютер Linux (Raspberry Pi) для разделения VPN-подключения через Ethernet. Я хочу, чтобы Raspberry Pi нормально подключался к Интернету (не через VPN). Я очень близок к тому, чтобы заставить его работать, но я не знаю, как настроить DNS для сети eth1.

Connection to the internet: eth0 192.168.11.21/24, gateway 192.168.11.1
vpn connection: tun0 <- openvpn connection
vpn sharing network: eth1 192.168.5.1/24 <- this maching is the gatway for the vpn sharing network

eth1 config:

eth1: /etc/network/interface
auto eth1
iface eth1 inet static
address 192.168.5.1
netmask 255.255.255.0

У меня dnsmasq работает как dhcp сервер для eth1 (виртуальная сеть vpn) 

# Configuration file for dnsmasq.
#
interface=eth1
dhcp-range=192.168.5.50,192.168.5.150,12h

vpn config

Я только хочу, чтобы трафик из eth1 использовал vpn. Я сам настраиваю маршруты, используя отдельную таблицу маршрутизации. 

# extract from openvpn config
route-noexec
route-up "/etc/openvpn/route-up.sh"
down "/etc/openvpn/down.sh"

# route-up.sh
/sbin/ip route add $trusted_ip/32 via $route_net_gateway table vpn
/sbin/ip route add 0.0.0.0/1 via $route_vpn_gateway table vpn
/sbin/ip route add 128.0.0.0/1 via $route_vpn_gateway table vpn

Мне также нужно было выполнить несколько команд для настройки отдельной таблицы маршрутизации:

# make a new routing table called vpn
echo 200 vpn >> /etc/iproute2/rt_tables 

# add a rule to use the routing table for the addresses on eth1
ip rule add from 192.168.5.0/24 table vpn

Связывание интерфейсов:

sysctl net.ipv4.ip_forward=1      
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Тестирование:

Я поставил ноутбук с Windows в сеть совместного использования VPN. Он может общаться по интернет-адресам напрямую. Но с использованием доменных имен поиск DNS не удается. Я не нашел рабочий способ настроить DNS.

Я пытался добавить это в dnsmasq

server=<dns-server-address>

Я также попытался добавить эту строку под eth1 в /etc /network /interfaces

dns-nameservers <dns-server-address>

Это заставило resolvconf -l вернуть это:

# resolv.conf from eth1.inet
# Generated by ifup for eth1.inet
nameserver <dns-server-address1>
nameserver <dns-server-address2>

но /etc/resolv.conf сохраняет то же самое:

# Generated by resolvconf
nameserver 127.0.0.1

Я даже пытался редактировать /etc/resolv.conf напрямую. - Но он автоматически обновляется и почти сразу перезаписывается.

--редактировать --

Моя цель состоит в том, чтобы иметь установку, которая не требует какой-либо конкретной конфигурации на клиенте в сети совместного использования vpn. (Я буду подключать устройства, которые не могут быть настроены)

Я также хотел бы отправлять DNS-запросы через VPN, если это возможно.

--edit 2--

Первый. Я перешел на тестирование с клиентом Linux. Модификация resolv.conf для добавления моего DNS-сервера заставляет работать интернет-соединение vpn'd.

Тем не менее - похоже, решение 5 для меня. Это перехватывает пакеты DNS и изменяет их, чтобы направить их на новый сервер DNS?

Я не мог заставить это работать на меня. Я выложу свою конфигурацию здесь. Я что-то пропустил?

# iptables-save
# Generated by iptables-save v1.4.21 on Fri Sep 23 16:57:46 2016
*mangle
:PREROUTING ACCEPT [51:3878]
:INPUT ACCEPT [49:3758]
:FORWARD ACCEPT [2:120]
:OUTPUT ACCEPT [30:3438]
:POSTROUTING ACCEPT [32:3558]
-A PREROUTING -p tcp -m tcp --dport 53 -j MARK --set-xmark 0x1/0xffffffff
-A PREROUTING -p udp -m udp --dport 53 -j MARK --set-xmark 0x1/0xffffffff
COMMIT
# Completed on Fri Sep 23 16:57:46 2016
# Generated by iptables-save v1.4.21 on Fri Sep 23 16:57:46 2016
*nat
:PREROUTING ACCEPT [4:337]
:INPUT ACCEPT [3:277]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -i tun0 -p tcp -m tcp --dport 53 -j DNAT --to-destination 198.18.0.1
-A PREROUTING -i tun0 -p tcp -m tcp --dport 53 -j DNAT --to-destination 198.18.0.2
-A POSTROUTING -o tun0 -j MASQUERADE
COMMIT
# Completed on Fri Sep 23 16:57:46 2016
# Generated by iptables-save v1.4.21 on Fri Sep 23 16:57:46 2016
*filter
:INPUT ACCEPT [41189:45918808]
:FORWARD ACCEPT [63803:44422296]
:OUTPUT ACCEPT [33919:5341216]
COMMIT
# Completed on Fri Sep 23 16:57:46 2016

# ip route list table vpn
0.0.0.0/1 via 172.21.24.1 dev tun0 
81.171.74.16 via 192.168.11.1 dev eth0 
128.0.0.0/1 via 172.21.24.1 dev tun0 


# ip route list table main
default via 192.168.11.1 dev eth0 
default via 192.168.11.1 dev eth0  metric 202 
172.21.24.0/23 dev tun0  proto kernel  scope link  src 172.21.24.57 
192.168.5.0/24 dev eth1  proto kernel  scope link  src 192.168.5.1 
192.168.11.0/24 dev eth0  proto kernel  scope link  src 192.168.11.21 
192.168.11.0/24 dev eth0  proto kernel  scope link  src 192.168.11.21  metric 202 

# ip rule
0:  from all lookup local 
32764:  from all fwmark 0x1 lookup vpn 
32765:  from 192.168.5.0/24 lookup vpn 
32766:  from all lookup main 
32767:  from all lookup default 

# cat /etc/resolv.conf 
# Generated by resolvconf
nameserver 127.0.0.1

# On the client
# cat /etc/resolv.conf 
# Generated by resolvconf
nameserver 192.168.5.1

- редактировать 3 -

# tcpdump -i tun0 -n port 53
23:44:29.787915 IP 192.168.5.1.53 > 192.168.5.128.38840: 36460 4/0/0 A 157.7.203.102, A 157.7.154.23, A 116.58.172.182, A 157.7.235.92 (101)
23:44:29.788071 IP 192.168.5.1.53 > 192.168.5.128.38840: 37999 0/0/0 (37)
23:44:30.619149 IP 192.168.5.1.53 > 192.168.5.128.58425: 3383 1/0/0 A 129.169.10.40 (47)
23:44:30.620635 IP 192.168.5.1.53 > 192.168.5.128.58425: 11649 0/1/0 (83)

Глядя на это, мы получаем ответы DNS, которые возвращаются к клиенту (192.168.5.128). Правильно? Теперь мне нужно выяснить, как это исправить ...

|источник

1 ответ1

1

Вы не уточнили, хотите ли вы, чтобы DNS-серверы были специфичны для вашей машины Windows, для всех клиентов OpenVPN или, возможно, даже для вашего RPI, и хотите ли вы, чтобы DNS-запросы проходили через VPN или нет.

1. Отдельный клиент (через OpenVPN) и RPI DNS.

Это самый простой случай: установить клиентские DNS в клиенте, а RPI DNS в /etc/resolv.conf.

2. Отдельный клиент (вне OpenVPN) и RPI DNS.

То же, что и выше, за исключением того, что вам нужно добавить следующее правило маршрутизации в RPI:

    ip route add 8.8.8.8/32 via Your.Router.IP.Address dev Your.Non.VPN.Interface table vpn

где я предположил, что ваш (Windows) клиент использует DNS от Google, 8.8.8.8.

3. Кроме того, вы можете пометить DNS-пакеты от клиентов и направить их через основную таблицу маршрутизации:

     iptables -A PREROUTING -t mangle -p tcp --dport 53 -j MARK --set-mark 1
     iptables -A PREROUTING -t mangle -p udp --dport 53 -j MARK --set-mark 1
     ip rule add from all fwmark 1 table main
     iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE

4. Те же DNS-серверы для RPI и клиентов, будь то через OpenVPN или снаружи.

То же, что в пуле 1 или 2, просто используйте тот же набор DNS.

5. Автоматическая настройка для всех клиентов OpenVPN, очевидно, через OpenVPN.

Вы можете подумать, что индивидуально настраивать DNS для каждого VPN-клиента утомительно, особенно если вам нужно настроить DNS в сети сервера, а не что-то более простое, чем в Google. Сначала вам нужно будет перенести опцию DNS с сервера на клиент RPI, добавив следующую запись в файл конфигурации сервера:

    push "dhcp-option DNS 10.66.0.4"

Эта опция записывается в переменную foreign_option_ {n}: первая опция, выдвинутая таким образом, будет иметь n = 1, а ее значение (в случае выше):

    foreign_option_1="dhcp-options DNS 10.66.0.4"

Эта переменная автоматически передается в сценарий up, где вам придется разбить его на три части, извлекая IP-адрес, скажем, в $ var3, и теперь вы можете добавить следующие строки в сценарий маршрутизации :

    iptables -t mangle -A PREROUTING -p tcp --dport 53 -j MARK --set-mark 1
    iptables -t mangle -A PREROUTING -p udp --dport 53 -j MARK --set-mark 1
    ip rule add  fwmark 1 table vpn
    iptables -t nat -A PREROUTING -p tcp --dport 53 -i tun0 -j DNAT --to-destination $var3
    iptables -t nat -A PREROUTING -p udp --dport 53 -i tun0 -j DNAT --to-destination $var3

Чтобы это работало, вам, возможно, придется отключить фильтр обратного пути: я не уверен, потому что на моем ноутбуке с Arch Linux мне это не нужно, а на рабочей станции Debian - нет. Итак, я немного озадачен, прямо сейчас, извините за это.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .