WICHTIG: Wartungsarbeiten am 10. März

Ihr habt doch gesoffen ;D

Naja, wie auch immer, die OpenVPN Umstellung ist fertig, ich hab jeden Server mal kurz getestet, scheint alles zu funktionieren..

Grüße
Lars
 
Jo, auch bei mir klappt alles. Gute und schnelle Arbeit!

Ich habe gerade bemerkt, dass die alten Gigabit-Domains bei Socks immer noch funktionieren, wie lang gedenkt ihr die noch am Leben zu erhalten?
 
Inkognito;n5539 said:
Ich habe gerade bemerkt, dass die alten Gigabit-Domains bei Socks immer noch funktionieren, wie lang gedenkt ihr die noch am Leben zu erhalten?
Click to expand...

Benutz die nicht und sags keinem :) Die Gigabit DNS Einträge für die Primären IPs der Server sind noch da, den code dafür hatte ich wegen fr.gigabit->paris gemacht. Wenn du jetzt heute zu faul bist das bei dir umzustellen, dann mach es am besten morgen. Irgendwann Ende der Woche sind die weg.

Grüße
Lars
 
Alles klar. Ihr habt leider einen großen Bug in euren .ovpns übersehen, nämlich folgenden

remote erfurt2.perfect-privacy.com 1149
remote erfurt2.perfect-privacy.com 151
remote erfurt2.perfect-privacy.com 150
remote erfurt2.perfect-privacy.com 149
remote erfurt2.perfect-privacy.com 1151
remote erfurt2.perfect-privacy.com 1150
# Fallbacks just in case..
remote erfurt2.perfect-privacy.net 149
remote erfurt2.perfect-privacy.info 1150
remote erfurt2.perfect-privacy.asia 151
remote erfurt2.perfect-privacy.info 1149
remote erfurt2.perfect-privacy.net 150
remote erfurt2.perfect-privacy.asia 1151
Click to expand...

Wie man sieht befinden sich die Ports der Fallbacks nicht in derselben Reihenfolge wie die der oberen Einträge. Es lässt sich auch keinerlei Muster erkennen, weswegen sich mir der Gedanke aufdrängt, dass einfach ohne jegliches Gewissen eine zufällige Reihenfolge ausgewählt wurde.
 
Inkognito;n5541 said:
Es lässt sich auch keinerlei Muster erkennen, weswegen sich mir der Gedanke aufdrängt, dass einfach ohne jegliches Gewissen eine zufällige Reihenfolge ausgewählt wurde.
Click to expand...

Skandal. Nicht nur das, ich kann dir sogar bestätigen das das python random.shuffle() war. Also noch viel gewissenloser als du dachtest. Wirklich Zufall.(naja, computer Zufall.. ) Und noch mehr, die nächste Zeile da drunter ist "remote-random" d.h. openvpn wählt aus dieser zufälligen liste auch noch einen zufälligen Server aus.

Wo war jetzt der Punkt? ;)

Grüße
Lars
 
Hi, neue config auf PC läuft, aber mit meinem Android hab ich Probleme. Während die alte cofig problemlos lief sagt die App mir jetzt folgendes

"Fehler beim Lesen der Konfigurationsdatei. Unsupported Option remote-random encountered in config file, Aborting"

Hilfeeeee!!:(
 
@Markymark

Sorry hat etwas gedauert. Du findest jetzt für iOS und Android extra Configs im Downloadbereich. Diese sollten gehn.
 
Betrifft: Android
1) Hab jetzt mal wild einen Server aus den mobile configs raus gefischt: Reykjavik. Ergebnis: Für Android unbrauchbar, weil die Option "remote-random" drin ist, mit der die "OpenVPN for Android" noch nie spielen mochte.
2) Neugierfrage: Warum sind die mobile configs laut dem Namen des zip-Archivs für TCP?
Denn:
3) Die Standard-Configs laufen eigentlich gut, sobald man "remote-random" rausgenommen hat. Bis auf die Fehlermeldungen, die auch der Desktop-Client schmeißt:

