Wismerhill

Merci pour l'info Roy. C'est vrai que ça va aider à suivre ce qui se passe :o)

Bonjour Roy, merci pour tes recherches. Je me suis fait un petit script qui se lance toutes les heures pour vérifier l'état du pare feu avec la commande iptables -L -v et j'obtiens ça : ***************************************** Sat Nov 21 12:00:02 CET 2015 ***************************************** Chain INPUT (policy ACCEPT 410 packets, 47528 bytes) pkts bytes target prot opt in out source destination 39379 4262K DEFAULT_INPUT all -- any any anywhere anywhere Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 48484 packets, 44M bytes) pkts bytes target prot opt in out source destination Chain DEFAULT_INPUT (1 references) pkts bytes target prot opt in out source destination 12151 556K ACCEPT tcp -- tun0 any anywhere anywhere multiport dports http,DSM-https,50000 26766 3654K ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED 15 808 DROP tcp -- tun0 any anywhere anywhere 31 2365 DROP udp -- tun0 any anywhere anywhere 1 32 DROP icmp -- tun0 any anywhere anywhere @+

Bonjour à tous, depuis quelques semaines j'ai quelques soucis avec le script de Cedcox. Les règles Iptables ne sont plus exécutées. Dans le script il y a un test pour savoir si le pare feu est en route : # Firewall is up ? if [ -n "$(ifconfig | grep "$interface_vpn")" ] && [ -z "$($iptables -L -v | grep "$interface_vpn")" ]; then echo $(date) ": Interface " $interface_vpn " found but firewall is not configured..." >> $logfile Normallement à chaque reconnexion du vpn toutes les règles iptables sont supprimées. Toutes ? Non, car deux irréductibles règles résistent encore et toujours : Chain DOS_PROTECT_VPN (1 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- tun0 any anywhere anywhere limit: avg 1/sec burst 3 0 0 DROP all -- tun0 any anywhere anywhere Du coup comme le script voit des règles iptables il pense que la protection est déjà activée et il ne relance pas les règles sur la connexion vpn. Pour ne pas tenir compte de la protection DOS toujours en place j'ai remplacé $iptables -L -v par $iptables -L INPUT à chaque test de la présence du parefeu. Je ne comprends pas pourquoi les règles DOS sont toujours actives, quand j'avais mis en place le script de Cedcox je n'avais pas ce problème. Je ne sais pas si d'autres que moi ont ce problème mais je vous invite à vérifier vos règles iptables !

Merci pour le coup de main, ça marche super bien :o) @+

Bonsoir Roy, merci pour ta réponse, je vais tester au plus vite ) Juste pour être bien sûr, est-ce que les variables doivent être mises entre guillemets ? openvpn_confid="/usr/syno/etc/synovpnclient/openvpn/client_o1420449358" openvpn_configname="nom déclaré" @+

Bonjour à tous, pour le moment j'utilise le script d'Argenos avec l'astuce de Stev84 qui permet de le lancer à chaque changement de connexion, du coup, plus besoin de passer par cron : J'aimerais bien utiliser le script de Cedcox mais je suis bloqué avec 2 variables : openvpn_confid= openvpn_configname= Je suppose qu'openvpn_configname correspond au nom que j'ai donné à ma configuration vpn lors de sa création par contre je ne vois pas à quoi correspond openvpn_confid. Merci d'avance pour votre aide.

Ca y est, je viens de recevoir 2 disques WD15EADS-00R6B0 par le SAV de Western Digital, en remplacement de mes disques non compatibles. Et l

donc j'ai

la r

ben en fait je pense que le câblage est bon parce que sur le même switch j'ai le nas et mon pc. J'ai partagé un répertoire avec des films sur mon pc (partage type samba), et mon pch trouve sans problème ce répertoire et la lecture des films (en hd ou pas) se fait sans aucun problème. Du coup, comme je ne vois vraiment pas d'où ça pourrait venir, je suis en train de re-préparer les disques du syno. Mais cette fois ci, en faisant une préparation complète. Donc j'ai monté les disques dans le pc, et comme je suis sous Ubuntu, j'ai pu lancer la commande : sudo dd if=/dev/zero of=/dev/sdb bs=1M conv=noerror Ca a pris une petite dizaine d'heures pas disque. Maintenant les disques sont dans le syno et pour l'instant c'est la création du volume en jbod. Le premier disque a été vérifié en 11 heures, et pour le deuxième ça devrait plutôt se faire en 15 - 16 heures. Je trouve ça un peu long mais peut-être que c'est normal pour des disques de 1,5To Si après tout ça il y a encore des problèmes, je pense que le syno ira faire un stage en sav... [edit] Finalement le nas n'est pas encore parti en sav, j'ai envoyé un mail à synology et j'attends la réponse. En attendant, j'ai retiré un des 2 disques et re-préparé celui restant en un volume de base, et pour l'instant tout semble fonctionner nettement mieux. Ce qui est surprenant, s'il s'avère que le problème venait bien de ce disque, c'est que lors de la préparation sous Ubuntu il n'y avait aucune erreur, puis la préparation du volume par le syno n'avait noté qu'une erreur sur 1 des 2 disques. Hors j'avais cru comprendre que la préparation du syno permettait justement d'éviter les ennuis en écartant les secteurs à problèmes (on m'aurait menti à l'insu de mon plein gré...) Bon je continue mes investigations et je posterai le résultat, peut être que ça pourra servir à quelqu'un [edit]

Salut

Merci pour la r

Salut

bon finalement, n'arrivant pas

Salut

Ça y est j'ai fais des tests : le plus rapide c'est le branchement direct du nas sur le pc avec un câble réseau. Il faut juste vérifier que la carte réseau du pc et celle du nas sont bien dans des adresses compatibles (par exemple chez moi ça commence par du 192.168.0.X) et là, le débit oscille régulièrement entre 20 et 30 Mo/s avec des transferts dans filezilla (plus souvent proche de 30Mo/s).

Salut Lucky, effectivement j'ai des plugs en 200MB/s (Lenovo). J'avais l'intention de tester l'installation en direct sur la freebox sans les plugs, mais je pense que je vais faire le test

Bonjour