Et à quel moment systemd va lui donner plus de boulot qu'avant ? Wep, il va devoir lire quelques pages de man et effectuer quelques tests, rien de nouveau pour un mec qui utilise Linux au quotidien.
Faut arrêter d'exagérer avec ça… A croire que les gens passent leur vie à interagir en permanence avec le système d'init… Je suis admin système et avant, c'était une véritable agonie d'écrire un script de démarrage correct pour un processus sous Linux… C'était pas élégant, bourré de race condition, pas compatible entre les distribution… Depuis systemd, j'ai échangé la commande service par systemctl, je peux écrire des units très facilement, exprimer des dépendances de manière élégante et copier/coller mes unités sans crainte de voir le processus se vautrer lamentablement. Que du bénéfice en somme.
Alors oui, moi aussi parfois je soulève un sourcil quand je vois la dernière nouveauté intégrée dans systemd. Puis je me souviens que je ne suis pas seul au monde, que les gens ont des besoins différents et que systemd essaye d'y répondre…
C'est pitoyable de balancer des tirades sur la liberté alors que ce que tu veux réellement, c'est empêcher les autres d'utiliser un projet que tu n'aimes pas.
Tu n'aimes pas systemd ? Va argumenter avec les développeurs et les mainteneurs qui décident de l'utiliser (tu sais, les mecs qui créent des logiciels que tu aimes bien utiliser gratuitement). Au pire, contribue, fork ou change de distro.
C'est le monde du libre, t'es libre de ne pas aimer et de changer.
[root@arch2 ~]# ip tuntap add mode tap dev tap2
[root@arch2 ~]# ovs-vsctl add-port ovs1 tap2
[root@arch2 ~]# ovs-vsctl list-ports ovs1
tap2
Tu as peut-être un reste de configuration dans lequel tu aurais ajouté ton interface physique par accident… En présumant que le nom de ton interface physique est eth0, essaye ceci :
Ma question finale est : Comment créer OVS1 et OVS2 ?
ovs-vsctl add-br ovs1
ovs-vsctl add-br ovs2
Tu peux plugger à chaud une VM sur un switch existant, ça lui rajoutera des ports virtuels à la volée. Libvirt est capable de le faire sans soucis. Tu dois créer un "réseau virtuel" par switch et attacher tes VM à ces réseaux (soit lors de l'installation, soit plus tard en éditant les paramètres de la machine)
Tu connais beaucoup d’admin. sys. qui vont mettre des IP aléatoires à leurs serveurs ?
Il suffit de chercher de :: à ::10 et tu auras déjà trouvé une bonne partie des hôtes.
Je sais bien que les administrateurs auront tendance à donner des adresses « prédictibles » à leurs serveurs mais il faut penser un peu au-delà de sa bulle et imaginer tous les cas dans lesquels IPv6 sera utilisé. Typiquement dans un réseau LAN domestique où l’auto configuration sera utilisée pour générer des IPv6 à rallonge imprédictibles.
Ou implémentent un mauvais firewall. Par exemple, chez l’opérateur Voo en Belgique, le routeur offre un firewall « activé ou désactivé ». Il est impossible d’ouvrir un port spécifique.
Sur mes LAN, je fais du RA + DHCPv6 pour les DNS et ça marche sur les OS les plus utilisé (Linux, Windows 7, Mac OS).
Et c’est une bonne nouvelle. Mais même sur ces OS « mainstream », il existe des divergences (voir le document) quant à la manière de lire les flags des RA et cela oblige l’administrateur à configurer le système pour maximiser la prédictibilité (rien que pour désactiver les privacy extensions par exemple). Et encore, tu as la chance de ne travailler qu’avec des OS dont le stack IPv6 est relativement bien testé. Je travaille dans des hôpitaux et je dois gérer un parc hétéroclite au possible (des AS400, des lecteurs bancontact, des respirateurs, des frigos, etc.) et je te prie de croire que c’est déjà relativement folklorique en IPv4…
Bien sûr, mais empiler les couches de NAT et de reverse-proxy comme ça se fait actuellement en IPv4, ça n'est pas simple ni sans poser problème.
Tout à fait. IPv4 s’est complexifié à cause de ces rustines. Mais s’imaginer qu’IPv6 est plus simple car « c’est comme IPv4 mais sans le PAT/CGN », c’est une erreur. Il ne suffit pas de cocher la case « Activer IPv6 » et d’aller boire un café en oubliant l’existence de ce protocole. IPv6 est une nécessité technique pour conserver un internet ouvert et c’est pour cela qu’il faut que les gens aient conscience que tout n’est pas rose. Le pire qu’il puisse y avoir, c’est que les gens déploient IPv6 dans leurs réseaux sans avoir conscience de tous ces paramètres, se prennent un retour de flammes et gardent une mauvaise image du protocole…
Je n'ai malheureusement pas eu le temps d'éditer mon message mais il faut aussi mentionner le fait que l'adressage local d'un réseau devient complètement dépendant du préfixe distribué par le FAI. Si on change de FAI, on doit changer la totalité de l'adressage interne… C'est relativement acceptable dans un LAN domestique mais dans une entreprise possédant plusieurs centaines/millers de machines, c'est se tirer une balle dans le pied… Pour régler cette problématique, on est en train de combiner les adresses IPv6 ULA avec un nouveau type de NAT : "IPv6 Network Prefix Translation".
Pour en revenir à la simplicité de gestion, on peut également aborder le problème de la distribution des adresses IPv6 aux hôtes. En IPv4, on connait deux méthodes principales : l'adressage statique et dynamique via DHCP. L’auto-configuration est quasiment inutilisée. En revanche, en IPv6, les choses sont complètements différentes : le DHPv6 ne distribue pas de routes et est fortement dépendant des RA envoyés par les routeurs. On ajoute à cela que chaque OS réagit de manière différente aux flags des RA et on se retrouve vite avec une grosse mélasse sur les bras
Les OS modernes implémentent la RFC 4941 qui permet de générer des adresses aléatoires et temporaires. Cet argument ne tient pas la route… IPv6 ne protège pas mieux ou moins bien qu'IPv4
Si tu n'as pas besoin d'effectuer de manipulations dans ton routeur pour avoir accès à ton LAN depuis l'extérieur en IPv6, c'est qu'il n'y a pas de firewall dans ton routeur et que tu es cul nul face à internet.
L'IPv6 est là pour palier à la pénurie d'adresse IPv4 qui oblige l'utilisation de rustines comme PAT et CGN qui sont des plaies pour les administrateurs réseaux et les personnes désirant héberger des services chez eux.
Je ne pense pas que l'utilisateur lambda verra une différence, tout se passe sous le capot
Posté par chaispaquichui .
En réponse au message Switch + Routeur.
Évalué à 3.
Dernière modification le 10 décembre 2014 à 15:41.
Une solution crade serait aussi d'enfermer chaque machine dans son subnet en /30 : une IP pour la machine, une pour ton routeur (ton routeur aurait donc une IP spécifique par client).
Mais bon, c'est crade et les clients peuvent contourner cela en modifiant le masque… C'est quoi l’intérêt de vouloir faire transiter tout ton trafic par le routeur ? Tu vas juste créer un goulot d'étranglement dans ton réseau…
Il ne fonctionne pas parce que l'empaqueteur a décidé de ne pas l'activer par défaut sous Ubuntu… L'empaqueteur de frugalware est libre de livrer ufw avec la configuration par défaut de son choix.
Et pourquoi l'utiliser ? Simplement parce qu'il est syntaxiquement plus élégant et simple qu'iptables. Ce dernier reste très puissant car c'est un outil de bas niveau mais sur la majorité des machines, les opérations à effectuer sont tellement triviales (ouvrir un port ou un ensemble de port) qu'il convient amplement
Je n'ai pas regardé en profondeur mais j'ai l'impression qu'il y a beaucoup de services qui utilisent les .service de systemd et pas le mode de compatibilité. J'entends déjà les hurlements de joie de Kaane :)
[root@rhel-7-beta ~]# ifconfig
-bash: ifconfig: command not found
Les nostalgiques peuvent néanmoins retrouver cette commande dans le package net-tools
[root@rhel-7-beta ~]# yum search mariadb-server
Loaded plugins: product-id, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
========================================== N/S matched: mariadb-server ===========================================
mariadb-server.x86_64 : The MariaDB server and related files
J'avais quelques craintes au sujet de la nouvelle version d'anaconda qui avait fait parler d'elle (et pas en bien) mais au final, ça c'est bien passé. Je vais quand même voir ce que l'outil de partitionnement a dans le ventre.
Les options 'broadcast-address' et 'subnet-mask' décrivent le segment de
réseau auquel le serveur DHCP fournit des données.
Ce n'est pas très parlant je trouve… Ça envoie juste l'adresse de broadcast et de sous-réseau au client. Et de mémoire, ce n'est plus nécessaire depuis bien longtemps
C'est le protocole d'encapsulation qui va être utilisé par ton VPN. 99% du temps, il est conseillé d'utiliser UDP car c'est le protocole encapsulé qui va gérer tout ce qui est retransmission, gestion de congestion, etc. Si tu veux des détails techniques, tu peux consulter ce lien
En somme, il ne faut utiliser TCP que dans des cas très spécifiques (un FAI un peu frileux qui drop les trop gros flux UDP, une middle box qui gère mal le NAT, etc.).
Tu dois voir ta connexion OpenVPN comme ceci (toujours en se basant sur ma configuration, les machines linus sont représentées par des symboles de routeur)
C'est à dire un réseau point-to-point (lien direct) entre tes deux machines
Du point de vue de l'hôte local, tu dois avoir ceci comme configuration au niveau de tun0
En somme ton VPN boucle sur lui même, tu dois revoir sa configuration ;)
Pour ce qui est des routes, même chose, tu dois indiquer l'adresse distante comme passerelle (10.8.0.2 dans mon cas). Par exemple, si je souhaite joindre le réseau 192.168.42.0/24 qui se trouve derrière le serveur OpenVPN, je dois indiquer une route comme ceci :
ip route add 192.168.42.0/24 via 10.8.0.2
Note que l'on peut également approcher ton problème d'une autre manière que le PBR, si ton application ne contacte qu'un serveur spécifique (disons 192.168.5.1 pour l'exemple), tu peux rajouter une simple route comme ceci
ip route add 192.168.5.1/32 via 10.8.0.2
Note que le serveur OpenVPN peut pousser ce genre de routes sur le client de manière dynamique, ce qui est excessivement pratique. En revanche, cela ne rempli pas complètement l'objectif initial puisque tout le trafic à destination de 192.168.5.1 sera envoyé dans le VPN
Je n'ai pas trop le temps de mettre en place les machines pour tester mais j'ai remarqué quelque chose d'étrange sur ton interface tun0
inet adr:10.200.3.45 P-t-P:10.200.3.45
Il y a sans doute une erreur dans ta config d'OpenVPN (ce qui provoque le crash je pense), tu devrais voir l'adresse IP de l'autre machine OpenVPN et non pas de l'interface locale de ta machine. Ainsi, ta config devrait ressembler à ceci (avec ma config comme exemple)
ip route add default via 10.8.0.2 dev tun0 table vpn
Regarde les logs d'OpenVPN, généralement la cause du plantage est indiquée de manière relativement explicite. Enfin, un conseil, essaye de mettre en place l'environnement de routage avec le moins de règles iptables possibles. Valide la configuration de routage dans un environnement simple pour commencer, tu compliqueras les choses après ;)
Nop, la configuration ne survit pas à un reboot. OpenVPN permet de lancer des scripts lorsqu'il démarre/se coupe, regarde les options up/down du fichier de configuration ;)
Pourquoi le faire un script sur le client quand la conf serveur le fait très bien ?
Si ta conf coté serveur et bien fait , il t'envoie tout ce que tu a besoin et tu n'a rien a faire et ce peu importe le client.
Je ne suis absolument pas un expert en OpenVPN, est-ce qu'il est possible pour le serveur de pousser des règles iptables, d'instancier une nouvelle table de routage sur le client et d'appliquer une règle de routage ? Ça serait en effet bien plus souple.
Paramètre --route-noexec pour ignorer les routes envoyées par le serveur, exécution automatique d'un script qui effectue le PBR (voir mon premier message) au démarrage du client OpenVPN et le tour est joué ;)
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par chaispaquichui . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 10. Dernière modification le 24 février 2015 à 23:25.
Et à quel moment systemd va lui donner plus de boulot qu'avant ? Wep, il va devoir lire quelques pages de man et effectuer quelques tests, rien de nouveau pour un mec qui utilise Linux au quotidien.
Faut arrêter d'exagérer avec ça… A croire que les gens passent leur vie à interagir en permanence avec le système d'init… Je suis admin système et avant, c'était une véritable agonie d'écrire un script de démarrage correct pour un processus sous Linux… C'était pas élégant, bourré de race condition, pas compatible entre les distribution… Depuis systemd, j'ai échangé la commande service par systemctl, je peux écrire des units très facilement, exprimer des dépendances de manière élégante et copier/coller mes unités sans crainte de voir le processus se vautrer lamentablement. Que du bénéfice en somme.
Alors oui, moi aussi parfois je soulève un sourcil quand je vois la dernière nouveauté intégrée dans systemd. Puis je me souviens que je ne suis pas seul au monde, que les gens ont des besoins différents et que systemd essaye d'y répondre…
[^] # Re: Moins de liberté, pour plus de sécurité
Posté par chaispaquichui . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 10.
Le premier Calimero est arrivé rapidement :)
C'est pitoyable de balancer des tirades sur la liberté alors que ce que tu veux réellement, c'est empêcher les autres d'utiliser un projet que tu n'aimes pas.
Tu n'aimes pas systemd ? Va argumenter avec les développeurs et les mainteneurs qui décident de l'utiliser (tu sais, les mecs qui créent des logiciels que tu aimes bien utiliser gratuitement). Au pire, contribue, fork ou change de distro.
C'est le monde du libre, t'es libre de ne pas aimer et de changer.
[^] # Re: Pas compris le problème :p
Posté par chaispaquichui . En réponse au message Utilisation d'OVS et de quagga. Évalué à 1.
Pas par défaut
[root@arch2 ~]# ovs-vsctl add-br ovs1
[root@arch2 ~]# ovs-vsctl add-br ovs2
[root@arch2 ~]# ovs-vsctl list-ports ovs1
[root@arch2 ~]#
[root@arch2 ~]# ovs-vsctl list-ports ovs2
[root@arch2 ~]#
Il faut rajouter des interfaces manuellement
[root@arch2 ~]# ip tuntap add mode tap dev tap2
[root@arch2 ~]# ovs-vsctl add-port ovs1 tap2
[root@arch2 ~]# ovs-vsctl list-ports ovs1
tap2
Tu as peut-être un reste de configuration dans lequel tu aurais ajouté ton interface physique par accident… En présumant que le nom de ton interface physique est eth0, essaye ceci :
[root@arch2 ~]# ovs-vsctl del-port ovs1 eth0
[root@arch2 ~]# ovs-vsctl del-port ovs2 eth0
# Pas compris le problème :p
Posté par chaispaquichui . En réponse au message Utilisation d'OVS et de quagga. Évalué à 1. Dernière modification le 20 février 2015 à 11:51.
ovs-vsctl add-br ovs1
ovs-vsctl add-br ovs2
Tu peux plugger à chaud une VM sur un switch existant, ça lui rajoutera des ports virtuels à la volée. Libvirt est capable de le faire sans soucis. Tu dois créer un "réseau virtuel" par switch et attacher tes VM à ces réseaux (soit lors de l'installation, soit plus tard en éditant les paramètres de la machine)
https://libvirt.org/formatnetwork.html
Note que tu peux utiliser un seul switch virtuel et utiliser les VLAN pour créer ta topologie :)
[^] # Re: Profitons de l'occasion :)
Posté par chaispaquichui . En réponse au journal IPv6 dépasse les 5% chez les utilisateurs de Google. Évalué à 2.
Je sais bien que les administrateurs auront tendance à donner des adresses « prédictibles » à leurs serveurs mais il faut penser un peu au-delà de sa bulle et imaginer tous les cas dans lesquels IPv6 sera utilisé. Typiquement dans un réseau LAN domestique où l’auto configuration sera utilisée pour générer des IPv6 à rallonge imprédictibles.
Le pire étant que certains routeurs CPE n’implémentent pas du tout de firewall IPv6
https://pay.reddit.com/r/sysadmin/comments/2cj0lj/my_synology_nas_has_been_hacked_by_ransomware/cjga90t
Ou implémentent un mauvais firewall. Par exemple, chez l’opérateur Voo en Belgique, le routeur offre un firewall « activé ou désactivé ». Il est impossible d’ouvrir un port spécifique.
Et c’est une bonne nouvelle. Mais même sur ces OS « mainstream », il existe des divergences (voir le document) quant à la manière de lire les flags des RA et cela oblige l’administrateur à configurer le système pour maximiser la prédictibilité (rien que pour désactiver les privacy extensions par exemple). Et encore, tu as la chance de ne travailler qu’avec des OS dont le stack IPv6 est relativement bien testé. Je travaille dans des hôpitaux et je dois gérer un parc hétéroclite au possible (des AS400, des lecteurs bancontact, des respirateurs, des frigos, etc.) et je te prie de croire que c’est déjà relativement folklorique en IPv4…
Tout à fait. IPv4 s’est complexifié à cause de ces rustines. Mais s’imaginer qu’IPv6 est plus simple car « c’est comme IPv4 mais sans le PAT/CGN », c’est une erreur. Il ne suffit pas de cocher la case « Activer IPv6 » et d’aller boire un café en oubliant l’existence de ce protocole. IPv6 est une nécessité technique pour conserver un internet ouvert et c’est pour cela qu’il faut que les gens aient conscience que tout n’est pas rose. Le pire qu’il puisse y avoir, c’est que les gens déploient IPv6 dans leurs réseaux sans avoir conscience de tous ces paramètres, se prennent un retour de flammes et gardent une mauvaise image du protocole…
[^] # Re: Profitons de l'occasion :)
Posté par chaispaquichui . En réponse au journal IPv6 dépasse les 5% chez les utilisateurs de Google. Évalué à 3.
Je n'ai malheureusement pas eu le temps d'éditer mon message mais il faut aussi mentionner le fait que l'adressage local d'un réseau devient complètement dépendant du préfixe distribué par le FAI. Si on change de FAI, on doit changer la totalité de l'adressage interne… C'est relativement acceptable dans un LAN domestique mais dans une entreprise possédant plusieurs centaines/millers de machines, c'est se tirer une balle dans le pied… Pour régler cette problématique, on est en train de combiner les adresses IPv6 ULA avec un nouveau type de NAT : "IPv6 Network Prefix Translation".
Plus d'informations dans la RFC suivante : https://tools.ietf.org/html/rfc6296
[^] # Re: Profitons de l'occasion :)
Posté par chaispaquichui . En réponse au journal IPv6 dépasse les 5% chez les utilisateurs de Google. Évalué à 3. Dernière modification le 01 janvier 2015 à 13:07.
Il faudra toujours un firewall dans le réseau. La grandeur de l'espace IPv6 va juste forcer les pirates à devenir imaginatifs pour trouver les hôtes.
Le sujet a été abordé dans cette RFC : http://www.ietf.org/rfc/rfc5157.txt
Pour en revenir à la simplicité de gestion, on peut également aborder le problème de la distribution des adresses IPv6 aux hôtes. En IPv4, on connait deux méthodes principales : l'adressage statique et dynamique via DHCP. L’auto-configuration est quasiment inutilisée. En revanche, en IPv6, les choses sont complètements différentes : le DHPv6 ne distribue pas de routes et est fortement dépendant des RA envoyés par les routeurs. On ajoute à cela que chaque OS réagit de manière différente aux flags des RA et on se retrouve vite avec une grosse mélasse sur les bras
Le document suivant rapporte les résultats de tests d’acquisitions d'adresses avec différents OS :
https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-02
Quand à ce document, il donne quelques recommandations pour la gestion des IPv6 en entreprise :
https://tools.ietf.org/html/draft-liu-v6ops-dhcpv6-slaac-guidance-03
Donc non, tout n'est pas aussi simple qu'on aimerait le croire :(
[^] # Re: Profitons de l'occasion :)
Posté par chaispaquichui . En réponse au journal IPv6 dépasse les 5% chez les utilisateurs de Google. Évalué à 10.
Les OS modernes implémentent la RFC 4941 qui permet de générer des adresses aléatoires et temporaires. Cet argument ne tient pas la route… IPv6 ne protège pas mieux ou moins bien qu'IPv4
[^] # Re: Profitons de l'occasion :)
Posté par chaispaquichui . En réponse au journal IPv6 dépasse les 5% chez les utilisateurs de Google. Évalué à 9. Dernière modification le 29 décembre 2014 à 16:50.
Si tu n'as pas besoin d'effectuer de manipulations dans ton routeur pour avoir accès à ton LAN depuis l'extérieur en IPv6, c'est qu'il n'y a pas de firewall dans ton routeur et que tu es cul nul face à internet.
Un conseil, change de FAI ou de routeur :)
[^] # Re: Profitons de l'occasion :)
Posté par chaispaquichui . En réponse au journal IPv6 dépasse les 5% chez les utilisateurs de Google. Évalué à 5.
Plus de sécurité ?
Non :(
Moins de Gestion ?
Non :(
Pour épater les copines ?
Si elles sont fortement geeks, éventuellement :)
L'IPv6 est là pour palier à la pénurie d'adresse IPv4 qui oblige l'utilisation de rustines comme PAT et CGN qui sont des plaies pour les administrateurs réseaux et les personnes désirant héberger des services chez eux.
Je ne pense pas que l'utilisateur lambda verra une différence, tout se passe sous le capot
# Sérieusement....
Posté par chaispaquichui . En réponse au journal Microsoft IIS ne dépasse pas Apache et il est encore en train de se prendre une taule. Évalué à 3.
Quelqu'un s'en soucie réellement ?
[^] # Re: VLAN + 802.1Q
Posté par chaispaquichui . En réponse au message Switch + Routeur. Évalué à 3. Dernière modification le 10 décembre 2014 à 15:41.
Une solution crade serait aussi d'enfermer chaque machine dans son subnet en /30 : une IP pour la machine, une pour ton routeur (ton routeur aurait donc une IP spécifique par client).
Mais bon, c'est crade et les clients peuvent contourner cela en modifiant le masque… C'est quoi l’intérêt de vouloir faire transiter tout ton trafic par le routeur ? Tu vas juste créer un goulot d'étranglement dans ton réseau…
# Ipv6...
Posté par chaispaquichui . En réponse à la dépêche OpenBSD 5.6. Évalué à -1.
"IPv6 est désormais désactivé par défaut sur les interfaces. Il s'active lors de l'ajout d'une adresse IPv6 sur celles-ci."
Et ben… Heureusement qu'il s'agit d'un OS orienté réseau…
"Il n'est plus possible d'installer OpenBSD via un FTP ou des cartouches."
J'ai du aller voir dans la release notes pour comprendre ce qu'était une "cartouche". Un peu ironique non ?
[^] # Re: Bienvenue en 1995 !
Posté par chaispaquichui . En réponse au journal Frugalware: Configuration du parefeu . Évalué à 1.
Il ne fonctionne pas parce que l'empaqueteur a décidé de ne pas l'activer par défaut sous Ubuntu… L'empaqueteur de frugalware est libre de livrer ufw avec la configuration par défaut de son choix.
Et pourquoi l'utiliser ? Simplement parce qu'il est syntaxiquement plus élégant et simple qu'iptables. Ce dernier reste très puissant car c'est un outil de bas niveau mais sur la majorité des machines, les opérations à effectuer sont tellement triviales (ouvrir un port ou un ensemble de port) qu'il convient amplement
# Dépôt HS
Posté par chaispaquichui . En réponse à la dépêche FusionDirectory 1.0.8.1 est sorti !. Évalué à 3. Dernière modification le 11 septembre 2014 à 22:10.
J'ai vraiment envie d'essayer la solution mais le dépôt pour centos semble HS
Le lien donné dans la doc
http://repos.fusiondirectory.org/rhel/6/noarch
me renvoie une erreur 404 :(
*edit : je n'avais pas vu les liens dans la news… Mais il faudra penser à mettre à jour la documentation ;)
[^] # Re: Paquets
Posté par chaispaquichui . En réponse au journal Le serveur DNS Knot. Évalué à -5. Dernière modification le 05 janvier 2014 à 09:40.
Quel dommage, pas de patch made-in-debian pour créer des failles de sécurité :)
*edit : ceci est un troll assumé
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par chaispaquichui . En réponse au journal RHEL 7 pourrait utiliser XFS par défaut. Évalué à 1.
Oui, le paquet yum dépose le script "yum-cron" dans l'init qui contrôle si le script "0yum-daily.cron" doit s'exécuter ou non
[^] # Re: pendant ce temps la, sur ftp.redhat.com
Posté par chaispaquichui . En réponse au journal RHEL 7 pourrait utiliser XFS par défaut. Évalué à 2.
Et pour répondre à ces insoutenables questions :)
Je n'ai pas regardé en profondeur mais j'ai l'impression qu'il y a beaucoup de services qui utilisent les .service de systemd et pas le mode de compatibilité. J'entends déjà les hurlements de joie de Kaane :)
Les nostalgiques peuvent néanmoins retrouver cette commande dans le package net-tools
J'avais quelques craintes au sujet de la nouvelle version d'anaconda qui avait fait parler d'elle (et pas en bien) mais au final, ça c'est bien passé. Je vais quand même voir ce que l'outil de partitionnement a dans le ventre.
[^] # Re: Un petit HOWTO sur la question
Posté par chaispaquichui . En réponse à la dépêche Atelier Serveur DHCP sous GNU/Linux le 15 novembre 2013 à Puteaux. Évalué à 2.
Ce n'est pas très parlant je trouve… Ça envoie juste l'adresse de broadcast et de sous-réseau au client. Et de mémoire, ce n'est plus nécessaire depuis bien longtemps
[^] # Re: Prout
Posté par chaispaquichui . En réponse au message OpenVPN + iptables. Évalué à 1.
C'est le protocole d'encapsulation qui va être utilisé par ton VPN. 99% du temps, il est conseillé d'utiliser UDP car c'est le protocole encapsulé qui va gérer tout ce qui est retransmission, gestion de congestion, etc. Si tu veux des détails techniques, tu peux consulter ce lien
http://www.ispl.jp/~oosaki/papers/Honda05_ITCom.pdf
Si tu veux des explications un peu moins lourdes, tu peux suivre ces liens
http://sites.inka.de/~W1011/devel/tcp-tcp.html
https://news.ycombinator.com/item?id=2409090
En somme, il ne faut utiliser TCP que dans des cas très spécifiques (un FAI un peu frileux qui drop les trop gros flux UDP, une middle box qui gère mal le NAT, etc.).
[^] # Re: Prout
Posté par chaispaquichui . En réponse au message OpenVPN + iptables. Évalué à 3.
Tu dois voir ta connexion OpenVPN comme ceci (toujours en se basant sur ma configuration, les machines linus sont représentées par des symboles de routeur)
C'est à dire un réseau point-to-point (lien direct) entre tes deux machines
Du point de vue de l'hôte local, tu dois avoir ceci comme configuration au niveau de tun0
Remarque bien qu'en P-t-P, tu as l'adresse du serveur. Dans la configuration que tu exposes, tu as deux fois la même adresse
En somme ton VPN boucle sur lui même, tu dois revoir sa configuration ;)
Pour ce qui est des routes, même chose, tu dois indiquer l'adresse distante comme passerelle (10.8.0.2 dans mon cas). Par exemple, si je souhaite joindre le réseau 192.168.42.0/24 qui se trouve derrière le serveur OpenVPN, je dois indiquer une route comme ceci :
Note que l'on peut également approcher ton problème d'une autre manière que le PBR, si ton application ne contacte qu'un serveur spécifique (disons 192.168.5.1 pour l'exemple), tu peux rajouter une simple route comme ceci
Note que le serveur OpenVPN peut pousser ce genre de routes sur le client de manière dynamique, ce qui est excessivement pratique. En revanche, cela ne rempli pas complètement l'objectif initial puisque tout le trafic à destination de 192.168.5.1 sera envoyé dans le VPN
# Adresse Ip
Posté par chaispaquichui . En réponse au message OpenVPN + iptables. Évalué à 1. Dernière modification le 20 juin 2013 à 22:16.
Je n'ai pas trop le temps de mettre en place les machines pour tester mais j'ai remarqué quelque chose d'étrange sur ton interface tun0
inet adr:10.200.3.45 P-t-P:10.200.3.45
Il y a sans doute une erreur dans ta config d'OpenVPN (ce qui provoque le crash je pense), tu devrais voir l'adresse IP de l'autre machine OpenVPN et non pas de l'interface locale de ta machine. Ainsi, ta config devrait ressembler à ceci (avec ma config comme exemple)
inet adr:10.8.0.1 P-t-P:10.8.0.2 Masque:255.255.255.255
et la route qui va bien
ip route add default via 10.8.0.2 dev tun0 table vpn
Regarde les logs d'OpenVPN, généralement la cause du plantage est indiquée de manière relativement explicite. Enfin, un conseil, essaye de mettre en place l'environnement de routage avec le moins de règles iptables possibles. Valide la configuration de routage dans un environnement simple pour commencer, tu compliqueras les choses après ;)
[^] # Re: Merci pour toutes vos réponses
Posté par chaispaquichui . En réponse au message N'utiliser un vpn que pour une application. Évalué à 1.
Nop, la configuration ne survit pas à un reboot. OpenVPN permet de lancer des scripts lorsqu'il démarre/se coupe, regarde les options up/down du fichier de configuration ;)
https://help.ubuntu.com/community/OpenVPN
Un exemple est donné dans "Configuring the Server"
[^] # Re: vpn, et table de routage
Posté par chaispaquichui . En réponse au message N'utiliser un vpn que pour une application. Évalué à 0.
Je ne suis absolument pas un expert en OpenVPN, est-ce qu'il est possible pour le serveur de pousser des règles iptables, d'instancier une nouvelle table de routage sur le client et d'appliquer une règle de routage ? Ça serait en effet bien plus souple.
[^] # Re: vpn, et table de routage
Posté par chaispaquichui . En réponse au message N'utiliser un vpn que pour une application. Évalué à 0. Dernière modification le 19 juin 2013 à 16:33.
Paramètre --route-noexec pour ignorer les routes envoyées par le serveur, exécution automatique d'un script qui effectue le PBR (voir mon premier message) au démarrage du client OpenVPN et le tour est joué ;)