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
