Ich habe eine funktionierende VPN-Verbindung über OpenVPN, möchte aber auch meinen DHCP-Server und nicht die Push-Funktion von OpenVPN verwenden. Momentan funktioniert alles einwandfrei, aber ich muss beispielsweise den DHCP-Client manuell starten. dhclient tap0Ich erhalte IP und andere wichtige Dinge von meinem DHCP. Gibt es eine Anweisung, die den DHCP-Client startet, wenn die Verbindung hergestellt ist?
Hier ist die Konfiguration meines Clients:
remote there.is.server.com
float
dev tap
tls-client
#pull
port 1194
proto tcp-client
persist-tun
dev tap0
#ifconfig 192.168.69.201 255.255.255.0
#route-up "dhclient tap0"
#dhcp-renew
ifconfig 0.0.0.0 255.255.255.0
ifconfig-noexec
ifconfig-nowarn
ca /etc/openvpn/ca.crt
cert /etc/openvpn/encyNtb_openvpn_client.crt
key /etc/openvpn/encyNtb_openvpn_client.key
dh /etc/openvpn/dh-openvpn.dh
ping 10
ping-restart 120
comp-lzo
verb 5
log-append /var/log/openvpn.log
Hier kommt die Serverkonfiguration:
mode server
tls-server
dev tap0
local servers.ip.here
port 1194
proto tcp-server
server-bridge
# Allow comunication between clients
client-to-client
# Allowing duplicate users per one certificate
duplicate-cn
# CA Certificate, VPN Server Certificate, key, DH and Revocation list
ca /etc/ssl/CA/certs/ca.crt
cert /etc/ssl/CA/certs/openvpn_server.crt
key /etc/ssl/CA/private/openvpn_server.key
dh /etc/ssl/CA/dh/dh-openvpn.dh
crl-verify /etc/ssl/CA/crl.pem
# When no response is recieved within 120seconds, client is disconected
keepalive 10 60
persist-tun
persist-key
user openvpn
group openvpn
# Log and Connected clients file
log-append /var/log/openvpn
verb 3
status /var/run/openvpn/vpn.status 10
# Compression
comp-lzo
#Push data to client
push "route-gateway 192.168.69.1"
push "redirect-gateway def1"
Antwort1
Ja, es ist möglich.
wenn du passierst "--up cmd" zum OpenVPN-Prozess.
Der UP-Schalter ist definiert als „ Shell-Befehl, der nach dem erfolgreichen Öffnen des TUN/TAP-Geräts (vor der Änderung der --user-UID) ausgeführt werden soll. Das Up-Skript ist nützlich, um Routenbefehle anzugeben, die IP-Verkehr, der für private Subnetze bestimmt ist, die am anderen Ende der VPN-Verbindung vorhanden sind, in den Tunnel leiten.“
Antwort2
Sie können Standard-Netzwerkverwaltungsskripte aus Ihrer Distribution verwenden. Ich habe dieses Problem in CentOS 6.6 gelöst und der Trick bestand darin, einen anderen Schnittstellennamen als tap0 zu verwenden. Das Problem bestand darin, dass Skripte davon ausgehen, dass tap*-Schnittstellen während des Bootvorgangs aufgerufen werden, und dies verhindert, dass Hotplug-Skripte die OpenVPN-Schnittstelle konfigurieren. Also,
Schreiben Sie in /etc/openvpn/client.conf:
dev priv0
dev-Typ tippen
anstatt:
Entwickler tap0
Erstellen Sie als nächstes die Konfigurationsdatei /etc/sysconfig/network-scripts/ifcfg-priv0
DEVICE=priv0
BOOTPROTO=dhcp
ONBOOT=nein
PERSISTENT_DHCLIENT=1
HOTPLUG=ja
Und fertig! Das Skript /etc/sysconfig/network-scripts/net.hotplug ruft „ifup priv0“ auf, nachdem der OpenVPN-Dienst die Schnittstelle priv0 erstellt hat. Das Problem ist jedoch, dass DHCP-Leases nicht freigegeben werden, wenn der OpenVPN-Dienst heruntergefahren wird. Das liegt daran, dass die Schnittstelle bereits entfernt ist, wenn das Skript net.hotplug informiert wird, sodass der DHCP-Client keine Daten durch den Tunnel leiten kann. Dies könnte behoben werden, indem der OpenVPN-Konfiguration ein Pre-Down-Skript wie „ifdown priv0“ hinzugefügt wird. Ich hatte Selinux laufen und habe mir nicht die Mühe gemacht, neue Regeln auszuarbeiten, um dem OpenVPN-Prozess den Aufruf des Ifdown-Skripts zu ermöglichen.