Jak skonfigurować DNS podczas udostępniania połączenia VPN w systemie Linux?


2

Używam komputera z systemem Linux (raspberry pi), aby udostępnić połączenie VPN przez sieć Ethernet. Chcę, aby Raspberry Pi łączyło się z Internetem normalnie (nie przez VPN). Jestem bardzo blisko uruchomienia go, ale nie wiem, jak skonfigurować DNS dla sieci 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

konfiguracja eth1:

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

Mam dnsmasq działający jako serwer dhcp dla eth1 (sieć udostępniania VPN)

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

vpn config

Chcę, aby ruch pochodzący z eth1 korzystał z VPN. Sam konfiguruję trasy za pomocą oddzielnej tabeli routingu.

# 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

Musiałem również uruchomić kilka poleceń, aby skonfigurować oddzielną tabelę routingu:

# 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

Łączenie interfejsów:

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

Testowanie:

Umieściłem laptopa z systemem Windows w sieci udostępniania VPN. Jest w stanie komunikować się bezpośrednio z adresami internetowymi. Ale przy użyciu nazw domen wyszukiwanie DNS kończy się niepowodzeniem. Nie znalazłem działającego sposobu konfiguracji DNS.

Próbowałem dodać to do dnsmasq

server=<dns-server-address> 

Próbowałem też dodać tę linię pod eth1 w / etc / network / interfaces

dns-nameservers <dns-server-address> 

Spowodowało to, że resolvconf -l zwrócił to:

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

ale /etc/resolv.conf powtarza to samo:

# Generated by resolvconf
nameserver 127.0.0.1

Próbowałem nawet edytować plik /etc/resolv.conf bezpośrednio. - Ale jest automatycznie aktualizowany i prawie natychmiast ponownie zapisywany.

--edytować --

Moim celem jest posiadanie konfiguracji, która nie wymaga żadnej konkretnej konfiguracji na kliencie w sieci udostępniania VPN. (Będę dołączał urządzenia, których nie można skonfigurować)

Chciałbym również wysłać żądania DNS przez VPN, jeśli to możliwe.

--edit 2--

Pierwszy. Przełączyłem się na testowanie z klientem linuxowym. Modyfikacja resolv.conf, aby dodać mój serwer dns, działa z połączeniem internetowym VPN.

Jednak - wygląda na to, że rozwiązanie 5 jest dla mnie. Czy przechwytuje pakiety DNS i zmienia je, aby skierować je do nowego serwera DNS?

Nie mogłem tego zrobić dla mnie. Tutaj opublikuję moją konfigurację. Czy czegoś mi brakuje?

# 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

- edytuj 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)

Patrząc na to, wracamy do odpowiedzi DNS, ale nie docierają do klienta (192.168.5.128). Dobrze? Teraz muszę się dowiedzieć, jak to naprawić ...


Pls przeczytał mój nowy punkt, pisałem go, gdy przeczytałeś moją (niepełną) odpowiedź.
MariusMatutiae

Byłoby pomocne, gdybyś mógł nasłuchiwać na interfejsie tun0 i zobaczyć, czy pakiety do / z portu 53 przechodzą przez niego, gdy klient próbuje rozwiązać nazwę. Spróbuj, w RPI, tcpdump -i tun0 -n port 53 , a następnie z klienta wykonaj polecenie ping do nieznanego adresu URL. Powinieneś zobaczyć przez tcpdump, aby pakiety przychodziły i wychodziły. Proszę zgłosić.
MariusMatutiae

Odpowiedzi:


1

Nie wyjaśniłeś, czy chcesz, aby serwery DNS były specyficzne dla twojego komputera z systemem Windows, dla wszystkich klientów OpenVPN, a może nawet dla ciebie, i czy chcesz, aby zapytanie DNS przechodziło przez VPN, czy nie.

1. Oddzielny klient (przez OpenVPN) i DNSy RPI.

To najłatwiejszy przypadek: ustaw DNSes klienta w kliencie , a DNSes RPI w /etc/resolv.conf .

2. Oddzielny klient (poza OpenVPN) i DNSe RPI.

Tak samo jak powyżej, ale będziesz musiał dodać następującą regułę routingu do RPI:

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

gdzie założyłem, że twój klient (Windows) używa DNS Google, 8.8.8.8.

3. Alternatywnie , możesz oznaczyć pakiety DNS od klientów i przekierować je przez Główny Tabela routingu:

     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. Te same serwery DNS dla RPI i klientów, zarówno przez OpenVPN, jak i na zewnątrz.

Tak samo jak punktor 1 lub 2, użyj tego samego zestawu DNSes.

5. Automatyczne ustawienie dla wszystkich klientów OpenVPN, oczywiście przez OpenVPN.

Możesz pomyśleć, że ustawianie DNSes indywidualnie w każdym kliencie VPN jest żmudne, zwłaszcza jeśli potrzebujesz ustawić DNSes w sieci serwera, a nie coś tak prostego jak Google. Najpierw musisz wypchnąć opcję DNS z serwera do klienta RPI, dodając następujący plik do pliku konfiguracyjnego serwera:

    push "dhcp-option DNS 10.66.0.4"

Ta opcja jest zapisywana do zmiennej o nazwie foreign_option_ {n} : pierwsza opcja wypchnięta w ten sposób będzie n = 1 , a jego wartość (w powyższym przypadku) to:

    foreign_option_1="dhcp-options DNS 10.66.0.4"

Ta zmienna jest automatycznie przekazywana do w górę skrypt, w którym musisz podzielić go na trzy części, wyodrębniając adres IP, powiedzmy $ var3 i możesz teraz dodać następujące linie do swojego trasa scenariusz:

    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

Aby to działało, ty może muszę wyłączyć filtr odwrotnej ścieżki: nie jestem pewien, ponieważ na moim laptopie Arch Linux robię nie muszę to zrobić, będąc na mojej stacji roboczej Debiana I robić . Tak więc jestem teraz trochę oszołomiony, przepraszam za to.


Dzięki. Dokonałem edycji dodając więcej szczegółów: DNS dla wszystkich klientów (nie pi). DNS przez VPN. Czy mam rację w myśleniu: w normalnym przypadku brama jest odpowiedzialna za serwery dns?
pauld

rozwiązanie numer 5: Ale mam problemy. mógłbyś spojrzeć na edycję 2 w pytaniu?
pauld
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.