xxx Log Deprecated TLS cipher name 'DHE-RSA-AES256-GCM-SHA384', please use IANA name 'TLS-DHE-RSA-WITH-AES-256-GCM-SHA384'
xxx Log Deprecated TLS cipher name 'DHE-RSA-AES256-SHA256', please use IANA name 'TLS-DHE-RSA-WITH-AES-256-CBC-SHA256'
xxx Log Deprecated TLS cipher name 'DHE-RSA-AES128-GCM-SHA256', please use IANA name 'TLS-DHE-RSA-WITH-AES-128-GCM-SHA256'
xxx Log Deprecated TLS cipher name 'DHE-RSA-AES128-SHA256', please use IANA name 'TLS-DHE-RSA-WITH-AES-128-CBC-SHA256'
xxx Log Deprecated TLS cipher name 'DHE-RSA-CAMELLIA256-SHA', please use IANA name 'TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA'
xxx Log Deprecated TLS cipher name 'DHE-RSA-AES256-SHA', please use IANA name 'TLS-DHE-RSA-WITH-AES-256-CBC-SHA'
xxx Log Deprecated TLS cipher name 'DHE-RSA-CAMELLIA128-SHA', please use IANA name 'TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA'
xxx Log Deprecated TLS cipher name 'DHE-RSA-AES128-SHA', please use IANA name 'TLS-DHE-RSA-WITH-AES-128-CBC-SHA'
xxx Log Deprecated TLS cipher name 'CAMELLIA256-SHA', please use IANA name 'TLS-RSA-WITH-CAMELLIA-256-CBC-SHA'
xxx Log Deprecated TLS cipher name 'AES256-SHA', please use IANA name 'TLS-RSA-WITH-AES-256-CBC-SHA'
xxx Log Deprecated TLS cipher name 'CAMELLIA128-SHA', please use IANA name 'TLS-RSA-WITH-CAMELLIA-128-CBC-SHA'
xxx Log Deprecated TLS cipher name 'AES128-SHA', please use IANA name 'TLS-RSA-WITH-AES-128-CBC-SHA'
 
1) Hab jetzt mal wild einen Server aus den mobile configs raus gefischt: Reykjavik. Ergebnis: Für Android unbrauchbar, weil die Option "remote-random" drin ist, mit der die "OpenVPN for Android" noch nie spielen mochte.

-->Hrm.. ok das haben wir vor 3 tagen mit mehreren Geräten getestet und das ging. Argll. Naja. ich habs wieder rausgenommen, Neue Version der mobile config ist online.

2) Neugierfrage: Warum sind die mobile configs laut dem Namen des zip-Archivs für TCP?

--> weil die mobile configs im moment nur mit tcp gehen. aber vielleicht kommt ja udp mal dazu falls es ein OpenVPN update gibt.

3) Die Standard-Configs laufen eigentlich gut, sobald man "remote-random" rausgenommen hat. Bis auf die Fehlermeldungen, die auch der Desktop-Client schmeißt:
xxx Log Deprecated TLS cipher name 'DHE-RSA-AES256-GCM-SHA384', please use IANA name 'TLS-DHE-RSA-WITH-AES-256-GCM-SHA384'


--> Naja das ist kein Fehler, das ist ein warnung, openvpn hat die ciphers umbekannt. Ich wollte das aber jetzt nicht sofort auch machen weil wir noch Mitglieder haben mit alten OpenVPN versionen und so weiter. Die benenne ich irgendwann mal um, das ist aber dann transparent und keiner muss seine config gezwungenermaßen updaten.

Grüße
Lars
 
Ich hab hier noch einige Probleme. Frankfurt reagiert überhaupt nicht und Rotterdam bringt seine config nicht richtig 'rüber.
Was habt ihr da gemacht?
Code: 
/sbin/route delete -net 0.0.0.0 netmask 128.0.0.0
echo "/sbin/route delete -net 0.0.0.0 netmask 128.0.0.0"
/sbin/route delete -net 128.0.0.0 netmask 128.0.0.0
echo "/sbin/route delete -net 128.0.0.0 netmask 128.0.0.0"
echo "ifconfig_local"
echo $ifconfig_local
echo "ifconfig_remote"
echo $ifconfig_remote
echo "ifconfig_netmask"
echo $ifconfig_netmask
echo "foreign_option_1"
echo $foreign_option_1
echo "foreign_option_2"
echo $foreign_option_2
echo "foreign_option_3"
echo $foreign_option_3

proxy="proxy_Rotterdam"

preamble=`echo $ifconfig_remote | cut -d '.' -f 1-3`
Gateway="${preamble}.1"
echo -e $Gateway '\t' $proxy > /etc/openvpn/gateways/Rotterdam_gateway

/sbin/route add -net $Gateway netmask 255.255.255.255 gw $ifconfig_remote
echo "/sbin/route add -net $Gateway netmask 255.255.255.255 gw $ifconfig_remote"
ifconfig_remote wird nicht zurückgegeben und zwar nur bei Rotterdam, die anderen, die ich umgestellt habe, machen es richtig.
Es gibt zwar einen workaround, nämlich $config_local zu nehmen, aber das geht nur, weil beide jetzt identisch sind (bislang waren sie unterschiedlich)
Das steht im log (mit workaround):
Code: 
...
Mon Mar 10 19:56:17 2014 us=172840 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.16.13.1
Mon Mar 10 19:56:17 2014 us=176065 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.16.13.1
/sbin/route delete -net 0.0.0.0 netmask 128.0.0.0
/sbin/route delete -net 128.0.0.0 netmask 128.0.0.0
ifconfig_local
10.16.13.6
ifconfig_remote

ifconfig_netmask
255.255.255.0
foreign_option_1
dhcp-option DNS 176.10.115.98
foreign_option_2
dhcp-option DNS 46.165.196.73
foreign_option_3

