This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

 

Si nous utilisons des cookies et retenons des données anonymes, c’est pour nous aider à mieux gérer notre mesure d’audience, aider nos partenaires commerciaux à nous rémunérer et nos partenaires publicitaires à proposer des annonces qui vous correspondent.

 

Grâce à ces cookies, le forum est en mesure de savoir qui écrit un message et utile pour le système d'authentification.

 

En cliquant sur « J'accepte », vous acceptez l'utilisation par NAS-Forum de cookies publicitaires et de mesure d'audience fine.

Nemesis666

Membres
  • Compteur de contenus

    66
  • Inscription

  • Dernière visite

À propos de Nemesis666

  • Rang
    Novice Syno

Visiteurs récents du profil

Le bloc de visiteurs récents est désactivé et il n’est pas visible pour les autres utilisateurs.

  1. Je ne pensais pas avoir besoin d'épiloguer à ce sujet là : je me trouve en résidence universitaire, je n'ai pas accès à ma propre box. Maintenant que tu le dit, l'interface a changé en effet oO !
  2. J'ai tenté de modifier le MDP Admin, mais rien à faire... Je n'y comprend rien...
  3. Bonjour à tous, Ce matin j'ai eu une coupure de courant sur mon 415+, manque de bol, il joue également le rôle de routeur, et je dois constamment remettre la valeur "iptables blablabla MASQUERADE blablabla" après chaque reboot pour qu'il route. Et donc là, en voulant remettre la commande, je me log en root en SSH (ou Telnet, aucune importance), et il me dit "access denied", je tente en admin, ça passe, mais impossible de ping ou de balancer la moindre commande. Comment est-il possible que mon MDP root (composé de lettre minuscule uniquement) ne soit plus accepté ? C'est assez urgent je vous avoue, je n'ai plus internet du tout... Un dimanche... :'( !!!
  4. Mes collègues arrivent à me voir, pour la plupart. J'ai un autre petit soucis : je dois remettre la commande << iptables [...] MASQUERADE >> après chaque extinction/coupure de courant, une idée sur ce point ?
  5. EDIT4 : Okay, donc quand j'ai retiré la passerelle par défaut, je ne me suis pas rendu compte que j'avais récupéré internet via le câble, mais pour tester le NAT moi je faisais des pings vers 192.168.6.10 (PC-Steph sur le schéma) ou 6.101 (Routeur Hebernet sur le schéma). Et comme il n'y avait pas de retour, j'en concluais que ça ne marchais pas. Donc là, le problème est à moitié résolu, j'ai récupéré internet, c'est l'essentiel, mais il faut que j'ai accès aux PC / Routeur de mes collègues maintenant.
  6. Oui il y avait un "s", quand j'ai copié collé j'ai mis celle où je m'étais gourrer, mais ça ne change rien : NeM-NAS> insmod /lib/modules/iptable_nat.ko insmod: can't insert '/lib/modules/iptable_nat.ko': File exists EDIT : ha oui non là il me dit qu'il est déjà chargé, attend je coupe le VPN et je reteste. EDIT2 : Oui voilà le message que ça me mettait : NeM-NAS> insmod /lib/modules/iptable_nat.ko insmod: can't insert '/lib/modules/iptable_nat.ko': unknown symbol in module, or unknown parameter EDIT3 : bon j'ai remis le VPN pour tester la modification antérieure : même sans passerelle renseigné pour ETH1 et commande MASQUERADE remise avec ETH0, ça ne change pas des masses.
  7. C'est effectivement la plage VPN. Mon réseau est déjà en 38.0/24 (passerelle renseigné y compris). Euh, je ne comprends pas trop ce que tu veux dire là, le NAT, tu l'as déjà "configuré" en passant la commande Ce que je veux dire c'est que les paquets passent et son routé dans un sens, mais qu'à mon avis y'a un problème au niveau du NAT car les paquets ne reviennent pas. Je vais vérifier qu'il n'y ait pas de passerelle configuré sur ETH1. EDIT : il y avait en effet une passerelle configuré sur ETH1, je l'ai retirer, je vais test après avoir reboot et remis la commande.
  8. EDIT : bon, en retapant la commande MASQUERADE blabla, il m'a rajouté une ligne : Chain DEFAULT_POSTROUTING (1 references) target prot opt source destination MASQUERADE all -- 10.0.0.0/24 anywhere MASQUERADE all -- anywhere anywhere Ca veut donc bien dire qu'il ne conserve pas l'info à chaque redémarrage. J'ai voulu remplacer ETH0 par ETH1, en me disant que, de toute manière, ça n'était pas gênant, ça remplacerait sûrement la précédente entrée, et ça me donne ça à présent : Chain DEFAULT_POSTROUTING (1 references) target prot opt source destination MASQUERADE all -- 10.0.0.0/24 anywhere MASQUERADE all -- anywhere anywhere MASQUERADE all -- anywhere anywhere Ca s'est donc rajouté dans la liste, cela dit ça ne fonctionne toujours pas.
  9. Insmod ne fonctionne pas non plus : NeM-NAS> insmod /lib/module/iptable_nat.ko insmod: can't insert '/lib/module/iptable_nat.ko': No such file or directory Oui c'est bien Eth0 qui est relié coté SwitchHebernet (F0/0 sur le schéma). Un "iptables -L -t nat" si ça peut aider : NeM-NAS> iptables -L -t nat Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination DEFAULT_POSTROUTING all -- anywhere anywhere Chain DEFAULT_POSTROUTING (1 references) target prot opt source destination MASQUERADE all -- 10.0.0.0/24 anywhere Pour les deux commandes, IP_FORWARD c'est bon (je l'ai inscrit pour qu'elle soit exécuté au lancement du routeur), et la seconde commande je l'ai rentré avec comme option "ETH0" (dégage t'elle à chaque redémarrage ? Je vais tenter de la remettre encore une fois peut-être). Comme je l'ai écris, le routage fonctionne visiblement, c'est le NAT à présent que je dois configurer.
  10. Donc je réactive le VPN (je ne m'y connecte pas), iptables s'active, mais ça ne marche toujours pas : NeM-NAS> iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) NeM-NAS> cat /proc/sys/net/ipv4/ip_forward 1 NeM-NAS> route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.6.101 0.0.0.0 UG 0 0 0 eth0 192.168.6.0 * 255.255.255.0 U 0 0 0 eth0 192.168.38.0 * 255.255.255.0 U 0 0 0 eth1 (A noter qu'OpenVPN me parle du port 1723 qui doit être ouvert etc... Bon évidement il n'est pas bloqué mais qu'est ce que je peux / qu'est ce je dois faire de ce port ?)
  11. Non non, ça c'est une contrainte technique pour contourner la "sécurité" en cas d'urgence, mais sur mon PC en débranchant le routeur du coup (en changeant la topologie). Oui je crois être quasiment sûre que ça passait, mais comme je switchais entre activation de VPN / désactivation de VPN / allumage de WiFi / désactivation de WiFi, il est bien possible que je me sois planté quelque part (puisque ça ne fonctionne pas/plus). Je ne comprend pas, d'un coté on me dit qu'on a pas besoin du NAT pour faire du routage, et de l'autre si, faut qu'on accorde nos violons là. J'écris que modprobe ne veux pas fonctionner à cause de ceci ou de cela, et que mes recherches ne donnent rien, et toi tu veux m'envoyer sur Google, si ça c'est pas du trolling qu'est ce que c'est >< !
  12. Stooa la couche ! Donc, il se trouve que j'ai été voir un spécialiste du Linux (pas de BusyBox hélas [la distribution qu'utilise Syno si je ne m'abuse]), et qu'en fait le dossier /sys/ n'a rien d'un dossier pour le coup. Voilà, ensuite je lui ai expliqué l'histoire du NAT, et il m'a répondu que : si l'on avait pas besoin de faire du NAT, ça ne servait absolument à rien pour faire du routage (et effectivement, si le NAT sert effectivement au VPN, pour le routage de base, on s'en fout), donc bravo monsieur Gaetan.Cambier pour cette réflexion hautement intéressante mais inutile, que je vous recolle ici, dans un Français approximatif : c la base de la base Ce n'est rien, ça me fait plaisir. Ensuite, on m'a fait désactiver la protection DDOS (DOS), puis on a fait mumuse avec Wireshark (sur le PC) et tcpdump/fidump (sur le routeur, évidement) pour finalement constater que les paquets passaient du PC vers l'extérieur, mais qu'ils ne revenaient pas, on en a donc conclu que le routage était effectif, mais qu'il y avait un autre problème ailleurs. Tiens, j'ai ça aussi : / # iptables -L modprobe: chdir(3.10.35): No such file or directory iptables v1.4.21: can't initialize iptables table `filter': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. Bon, je n'ai pu passer qu'une heure ou deux avec lui, donc pour trouver d'où ça vient, je suis de retour ici xD ! Cela dit, je pense qu'il y a une 9ème couche, que j'intitulerais sobrement : La Couche MURPHY.
  13. Je trouve ça quand je fais un find : NeM-NAS> find / -name iptable_nat /sys/module/ip_tables/holders/iptable_nat /sys/module/nf_nat/holders/iptable_nat /sys/module/nf_nat_ipv4/holders/iptable_nat /sys/module/nf_conntrack/holders/iptable_nat /sys/module/iptable_nat Naivement, j'ai testé "modprobe /sys/module/iptable_nat" (on sais jamais, hein), mais ça met le même message. Dois-je en déduire qu'il sait déjà qu'il a toujours eu accès au module IPTABLE_NAT, mais que le problème est ailleurs ?