3
OpenVPN ccd wird nicht gelesen
Hallo,
würde den OpenVPN Server wie folgt laufen lassen
Clients dürfen sich gegenseitig sehen, jedoch sollen nicht auf das interne Netz dahinter zugreifen. Des weiteren dürfen die Clients den Server sehen, aber nicht auf das Netz dahinter zugreifen. Die IP-Adressen müssen statisch sein.
Bekomme aber wie in der status.txt zu sehen, nicht meine vorgegebenen Adressen.
10.10.x.1 als IP-Adresse der Clients muss nicht sein. Schöner wäre es
10.10.0.1 # Server
10.10.0.2 # Client_01
würde den OpenVPN Server wie folgt laufen lassen
Clients dürfen sich gegenseitig sehen, jedoch sollen nicht auf das interne Netz dahinter zugreifen. Des weiteren dürfen die Clients den Server sehen, aber nicht auf das Netz dahinter zugreifen. Die IP-Adressen müssen statisch sein.
- gemini.conf in /etc/openvpn
port 1194
proto udp
dev tun0
ca gemini/ca.crt
cert gemini/server.crt
key gemini/server.key
dh gemini/dh2048.pem
server 10.10.0.0 255.255.255.0 # clients
ifconfig-pool-persist gemini/ipp.txt
#push "redirect-gateway def1 bypass-dhcp"
#push "dhcp-option DNS 8.8.8.8"
#push "dhcp-option DNS 8.8.4.4"
client-config-dir gemini/ccd
client-to-client
keepalive 10 120
comp-lzo
user openvpn
group openvpn
persist-key
persist-tun
status /status.txt
log gemini/log.txt
verb 3- status.txt in /etc/openvpn/gemini
OpenVPN CLIENT LIST
Updated,Wed May 20 08:59:45 2020
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
client_03,85.8.95.202:34337,202811,192526,Tue May 19 22:01:04 2020
client_02,87.189.72.85:48541,112207,114784,Wed May 20 04:10:17 2020
client_01,87.138.229.139:31828,63081,4399,Wed May 20 08:58:06 2020
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.10.0.6,client_01,87.138.229.139:31828,Wed May 20 08:58:06 2020
10.10.0.10,client_02,87.189.72.85:48541,Wed May 20 04:10:18 2020
10.10.0.14,client_03,85.8.95.202:34337,Tue May 19 22:01:06 2020
GLOBAL STATS
Max bcast/mcast queue length,3
END- client_01 in /etc/openvpn/gemini/ccd
ifconfig-push 10.10.1.1 10.10.1.2Bekomme aber wie in der status.txt zu sehen, nicht meine vorgegebenen Adressen.
10.10.x.1 als IP-Adresse der Clients muss nicht sein. Schöner wäre es
10.10.0.1 # Server
10.10.0.2 # Client_01
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 573163
Url: https://administrator.de/contentid/573163
Ausgedruckt am: 13.11.2024 um 11:11 Uhr
3 Kommentare
Neuester Kommentar
Die Client-IPs müssen sich innerhalb des in der Server-Config angegebenen IP-Range befinden, sonst werden sie neu vergeben.
Entweder änderst du also die Client-IPs oder den konfigurierten IP-Pool.
Entweder änderst du also die Client-IPs oder den konfigurierten IP-Pool.
Hallo,
nöö... Clients sind 4er Blöcke - /30 .. also 6, 10, 14 .... auch bei CCD Verwendung; falls du falsch vergeben hast "nimmt er aus dem Sack", siehe auch doku bei openvpn.net
für einzelne Maschinen nut im Zugriff (ggfs. Firewall) und korrekte Routen setzen ! Netmaske /32 z.B. oder wie auch immer deine Zugriffsverteilung ausschaut.
Fred
ps: IPs im Schema 1,2,3,4 ... geht nur in (openVPN)Bridged Networks
10.10.x.1 als IP-Adresse der Clients muss nicht sein. Schöner wäre es
10.10.0.1 # Server
10.10.0.2 # Client_01
10.10.0.1 # Server
10.10.0.2 # Client_01
nöö... Clients sind 4er Blöcke - /30 .. also 6, 10, 14 .... auch bei CCD Verwendung; falls du falsch vergeben hast "nimmt er aus dem Sack", siehe auch doku bei openvpn.net
für einzelne Maschinen nut im Zugriff (ggfs. Firewall) und korrekte Routen setzen ! Netmaske /32 z.B. oder wie auch immer deine Zugriffsverteilung ausschaut.
Fred
ps: IPs im Schema 1,2,3,4 ... geht nur in (openVPN)Bridged Networks
Clients sind 4er Blöcke - /30 .. also 6, 10, 14
Das ist das Dilemma des TO weil er hier das veraltete net30 Verfahren mit /30er Subnetzen verwendet. Das ist kontraproduktiv und man sollte immer besser das neue und aktuelle subnet Verfahren nutzen, dann klappt es auch besser mit der statischen Client IP Adressvergabe. Siehe dazu auch HIER.Für die Anforderung des TO reicht es lediglich das push "route..." oder push "redirect-gateway..." Kommando zu entfernen was er ja auch richtigerweise gemacht hat.
Irgendwelche Routen muss man natürlich nicht setzen, das ist Quatsch wenn nur die VPN Clients untereinander und nur den Server erreichen müssen. Das können sie immer über das interne VPN IP Netz. Dafür sind keine zusätzlichen Parameter in der Konfig Datei erforderlich !
