Es hat eine ganze Weile gedauert, aber ich habe es geschafft connlimit mit limit-burst "nachzubauen". Dieses Script erlaubt nur einen Up- bzw Download:
Rich (BBCode):
#!/bin/sh
# #####################################
# LimitCloudSync v0.2
#
# Notes:
# This adds a new rule to iptables that limits OUTGOING traffic to a specific domain
#
# Changelog:
# 0.2
# - working script
# 0.1
# - first release
#
# Todo:
# #####################################
destination="<deineCloud>.owncube.com"
dest_domain="owncube.com"
# check running tcp connections
tcp_stats="$(netstat --tcp --wide | grep $dest_domain)"
established=0
while read line; do
# echo $line
if [[ "$line" =~ "ESTABLISHED" ]]; then
established=$((established+1))
fi
done <<< "$tcp_stats"
echo $established
if [[ $established == 0 ]]; then
# check if this rule was set before (this means an up- / download has been finished)
iptables -C OUTPUT -p TCP --match state --state NEW --match limit --limit 1/d --limit-burst 1 --jump ACCEPT -d $destination
iptables_return=$?
if [[ $iptables_return -eq 0 ]]; then
# add general drop rule (to avoid new connections while resetting the rules)
iptables -A OUTPUT --jump DROP -d $destination
# delete old burst limit
iptables -D OUTPUT -p TCP --match state --state NEW --match limit --limit 1/d --limit-burst 1 --jump ACCEPT -d $destination
# delete old DROP rule
iptables -D OUTPUT --match state --state NEW --jump DROP -d $destination
# now it will re-add the burst limit and by that it will reset the bucket to 1 new connection
fi
# add new burst limit
iptables -A OUTPUT -p TCP --match state --state NEW --match limit --limit 1/d --limit-burst 1 --jump ACCEPT -d $destination
# add new drop rule at the bottom
iptables -A OUTPUT --match state --state NEW --jump DROP -d $destination
# delete general drop rule
iptables -D OUTPUT --jump DROP -d $destination
elif [[ $established != 1 ]]; then
# check if the global rule exists (this means its still trying to kill existing connections)
iptables -C OUTPUT --jump DROP -d $destination
iptables_return=$?
if [[ $iptables_return != 0 ]]; then
# add general drop rule (this will slowly kill existing connections)
iptables -A OUTPUT --jump DROP -d $destination
# check if a burst rule is set (if not, this is the very first request of the script and we do nothing)
iptables -C OUTPUT -p TCP --match state --state NEW --match limit --limit 1/d --limit-burst 1 --jump ACCEPT -d $destination
iptables_return=$?
if [[ $iptables_return -eq 0 ]]; then
# delete old burst limit
iptables -D OUTPUT -p TCP --match state --state NEW --match limit --limit 1/d --limit-burst 1 --jump ACCEPT -d $destination
# delete the old DROP rule
iptables -D OUTPUT --match state --state NEW --jump DROP -d $destination
fi
fi
fi
Zur Erklärung:
Man hinterlegt das Script im Aufgabenplaner und stellt die Ausführung auf minütlich:
Beim Neustart des NAS wird Cloud Sync so viele Verbindungen aufbauen wie eingestellt sind. Also in der Regel starten dann 3 Up-/Downloads. Nachdem das Script dann ausgeführt wird, greift der letzte Block ($established != 1). Dieser blockiert alle TCP Pakete in Richtung der Cloud bis keine Verbindung mehr besteht. Beim nächsten Aufruf des Scriptes greift dann der erste Block ($established == 0). Dieser erlaubt pro Tag eine Verbindung. Sobald nun der Up- / Download fertig ist, wird diese Verbindung wieder verschwinden und sobald danach das Script wieder aufgerufen wird, wird wieder eine Verbindung pro Tag erlaubt.
In Screenshots sieht das dann aus wie folgt:
Das NAS wurde neu gestartet (wie man sieht respektiert Cloud Sync nicht mal die eigenen Einstellung von 3 Verbindungen):
Es dauert ein paar Minuten, aber dann sind alle Verbindungen gekillt:
Danach öffnet das Script eine Verbindung zur Cloud, die dann natürlich die maximale Bandbreite nutzen kann:
Hinweise:
1.) Meine Cloud ist bei owncube.com gehostet. Ich habe dort eine subdomain.owncube.com. Trotzdem braucht das Script die Domain, denn subdomain.owncube.com ist nur ein Alias von occloudXXX.owncube.com und unser Script sucht in den TCP-Verbindungen gezielt nach dieser Zieladresse. Man muss also destination und dest_domain korrekt einstellen.
2.) Die einzige Möglichkeit, dass nun mehr als eine Verbindung aufgebaut wird ist, dass der Up- / Download einer Datei länger als 24 Stunden benötigt. In diesem Fall würde limit-burst eine weitere Verbindung erlauben. Das Script wiederum würde dann wieder anfangen alle Verbindungen zu killen. Das muss man wissen, sofern man so große Einzeldateien in die Cloud lädt bzw der Upload sehr langsam ist. Die würde dann logischerweise nie hochgeladen werden. Kommt bei mir nicht vor, sollte man aber einfach wissen.
3.) Ich empfehle jedem Cloud Sync über die allgemeine Datenflusssteuerung zu limitieren, gerade wenn das NAS an einem anderen Standort steht und per Fernwartung erreichbar bleiben soll. Wenn der Upload komplett bei DSL Anschlüssen genutzt wird, kann sich das nämlich negativ auf den Ping bzw den Download auswirken. Bei einem billigen Router kann es sogar passieren das gar nichts mehr geht (fehlendes QoS). Ich konnte zB bei einem Standort nicht mal mehr per Teamviewer auf einen lokalen PC zugreifen um von dort aufs NAS zu kommen und vor Ort gab es massive Probleme schon beim Laden von Internetseiten (weil eine Anfrage an eine Website ja auch nichts anderes als ein Upload ist). Wenn das Ziel von Cloud Sync wie bei mir ein WebDAV Server ist, dann müsste man in dem Fall die Ports 80 und 443 limitieren (bei diesem Anschluss habe ich den Upload auf 3 MB/s von 4 MB/s begrenzt):
