D'après ce que je comprends de Nosql, la cohérence est de type 'eventually consistency' pas stricte. C'est un peu gonflé de mettre ça comme choix numéro 1.
On s'étonne que le client n'ai pas envie de prendre la qualité inférieure
Je pense que la plupart des client visés ne savent même pas qu'un MP3 est de moins bonne qualité qu'un CD. Et qu'a 292kbps écoutés avec un casque pas génial dans le métro, il ne s'en rendent pas compte.
Le NAT est une vrai daube pour les protocole un peu complexe comme le H323 ou le SIP.
C'est clair, mais il faudrait peut-être aussi s'en prendre à ceux qui ont rédigés ces protocoles qui ne prennent pas en compte les connexions NATés, alors qu'elles sont nombreuses.
A moins qu'ils ne les ait fait ainsi pour permettre aux sociétés de sécurité de vendre de nouveaux produit qui savent remonter au niveau 7 ?
Mme Michu est au contraire beaucoup plus utilisatrice d'applications tierces que le geek
Super. En ce qui me concerne madame Michu (tm) (r) (c) elle fait du web, du mail et de l'office. Mme Michu est au contraire beaucoup moins utilisatrice d'applications tierces que le geek.
tu n'y comprends rien, tellement tu es arcbouté sur tout fermer.
Question de point de vue, du miens c'est toi qui ne comprends rien.
Du coup, cela ne m'intéresse même plus de débattre avec toi.
Effectivement je préfére aussi arreter de débattre avec quelqu'un qui ne sais pas regarder depuis la fenetre des autres.
> Qu'est ce qui garanti que seules des personnes autorisées à accéder au réseau de la
> boite ont accès à ton serveur externe, et donc au tunnel ?
Auncun
OK, comprends donc que la boite en face ne veuille pas forcement déporter sa sécurité. Après si le contrat est mal fait, ou qu'ils ne veulent pas payer plus cher pour faire quelque chose de propre, ce n'est pas la faute de la sécurité. Tu as tees objectifs, ils ont les leurs.
Chez moi, une machine a toujours la même IP.
C'est ton choix, ce n'est pas celui de la majorité des grandes entreprises pour des raisons evidente de flexibilité. Un utilisateur non admin aura du mal à spoofer.
Parce que les DSI sont coincés pour ouvrir un port en sortie vers une SEULE ip fixe
Une seule IP ? Je vais finir par croire que tu bosse dans une boite de 10 personnes !
Toi, tu es dans ta tour d'ivoire... Tu as l'impression de ne pas avoir pris de risque mais tu m'as tout reporté sur moi pour que notre contrat de collaboration marche
Vilain procès d'intention, j'essaye juste d'expliquer le point de vue du bord opposé au tiens. Dans les fait, oui, le risque pris par ma boite est plus limité qu'avec un tunnel ssh accessible potentielement au monde entier si ton réseau n'est pas sécurisé. Mission accomplie, par ici les pepettes.
tu acceptes du SSH sur HTTP...
j'accepte http, pas ssh et ses port forwarding/reverse tunneling
Combien de gens dans ta boite commence a utiliser leur iphone ou équivalent dans le cadre du boulot ? Maîtrise-tu ce nouveau réseau ?
Ca c'est un vrai enjeu d'avenir, mais certaines boites interdisent tout simplement la connexion usb de ce genre d'appareil su un poste d'entreprise.
C'est la réponse classique des DSI quand je dis cela !
Je suis prêt à devenir un deçaïdeur praissé \o/
Pour ce problème, il aurait du autoriser la machine interne X a venir faire du SSH sur mon serveur Y.
Qu'est ce qui garanti que seules des personnes autorisées à accéder au réseau de la boite ont accès à ton serveur externe, et donc au tunnel ?
Ouvrir vers un nombre finie et limité de machine en sortie quelques protocoles non HTTP, ce n'est pas la mort
Dans les faits, si c'est un peu la mort :) il faut réserver des IP fixes en pagaille (sauf à utiliser un firewall authentifiant), être sur d'être prévenu quand l'accès n'est plus nécessaire, être réactif parce que 'l'ip fixe de mon serveur perso chez moi à changé, vous pouvez mettre à jour les règles c'est méga urgent', ou encore parce que 'on m'a changé ma machine, vous pouvez remettre mes droit sur le firewall, c'est méga urgent (toujours)' ?
L'équipe en charge de l'infra à souvent d'autres chats à fouetter que de gérer ces accès qui découlent le plus souvent d'une organisation a l'arrache et pour lesquelles elle se fera taper sur les doigts en cas de problème. oui, je m'ennerve là :)
A ces gens là je dis, attention à la 3G, vous allez vous amuser avec les ponts ;-)
C'est pas nouveau, on peut faire des ponts avec le wifi aussi. Il suffit de les bloquer sur le poste de travail lorsqu'il est connecté au réseau filaire, ou les interdire complétement ,suivant ce que l'on veut.
à part une analyse statistique de l'utilisation de la bp je vois pas
Par exemple, par défaut, la première réponse d'un serveur ssh c'est la banniere de version, qui se detecte facilement (et qui se change aussi facilement, mais ce n'est q'un exemple). Ensuite oui, certaines boites font de l'interception ssl systématique sur leurs proxy (sauf sur les sites pour lequel c'est interdit, tels que les banques).
rien ne m'empêche sur un serveur externe que je contrôle de mettre un service sur le port 80 qui répond à un bête client qui fait du http pour lui faire exécuter des commandes en interne.
Il y aura toujours un moyen, plus ou moins évident selon l'architecture en place. Le but est déjà d'éviter les plus triviaux.
elles ne servent à rien pour une personne déterminée à donner un accès vers l'intérieur
La sécurité totale n'existe pas (même chez OpenBSD :) , mais la personne en question risque de ce casser les dents sur les premières barrières en place, ce qui permettra de le detecter et de gentiment aller lui expliquer ce qu'il n'est pas sensé faire.
Le problème en soi n'est même pas le reverse tunnel, c'est le fait de ne plus contrôller le périmétre : qu'est ce qu'on sait de la sécurité du serveur qui monte le reverse ? Peut-être qu'il est cracké et que, sans le savoir, celui qui monte ce tunnel et qui est plein de bonnes intentions donne au passage accès au réseau de l'entreprise à un vil pirate qui n'en demande pas tant...
Pour ça faut être en interne.
J'ai peut-être mal compris, mais il me semble qu'on parle d'accés ssh en sortie, donc depuis l'interne ?
corkscrew + accès vers un serveur ssh externe sur le port 443
Il y a des moyens pour détecter et interdire ça. J'ai déjà vu des gens renvoyés pour ça...
Là ou je veux en venir, c'est que ça ne sécurise rien du tout.
OK, on a qu'a laisser les machines en direct faire ce quelles veulent sur internet, c'est sur que ça fera avancer la sécurité. On ne peut pas tout bloquer, ça ne veut pas dire qu'il ne faut rien bloquer.
Avez-vous plus confiance dans le couple Apache+AjaxTerm qu'en OpenSSH ?
Le problème avec Openssh est qu'il permet trop facilement de faire du reverse tunnelling, et donc de permettre un accès entrant directement sur le réseau de l'entreprise. Certe on peut faire la même chose sur du http, mais ca se detecte , et ce n'est pas parce que qu'on ne peut pas arrêter la peste qu'on ne doit rien faire contre le choléra...
Quant à n'autoriser que http en sortie, c'est aussi parce que c'est le protocol pour lequel on trouve le plus facilement des proxy avec des fonctions 'avancés' intégrées (filtrage d'url, support d'icap, interception ssl...).
Check poste ? càd ?
Vérification de conformité, par exemple s'assurer de la présence d'un antivirus à jour avant d'autoriser la connexion. Tout ce qui se cache derrière le beau terme marketting " NAC"
Je suis pas un spécialiste Checkpoint, mais ça se vend pas que sur des plateformes Nokia, ils le vendent même à installer sur un Windows
Tout à fait, sur linux et solaris aussi, mais restons sérieux...
Effectivement, avec de l'OpenVPN par exemple c'est un process par CPU, donc à moins de monter plusieurs VPN et faire du round robin avec relayd, c'est pas out of the box (bien que faire du round robin avec relayd ça soit pas vraiment dur ...)
Sinon y'a du support de cryptodev pour Via padlock (avec OpenSSL sous OpenBSD j'ai déjà essayé avec des débits à 300Mbits/s, mais j'ai un doute, je sais plus si c'était avec AES128 ou AES256 ou les deux)
Ok, je ne connais pas, merci pour l'info. 300Mbps en vpn c'est bien, mais la plus petite des IP appliance checkpoint est annoncé au double, faudrait comparer en conditions réelles.
Malheureusement je doute fortement que ça marche en ayant les machines comme endpoint IPSec ou OpenVPN (ou alors il faut sérieusement bidouiller)
Ca de toute façon, ça marche toujours très bien sur le papier chez plein de constructeurs...
ais que tu cites les reproches (les inconvénients) faits aux solutions propriétaires pour expliquer qu'elles ne correspondent pas aux besoins auxquels elles répondent.
En fait je suis persuadé qu'il y a un marché pour checkpoint autant que pour PF, tout dépends justement du besoin. C'est pour ça que je demande des infos sur la partie performance, n'ayant jamais migré de l'un à l'autre. Mais l'auteur du journal préfére pointer ma confusion Freebsd/openbsd plutôt que d'essayer de répondre.
Tu sous-entends que des gens ont besoin:
- de payer des licences,
- de se faire chier à désactiver des trucs qui les emmerdent et qu'ils ont payé?
Plus précisement, je dis que si tu achétes quelque chose dont tu n'as pas besoin et que tu est obligé de te taper une migration après, apprends à faire une étude.
Mais c'est parce que j'ai aussi mis PF dans la phrase : Firewall, FreeBSD et PF
Décidement...
Si t'as pas envie de lire le journal, t'es pas obligé de poser des questions.
Si tu veux écrire un journal pour dire que tu ne sais pas utiliser checkpoint, que tu préfére freebsd et que tu ne veux pas répondre à des questions, fais un blog.
Au temps pour moi, je pense à PF dès que je vois firewall et bsd dans la même phrase. Mais la question reste valable : Splat supporte le multicoeur, les cartes accélératrice et le mode actif/actif depuis longtemps. Qu'en est-il sous freebsd ?
Le client VPN fourni pas Checkpoint ne fonctionne pas sur les version 64 bits de Vista
Pourtant il est vendu pour : http://www.checkpoint.com/products/endpoint_connect/index.ht(...)
Bon j'ai pas testé, mais tu as quoi comme alternative pour faire un check du poste et un déploiement de règles locales a la connexion ?
Basé sur du Linux, mais suffisamment différent pour ne pas être utilisable comme un Linux
Si tu parles bien d'ipso, c'est basé sur du bsd à l'origine. Et il existe Gnukia pour retrouver un peu du confort Gnu sous ipso
Avoir deux IP sur la même carte réseau étant possible moyennant quelques bidouilles dans des fichiers de configuration non documentés.
Jamais essayé, mais dans quel but ? Ipso supportte très bien les interfaces vlans
Des licences à payer Des options de sécurités top-cool qu'on passait notre temps à chercher puis désactiver
Bref, ça ne correspond pas à ton besoin.
Concernant les perf, il y a des cartes accélératrices qui fonctionnent correctement sous openbsd ? Déjà qu'il ne sait apparement pas utiliser plusieurs core d'après http://www.openbsd.org/faq/pf/fr/perf.html ...
[^] # Re: Théorème CAP
Posté par Volnai . En réponse à la dépêche MongoDB 1.4, prêt pour la production. Évalué à 2.
D'après ce que je comprends de Nosql, la cohérence est de type 'eventually consistency' pas stricte. C'est un peu gonflé de mettre ça comme choix numéro 1.
[^] # Re: Théorème CAP
Posté par Volnai . En réponse à la dépêche MongoDB 1.4, prêt pour la production. Évalué à 3.
No set of failures less than total network failure is allowed to cause the system to respond incorrectly ( http://www.julianbrowne.com/article/viewer/brewers-cap-theor(...) )
On peut faire ça avec les RDBMS classiques il me semble, non ?
[^] # Re: Pour vendre
Posté par Volnai . En réponse au journal "On nous a demandé avec beaucoup d'insistance de voter Hadopi". Évalué à 2.
Je pense que la plupart des client visés ne savent même pas qu'un MP3 est de moins bonne qualité qu'un CD. Et qu'a 292kbps écoutés avec un casque pas génial dans le métro, il ne s'en rendent pas compte.
[^] # Re: Incontournable
Posté par Volnai . En réponse à la dépêche OpenSSH v5.4 : Certificat et Révocation. Évalué à 2.
[^] # Re: Incontournable
Posté par Volnai . En réponse à la dépêche OpenSSH v5.4 : Certificat et Révocation. Évalué à 1.
C'est clair, mais il faudrait peut-être aussi s'en prendre à ceux qui ont rédigés ces protocoles qui ne prennent pas en compte les connexions NATés, alors qu'elles sont nombreuses.
A moins qu'ils ne les ait fait ainsi pour permettre aux sociétés de sécurité de vendre de nouveaux produit qui savent remonter au niveau 7 ?
[^] # Re: problème chez Free, ou chez Algérie-Télécom/Anis ?
Posté par Volnai . En réponse au journal Free ! j'ai rien compris !. Évalué à 1.
Il doit t'en manquer, ici j'ai une centaine de prefixes annoncés par 33774, et quelques un ne passent pas par 5511.
[^] # Re: Déjà là !
Posté par Volnai . En réponse au journal Le 26 Janvier prochain. Évalué à 2.
[^] # Re: Utilisation abusive de tes votes
Posté par Volnai . En réponse au journal Consommation de ressources de Windows et Debian. Évalué à 3.
Depuis quelques temps, vu les conneries qu'on peut lire (comme ce journal), je me dit qu'il pourrait tenir pas mal de temps en fait.
[^] # Re: Pas un problème
Posté par Volnai . En réponse au journal MALWARE LINUX. Évalué à 4.
Super. En ce qui me concerne madame Michu (tm) (r) (c) elle fait du web, du mail et de l'office. Mme Michu est au contraire beaucoup moins utilisatrice d'applications tierces que le geek.
facile non ?
# ...
Posté par Volnai . En réponse au journal Sozi : vers un système de présentation alternatif libre. Évalué à 3.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Volnai . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à -1.
Question de point de vue, du miens c'est toi qui ne comprends rien.
Du coup, cela ne m'intéresse même plus de débattre avec toi.
Effectivement je préfére aussi arreter de débattre avec quelqu'un qui ne sais pas regarder depuis la fenetre des autres.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Volnai . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 0.
> boite ont accès à ton serveur externe, et donc au tunnel ?
Auncun
OK, comprends donc que la boite en face ne veuille pas forcement déporter sa sécurité. Après si le contrat est mal fait, ou qu'ils ne veulent pas payer plus cher pour faire quelque chose de propre, ce n'est pas la faute de la sécurité. Tu as tees objectifs, ils ont les leurs.
Chez moi, une machine a toujours la même IP.
C'est ton choix, ce n'est pas celui de la majorité des grandes entreprises pour des raisons evidente de flexibilité. Un utilisateur non admin aura du mal à spoofer.
Parce que les DSI sont coincés pour ouvrir un port en sortie vers une SEULE ip fixe
Une seule IP ? Je vais finir par croire que tu bosse dans une boite de 10 personnes !
Toi, tu es dans ta tour d'ivoire... Tu as l'impression de ne pas avoir pris de risque mais tu m'as tout reporté sur moi pour que notre contrat de collaboration marche
Vilain procès d'intention, j'essaye juste d'expliquer le point de vue du bord opposé au tiens. Dans les fait, oui, le risque pris par ma boite est plus limité qu'avec un tunnel ssh accessible potentielement au monde entier si ton réseau n'est pas sécurisé. Mission accomplie, par ici les pepettes.
tu acceptes du SSH sur HTTP...
j'accepte http, pas ssh et ses port forwarding/reverse tunneling
Combien de gens dans ta boite commence a utiliser leur iphone ou équivalent dans le cadre du boulot ? Maîtrise-tu ce nouveau réseau ?
Ca c'est un vrai enjeu d'avenir, mais certaines boites interdisent tout simplement la connexion usb de ce genre d'appareil su un poste d'entreprise.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Volnai . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 1.
Je suis prêt à devenir un deçaïdeur praissé \o/
Pour ce problème, il aurait du autoriser la machine interne X a venir faire du SSH sur mon serveur Y.
Qu'est ce qui garanti que seules des personnes autorisées à accéder au réseau de la boite ont accès à ton serveur externe, et donc au tunnel ?
Ouvrir vers un nombre finie et limité de machine en sortie quelques protocoles non HTTP, ce n'est pas la mort
Dans les faits, si c'est un peu la mort :) il faut réserver des IP fixes en pagaille (sauf à utiliser un firewall authentifiant), être sur d'être prévenu quand l'accès n'est plus nécessaire, être réactif parce que 'l'ip fixe de mon serveur perso chez moi à changé, vous pouvez mettre à jour les règles c'est méga urgent', ou encore parce que 'on m'a changé ma machine, vous pouvez remettre mes droit sur le firewall, c'est méga urgent (toujours)' ?
L'équipe en charge de l'infra à souvent d'autres chats à fouetter que de gérer ces accès qui découlent le plus souvent d'une organisation a l'arrache et pour lesquelles elle se fera taper sur les doigts en cas de problème. oui, je m'ennerve là :)
A ces gens là je dis, attention à la 3G, vous allez vous amuser avec les ponts ;-)
C'est pas nouveau, on peut faire des ponts avec le wifi aussi. Il suffit de les bloquer sur le poste de travail lorsqu'il est connecté au réseau filaire, ou les interdire complétement ,suivant ce que l'on veut.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Volnai . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 1.
Par exemple, par défaut, la première réponse d'un serveur ssh c'est la banniere de version, qui se detecte facilement (et qui se change aussi facilement, mais ce n'est q'un exemple). Ensuite oui, certaines boites font de l'interception ssl systématique sur leurs proxy (sauf sur les sites pour lequel c'est interdit, tels que les banques).
rien ne m'empêche sur un serveur externe que je contrôle de mettre un service sur le port 80 qui répond à un bête client qui fait du http pour lui faire exécuter des commandes en interne.
Il y aura toujours un moyen, plus ou moins évident selon l'architecture en place. Le but est déjà d'éviter les plus triviaux.
elles ne servent à rien pour une personne déterminée à donner un accès vers l'intérieur
La sécurité totale n'existe pas (même chez OpenBSD :) , mais la personne en question risque de ce casser les dents sur les premières barrières en place, ce qui permettra de le detecter et de gentiment aller lui expliquer ce qu'il n'est pas sensé faire.
Le problème en soi n'est même pas le reverse tunnel, c'est le fait de ne plus contrôller le périmétre : qu'est ce qu'on sait de la sécurité du serveur qui monte le reverse ? Peut-être qu'il est cracké et que, sans le savoir, celui qui monte ce tunnel et qui est plein de bonnes intentions donne au passage accès au réseau de l'entreprise à un vil pirate qui n'en demande pas tant...
[^] # Re: Touche pas à (mon) grisbi !
Posté par Volnai . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à 0.
J'ai peut-être mal compris, mais il me semble qu'on parle d'accés ssh en sortie, donc depuis l'interne ?
corkscrew + accès vers un serveur ssh externe sur le port 443
Il y a des moyens pour détecter et interdire ça. J'ai déjà vu des gens renvoyés pour ça...
Là ou je veux en venir, c'est que ça ne sécurise rien du tout.
OK, on a qu'a laisser les machines en direct faire ce quelles veulent sur internet, c'est sur que ça fera avancer la sécurité. On ne peut pas tout bloquer, ça ne veut pas dire qu'il ne faut rien bloquer.
[^] # Re: Touche pas à (mon) grisbi !
Posté par Volnai . En réponse au journal Avec SPDY, Google souhaite accélérer remplacer/accélérer HTTP. Évalué à -1.
Le problème avec Openssh est qu'il permet trop facilement de faire du reverse tunnelling, et donc de permettre un accès entrant directement sur le réseau de l'entreprise. Certe on peut faire la même chose sur du http, mais ca se detecte , et ce n'est pas parce que qu'on ne peut pas arrêter la peste qu'on ne doit rien faire contre le choléra...
Quant à n'autoriser que http en sortie, c'est aussi parce que c'est le protocol pour lequel on trouve le plus facilement des proxy avec des fonctions 'avancés' intégrées (filtrage d'url, support d'icap, interception ssl...).
[^] # Re: Tout dépend du besoin...
Posté par Volnai . En réponse au journal De Checkpoint à FreeBSD. Évalué à 1.
Vérification de conformité, par exemple s'assurer de la présence d'un antivirus à jour avant d'autoriser la connexion. Tout ce qui se cache derrière le beau terme marketting " NAC"
Je suis pas un spécialiste Checkpoint, mais ça se vend pas que sur des plateformes Nokia, ils le vendent même à installer sur un Windows
Tout à fait, sur linux et solaris aussi, mais restons sérieux...
Effectivement, avec de l'OpenVPN par exemple c'est un process par CPU, donc à moins de monter plusieurs VPN et faire du round robin avec relayd, c'est pas out of the box (bien que faire du round robin avec relayd ça soit pas vraiment dur ...)
Sinon y'a du support de cryptodev pour Via padlock (avec OpenSSL sous OpenBSD j'ai déjà essayé avec des débits à 300Mbits/s, mais j'ai un doute, je sais plus si c'était avec AES128 ou AES256 ou les deux)
Ok, je ne connais pas, merci pour l'info. 300Mbps en vpn c'est bien, mais la plus petite des IP appliance checkpoint est annoncé au double, faudrait comparer en conditions réelles.
Malheureusement je doute fortement que ça marche en ayant les machines comme endpoint IPSec ou OpenVPN (ou alors il faut sérieusement bidouiller)
Ca de toute façon, ça marche toujours très bien sur le papier chez plein de constructeurs...
[^] # Re: Tout dépend du besoin...
Posté par Volnai . En réponse au journal De Checkpoint à FreeBSD. Évalué à 1.
C'est tout ce que je demandais. Pour les liens vers freebsd, pf et carp, c'est gentil, merci.
[^] # Re: Tout dépend du besoin...
Posté par Volnai . En réponse au journal De Checkpoint à FreeBSD. Évalué à 0.
En fait je suis persuadé qu'il y a un marché pour checkpoint autant que pour PF, tout dépends justement du besoin. C'est pour ça que je demande des infos sur la partie performance, n'ayant jamais migré de l'un à l'autre. Mais l'auteur du journal préfére pointer ma confusion Freebsd/openbsd plutôt que d'essayer de répondre.
[^] # Re: Tout dépend du besoin...
Posté par Volnai . En réponse au journal De Checkpoint à FreeBSD. Évalué à 0.
- de payer des licences,
- de se faire chier à désactiver des trucs qui les emmerdent et qu'ils ont payé?
Plus précisement, je dis que si tu achétes quelque chose dont tu n'as pas besoin et que tu est obligé de te taper une migration après, apprends à faire une étude.
[^] # Re: Tout dépend du besoin...
Posté par Volnai . En réponse au journal De Checkpoint à FreeBSD. Évalué à -4.
Décidement...
Si t'as pas envie de lire le journal, t'es pas obligé de poser des questions.
Si tu veux écrire un journal pour dire que tu ne sais pas utiliser checkpoint, que tu préfére freebsd et que tu ne veux pas répondre à des questions, fais un blog.
[^] # Re: Tout dépend du besoin...
Posté par Volnai . En réponse au journal De Checkpoint à FreeBSD. Évalué à -2.
Au temps pour moi, je pense à PF dès que je vois firewall et bsd dans la même phrase. Mais la question reste valable : Splat supporte le multicoeur, les cartes accélératrice et le mode actif/actif depuis longtemps. Qu'en est-il sous freebsd ?
# Tout dépend du besoin...
Posté par Volnai . En réponse au journal De Checkpoint à FreeBSD. Évalué à 2.
Pourtant il est vendu pour :
http://www.checkpoint.com/products/endpoint_connect/index.ht(...)
Bon j'ai pas testé, mais tu as quoi comme alternative pour faire un check du poste et un déploiement de règles locales a la connexion ?
Basé sur du Linux, mais suffisamment différent pour ne pas être utilisable comme un Linux
Si tu parles bien d'ipso, c'est basé sur du bsd à l'origine. Et il existe Gnukia pour retrouver un peu du confort Gnu sous ipso
Avoir deux IP sur la même carte réseau étant possible moyennant quelques bidouilles dans des fichiers de configuration non documentés.
Jamais essayé, mais dans quel but ? Ipso supportte très bien les interfaces vlans
Des licences à payer
Des options de sécurités top-cool qu'on passait notre temps à chercher puis désactiver
Bref, ça ne correspond pas à ton besoin.
Concernant les perf, il y a des cartes accélératrices qui fonctionnent correctement sous openbsd ? Déjà qu'il ne sait apparement pas utiliser plusieurs core d'après http://www.openbsd.org/faq/pf/fr/perf.html ...
Et ca fonctionne bien en mode actif/actif ?
# Et la démo ?
Posté par Volnai . En réponse au journal Auxrames : Outil de gestion d'équipe. Évalué à 7.
[^] # Re: Espion qdisc et/ou Courbe temps-réel d'historique de variable kerne
Posté par Volnai . En réponse au journal Espion qdisc et/ou Courbe temps-réel d'historique de variable kernel. Évalué à 9.
C'est pas grave, des clowns on en a déjà plein ici.