Quelle différence avec un firewall standard, quand tu utilise mon architecture ?
Euh ? Un WAF analyse le contenu du trafic HTTP, hein ? Donc tu fais une analyse couche applicative par conception. Si tu veux la faire via ton firewall c'est possible, mais c'est bizarre (ça veut dire que ton firewall (ou ce qui se plug à ton fw) va décoder la requête http, puis que tu va dans la suite continuer de vouloir être agnostique à la couche 7. Ça n'est pas particulièrement beau.
TLS offloading,
Je ne suis pas sûr de ce que tu proposes
Terminaison TLS si tu préfère.
mais la manière historique de faire c'est IPsec
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 ?
sinon, dans mon exemple tu pourrais rajouter du TLS avec un wrapper adapté (OK, c'est hypothétique).
Oui tu utilise un reverse proxy donc.
logging,
Mmmhhh, je le fais aussi. Si ton service est Unix standard, il utilise syslog. Forcément, si tu parles de l'avantage du logging pour palier son manque dû à des applis Web codées par des dev modernes...
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.
Note que dans ton cas, tu as externalisé toutes ces difficultés en prenant comme hypothèse que tu avais déjà une machine qui a un enregistrement DNS et un routage qui fonctionne. Ces choses ne sont pas arrivées magiquement, et un administrateur a bien dû les configurer.
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.
Le principe du « bout-en-bout », c'est de ne pas rajouter une couche au-dessus de tout ça (HTTP et reverse-proxy) pour faire quelque-chose qui était à la base prévu dans l'architecture d'Internet : le réseau a été conçu pour être un « réseau de processus », pas forcément de « machines » sur lesquelles on va rajouter une couche. Donc on pousse le nommage et le routage jusqu'aux extrémités.
Je sais et je le comprends bien. Ça n'empêche pas de pouvoir le critiquer. 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.
mais contrairement à ce qui est dit dans le journal choisir de faire un peu plus tardivement le routage ne me paraît pas forcément choquant.
Je n'ai pas dit choquant, je crois, jusque que c'est plus complexe et fragile. Si tu y trouves des avantages, tant mieux, mais j'ai souvent vu ses promoteurs sous-estimer ses désavantages.
Et des idéalistes voir des désavantages au microscopes. En fait quand je vois la facilité de mise en place 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.
Je vois 3 points qui peuvent pose des problèmes sous fortes charges avec les reverses proxy :
le loadbalancing est fait plutôt tardivement ce qui réduit théoriquement les performance, mais il faut relativiser ce coût face au reste du boulot de loadbalancing
le nombre de connexion une connexion TCP est identifiée par le quadruplé src_host:src_port → dest_host:dest_port si tu fixe la partie destination un client ne peux ouvrir que 30k connexions vers ton serveur (les distributions que j'ai regardé son configuré pour n'utiliser que les ports de 32768 à 60999 (voir /proc/sys/net/ipv4/ip_local_port_range). C'est utile pour certain bench
lors de l'ajout/suppression de service, il faut pouvoir reconfigurer à chaud ton reverse proxy. Nous avec haproxy, on utilise nl-qdisc-add et ça se passe bien. Sozu a était conçu pour ça. L'utilisation de pile réseau différente permet de faire des bidouille d'un coté sans impacter le reste ce qui est cool. Par contre pour la mise à jour atomique d'un service ça me semble plus compliquée
[^] # Re: Merci !
Posté par barmic . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 1.
Euh ? Un WAF analyse le contenu du trafic HTTP, hein ? Donc tu fais une analyse couche applicative par conception. Si tu veux la faire via ton firewall c'est possible, mais c'est bizarre (ça veut dire que ton firewall (ou ce qui se plug à ton fw) va décoder la requête http, puis que tu va dans la suite continuer de vouloir être agnostique à la couche 7. Ça n'est pas particulièrement beau.
Terminaison TLS si tu préfère.
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 ?
Oui tu utilise un reverse proxy donc.
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.
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.
Je sais et je le comprends bien. Ça n'empêche pas de pouvoir le critiquer. 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.
Et des idéalistes voir des désavantages au microscopes. En fait quand je vois la facilité de mise en place 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.
Je vois 3 points qui peuvent pose des problèmes sous fortes charges avec les reverses proxy :