Euh ? Un WAF analyse le contenu du trafic HTTP, hein ? Donc tu fais une analyse couche applicative par conception.
OK, donc tu veux inclure un service intermédiaire, et ça n'est pas dans la philosophie d'IP : du coup oui, mets ton firewall applicatif. IP ne l'interdit pas, au contraire, mais ne peut pas remplacer effectivement une standardisation d'applicatif type request-response.
Non, la première RFC d'IPsec date de 1998 alors que SSL1.0 date de 1994,
mais bon comment tu adresse un serveur IPsec+SMTP ?
Il n'y a effectivement pas de modèle de CA global associé à IPsec, donc « tu ne peux pas » pour le cas généraliste qu'on voit avec TLS.
Oui tu utilise un reverse proxy donc.
Non, pas « proxy », juste parler TLS directement. Je précise car souvent le reverse-proxy implique d'avoir à différencier sur le hostname, avec SNI et consort, alors qu'ici on peut éviter ça.
Je n'ai pas était très précis. Mais tu peux vouloir avoir des log qui inclus l'information métier et donc doit décoder la 7ème couche. Tu peux imaginer vouloir réagir à ces informations comme ne pas router le trafic s'il y a trop d'erreurs avant.
Comme pour le premier cas, on ne va effectivement pas demander à IP de faire de l'applicatif. Ce que propose IP, par contre, c'est que le routage soit fait à la « bonne » couche.
Par contre je n'ai pas compris ton exemple de ne pas router « s'il y a trop d'erreurs avant ».
Prendre comme hypothèse que ça a était fais une fois est un peu plus simple que de considérer que ce sera fais pour chaque nouveaux services.
Pas d'accord : pour ton reverse, il va falloir que tu fasses l'adressage (et éventuellement le nommage) de toutes façons, mais tu le feras avec des couches d'IPv4 voire du NAT, et autre. Et dès qu'il faudra « bouger » tes backend, ça va être la merde parce que ton archi d'adressage est complètement sclérosée ; tu vas aller vers des solutions à la con genre VXLAN et consort (quoique ça doit être has-been aujourd'hui). Tout mettre au niveau d'IP avec de l'adressage globale découple complètement le routage de ton applicatif, et c'est ça qui simplifie énormément la vie. On ne voit pas les désavantages d'IPv4 parce que ses restrictions ont tellement été internalisées par tous que personne ne penserait à bouger un service : tu es « on-premise », ou dans le « Cloud », par exemple, mais jamais tu ne mélanges tout ça ; hérésie ! Alors que ça serait tellement évident en IPv6...
Et je ne parle même pas du setup de ton reverse-proxy : vu que c'est un SPOF, et qu'il doit être dimensionné « costaud », tu complexifies beaucoup plus que « juste un routeur ». Certes, trouver quelqu'un qui saura configurer correctement un routeur en IPv6 aujourd'hui est malheureusement pas si facile, mais j'espère que ça changera.
Mais l'argument disant que les gens l'ont pensé comme ça il y a 30 ans donc on doit continuer à le faire n'est pas très convainquant.
Oui, j'ai peut-être du mal à « faire rêver » avec mes trucs.
En fait quand je vois la facilité de mise en place
Je suis désolé mais de ce que j'ai vu (OK, subjectif), ça n'est vraiment pas si simple. Oui, les solutions sont mieux intégrées que le genre d'archi que je propose, mais ce ne sont « que » des problématique d'intégration qui pourraient être corrigées relativement facilement si on se bougeait un peu le cul. Derrière, quand il s'agit de gérer la scalabilité du bouzin, c'est une autre histoire.
et comme de très grosses infrastructures s'en servent, je me dis que pour mes besoins ça doit le faire sans trop se poser de question.
Les gros y mettent de gros moyens, et forcément ça marche. Mais le genre de truc que je propose marche même à très petite échelle, avec des moyens matériels très réduits. Ça n'est pas forcément vendeur car ça ne pousse pas à la consommation, mais c'est la manière que je préfère.
Je vois 3 points qui peuvent pose des problèmes sous fortes charges avec les reverses proxy :
1. le loadbalancing est fait plutôt tardivement ce qui réduit théoriquement les performance
Niveau perfs, je ne doute pas que vu comment c'est tuné aujourd'hui (d'autant plus si tu parles du très bon haproxy), ça ne doit pas avoir un impact énorme.
le nombre de connexion
Là c'est clairement un des avantages d'IPv6 : tu n'as pas de limite de scalabilité. Donc ton infra marche bien tant que tu es en-dessous de la limite (et ça suffit à plein de monde, certes), mais tu sais que quand tu l'atteins t'es dans la merde.
lors de l'ajout/suppression de service, il faut pouvoir reconfigurer à chaud
Effectivement.
Mais ça ne sont pas les désavantages les plus flagrants que je voyais : je pense plutôt à la complexité de la machine (applicatif spécialisé complet versus kernel + userspace « basique »), les différentes possibilités de configuration (= très simple en IP), le SPOF que ça constitue, ou si tu utilises des front redondés la complexité du partage d'état fait (problématique non présente en IP), etc.
[^] # Re: Merci !
Posté par benoar . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 2. Dernière modification le 06 février 2019 à 17:01.
OK, donc tu veux inclure un service intermédiaire, et ça n'est pas dans la philosophie d'IP : du coup oui, mets ton firewall applicatif. IP ne l'interdit pas, au contraire, mais ne peut pas remplacer effectivement une standardisation d'applicatif type request-response.
Je disais « historique » pour dire classiquement associée avec IP. Et si je chipotte, IPsec c'est 1995 https://tools.ietf.org/html/rfc1825.
Il n'y a effectivement pas de modèle de CA global associé à IPsec, donc « tu ne peux pas » pour le cas généraliste qu'on voit avec TLS.
Non, pas « proxy », juste parler TLS directement. Je précise car souvent le reverse-proxy implique d'avoir à différencier sur le hostname, avec SNI et consort, alors qu'ici on peut éviter ça.
Comme pour le premier cas, on ne va effectivement pas demander à IP de faire de l'applicatif. Ce que propose IP, par contre, c'est que le routage soit fait à la « bonne » couche.
Par contre je n'ai pas compris ton exemple de ne pas router « s'il y a trop d'erreurs avant ».
Pas d'accord : pour ton reverse, il va falloir que tu fasses l'adressage (et éventuellement le nommage) de toutes façons, mais tu le feras avec des couches d'IPv4 voire du NAT, et autre. Et dès qu'il faudra « bouger » tes backend, ça va être la merde parce que ton archi d'adressage est complètement sclérosée ; tu vas aller vers des solutions à la con genre VXLAN et consort (quoique ça doit être has-been aujourd'hui). Tout mettre au niveau d'IP avec de l'adressage globale découple complètement le routage de ton applicatif, et c'est ça qui simplifie énormément la vie. On ne voit pas les désavantages d'IPv4 parce que ses restrictions ont tellement été internalisées par tous que personne ne penserait à bouger un service : tu es « on-premise », ou dans le « Cloud », par exemple, mais jamais tu ne mélanges tout ça ; hérésie ! Alors que ça serait tellement évident en IPv6...
Et je ne parle même pas du setup de ton reverse-proxy : vu que c'est un SPOF, et qu'il doit être dimensionné « costaud », tu complexifies beaucoup plus que « juste un routeur ». Certes, trouver quelqu'un qui saura configurer correctement un routeur en IPv6 aujourd'hui est malheureusement pas si facile, mais j'espère que ça changera.
Oui, j'ai peut-être du mal à « faire rêver » avec mes trucs.
Je suis désolé mais de ce que j'ai vu (OK, subjectif), ça n'est vraiment pas si simple. Oui, les solutions sont mieux intégrées que le genre d'archi que je propose, mais ce ne sont « que » des problématique d'intégration qui pourraient être corrigées relativement facilement si on se bougeait un peu le cul. Derrière, quand il s'agit de gérer la scalabilité du bouzin, c'est une autre histoire.
Les gros y mettent de gros moyens, et forcément ça marche. Mais le genre de truc que je propose marche même à très petite échelle, avec des moyens matériels très réduits. Ça n'est pas forcément vendeur car ça ne pousse pas à la consommation, mais c'est la manière que je préfère.
Niveau perfs, je ne doute pas que vu comment c'est tuné aujourd'hui (d'autant plus si tu parles du très bon haproxy), ça ne doit pas avoir un impact énorme.
Là c'est clairement un des avantages d'IPv6 : tu n'as pas de limite de scalabilité. Donc ton infra marche bien tant que tu es en-dessous de la limite (et ça suffit à plein de monde, certes), mais tu sais que quand tu l'atteins t'es dans la merde.
Effectivement.
Mais ça ne sont pas les désavantages les plus flagrants que je voyais : je pense plutôt à la complexité de la machine (applicatif spécialisé complet versus kernel + userspace « basique »), les différentes possibilités de configuration (= très simple en IP), le SPOF que ça constitue, ou si tu utilises des front redondés la complexité du partage d'état fait (problématique non présente en IP), etc.