Hey,
hatte es heute morgen auf der wireless-berlin gepostet, aber Euch betrifft das natürlich auch. Ich hab' eine Änderung in den Rückrouten in den VPN03-Server eingebaut. Nun interessiert mich natürlich, ob die schnell Umschaltung klappt und was bringt. Darum lasse ich derzeit eine Debug-Ausgabe mitlaufen. Der Gewinner ist 10.22.2.160 mit 37 Umschaltungen seit 08:00h. Vom VPN03 aus kann ich ja die Web-UI der beiden DSL/VPN-Exitnodes abfragen:
entweder 10.22.0.160 -> 10.22.2.160, LQ=0,666 NLQ=0,156 oder 10.22.4.32 -> 10.22.2.160, LQ=0,584 NLQ=0,878
Was mich nun interessiert (und ich nicht checken kann): die 10.22.2.160 schaltet ja öfter zwischen 2. Exitnodes um. Geht das schnell genug, um eine SSH-Session nach Extern oder einen Download nicht zu unterbrechen? Oder merkt man das (abgebrochene Downloads, SSH-Sessions etc). Kann mal jemand von Euch nachgucken?
Gruß // Sven-Ola
<ZIT> heute größeres OpenVPN-Update auf VPN03 eingespielt. Version(2.3.1) auf Version(2.3.2) und wichtiger: Bugfix für Rückrouten-Umschaltung und Verlängerung des Rückrouten-Timeouts von 60s auf 1h.
Hintergrund: über VPN03 geht mittlerweile schon etwas Verkehr. Heute morgen ist nix los, aber
root@vpn03:/tmp# ip r | wc -l 246
Heisst: das Server "sieht" 250 einzelne IPv4-Adressen die in der letzen Stunde Pakete ins Internet gesendet haben. Das ist ein gepatchter OpenVPN, der hereinkommende Pakete auf einem der Tunnel zum gleichen Tunnel zurückroutet. So sparen wir uns de n $Routingdaemon auf der Kistes. Sind in einem Mesh mehrere VPN-Tunnel-Ausgänge aktiv kann es vorkommen, dass eine Node bei ungeänderter IPv4 von einem zum anderen Tunnel wandert ("Roaming"). Das war bisher mit Timeout gelöst. Ich hab' es jetzt auf "Umschalten" geändert. Wenn's da irgend welche Quirks gibt: gerne Bescheid an mich. </ZIT>
// Sven-Ola