/sbin/route add -net 10.16.13.1 netmask 255.255.255.255 gw 10.16.13.6
Mon Mar 10 19:56:17 2014 us=199618 GID set to nogroup
Mon Mar 10 19:56:17 2014 us=199690 UID set to nobody
Mon Mar 10 19:56:17 2014 us=199711 Initialization Sequence Completed

Hier das log von Frankfurt:
Code: 
Mon Mar 10 19:57:01 2014 us=138534 Expected Remote Options hash (VER=V4): 'ad1c1209'
Mon Mar 10 19:57:01 2014 us=138561 UDPv4 link local: [undef]
Mon Mar 10 19:57:01 2014 us=138584 UDPv4 link remote: [AF_INET]46.165.196.73:1151
Mon Mar 10 19:59:02 2014 us=107870 [UNDEF] Inactivity timeout (--ping-restart), restarting
Mon Mar 10 19:59:02 2014 us=107968 TCP/UDP: Closing socket
Mon Mar 10 19:59:02 2014 us=108007 SIGUSR1[soft,ping-restart] received, process restarting
Mon Mar 10 19:59:02 2014 us=108029 Restart pause, 2 second(s)

Korrektur - das mit ifconfig_remote scheint auch bei anderen der Fall zu sein. Ist zwar 'ne leichte Übung, das eben zu ändern, aber bleibt das auch so?
 
Seit dem ich die neuen Konfig-Files über den PP OpenVPN Manager habe, ist der Ping (wenn man verbunden ist) sehr hoch. Ist das jetzt normal, da die Verschlüsselung erhöht wurde ?

Gr33tz
Fusi0nCr0w
 
Hm,bei mir läuft nichts mehr. Hab sowohl den PP OpenVPN Manager neu installiert als auch die ServerListe manuell noch mal neu eingefügt. Aber nichts :(

3/11/2014 3:57:55 PM Management Connecting to management interface 127.0.0.1:11001
3/11/2014 3:57:55 PM Log MANAGEMENT: CMD 'state on'
3/11/2014 3:57:55 PM Log MANAGEMENT: CMD 'hold release'
3/11/2014 3:57:55 PM Log MANAGEMENT: CMD 'username 'Auth' "XXX"'
3/11/2014 3:57:56 PM Log MANAGEMENT: CMD 'password [...]'
3/11/2014 3:57:56 PM Log Restart pause, 2 second(s)
3/11/2014 3:57:58 PM Log Control Channel Authentication: using 'Gigabit-US_ta.key' as a OpenVPN static key file
3/11/2014 3:57:58 PM Log Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
3/11/2014 3:57:58 PM Log Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
3/11/2014 3:57:58 PM Log LZO compression initialized
3/11/2014 3:57:58 PM Log Control Channel MTU parms [ L:1560 D:168 EF:68 EB:0 ET:0 EL:0 ]
3/11/2014 3:57:58 PM Log Socket Buffers: R=[8192->8192] S=[8192->8192]
3/11/2014 3:57:58 PM Log MANAGEMENT: >STATE:1394571478,RESOLVE,,,
3/11/2014 3:57:58 PM State RESOLVE
3/11/2014 3:57:59 PM Log Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]
3/11/2014 3:57:59 PM Log Local Options String: 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
3/11/2014 3:57:59 PM Log Expected Remote Options String: 'V4,dev-type tun,link-mtu 1560,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
3/11/2014 3:57:59 PM Log Local Options hash (VER=V4): '2f2c6498'
3/11/2014 3:57:59 PM Log Expected Remote Options hash (VER=V4): '9915e4a2'
3/11/2014 3:57:59 PM Log Attempting to establish TCP connection with [AF_INET]208.53.158.59:152
3/11/2014 3:57:59 PM Log MANAGEMENT: >STATE:1394571479,TCP_CONNECT,,,
3/11/2014 3:57:59 PM State TCP_CONNECT
3/11/2014 3:58:20 PM Log TCP: connect to [AF_INET]208.53.158.59:152 failed, will try again in 5 seconds: Connection timed out (WSAETIMEDOUT)
3/11/2014 3:58:20 PM Log SIGUSR1[soft,init_instance] received, process restarting
3/11/2014 3:58:20 PM Log MANAGEMENT: >STATE:1394571500,RECONNECTING,init_instance,,
3/11/2014 3:58:20 PM State RECONNECTING
Click to expand...

das geht endlos dann so weiter... auf jedem Server :/
 
Sehr eigenartig. Deinstalliere mal den Manager über die Systemsteuerung und "Program deinstallieren". Und dann installiere diesen nochmal. Ich hatte mal den Fehler, das beim Update die Dateien nicht wirk,ich überschrieben wurden.
 
Immer noch das gleiche. Das strange ist auch, dass ich mich ganz normal mit meinem usr/pw in den Kundenbereicheinloggen kann von PP. Aber wenn ich im PP OVPN auf Server updaten clicke, bekomme ich immer ein "download failed":
 
You must log in or register to reply here.
Back
Top