Re: [FRnOG] [TECH] DNS adressage publique et privé d'un même domaine
Salut Jean-Philippe, Ce que tu souhaites s'appelle le Split Horizon DNS et est bien présenté là : https://en.wikipedia.org/wiki/Split-horizon_DNS Il n'y a aucune difficulté particulière à l'implémenter avec des serveurs DNS modernes. @+ -- Jérôme Nicolle +33 6 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Question résolution DNS ... particulière ...
> Kevin CHAILLY a écrit : > Attention, si ton application est attaquée par un navigateur internet, > ceux-ci vont vouloir > faire du DoH ( rien a voir avec Homer simpson ) et donc vont refuser > Split-horizon DNS > Il faut donc configurer ton serveur DNS pour désactiver DoH : > https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet Merci, çà m'a fait gagner du temps; c'était sur ma liste de gougler pour savoir comment faire çà. Ici, split DNS aussi. AD/M$ DNS en interne, un serveur différent sous Linux pour l'externe. Même certificat, donc que monserveur.maboite.com soit résolu avec une adresse privée quand on est local ou VPN ou avec une adresse publique pour les clients qui viennent de l'extérieur (et donc traversent NAT) çà marche. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Besoin d'avis sur l'usage d'IP privée dans les DNS publics
> > Pour ne plus être emmerdé avec le split DNS et la gestion de serveurs DNS, > > le client souhaite utiliser uniquement un resolver DNS public avec les > > enregistrements publics et privés. > Le split DNS c'est quand même un nid à ennui ++ +1 (...) > > Techniquement, ça marche. > Oui plutôt pas mal, sauf avec les résolveurs de certains FAI qui veulent ton > bien en répondant un NXDOMAIN (pas sur) quand c'est une IP RFC1918 (Coucou > Free > et Numericable). +1 Il faut bien avoir cette limitaion a l'esprit si les ressources privées sont accessibles via un VPN par exemple, et qu'on ne maitrise pas les resolver DNS des utilisateurs (clientless SSL VPN par exemple). (...) > Oui, je l'ai fait plusieurs fois, le seul soucis que je vois c'est de leaker à > l'extérieur le plan d'adressage interne, mais bon ça ne me semble pas une > information si utile à un attaquant (les ranges RFC 1918 sont pas si vastes) > par rapport aux ennuis créés par le split dns. On n'est pas vendredi donc je > ne > vais pas parler de zero-trust. Sans parler de zero-trust, avoir des entrées dans la zone DNS publique pour des sans IP publique joignable permet aussi de déployer des certificats SSL avec ACME (let's encrypt, zerossl, etc) et validation DNS. Evidemment, il n'est pas nécessaire que ces entrées DNS pointent vers une IP (privée ou publique). Donc je suis pas contre non plus. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] DNS Public et Adresse IPv4 privés.
On Thu, Dec 05, 2019 at 03:11:58PM +0100, Julien Escario wrote: […] Pour cela, il faut regarder du côté de split-horizon DNS mais c'est assez lourd à mettre en place juste pour un enregistrement. Quand j'ai discuté de la pertinence d'utiliser les vues en terme de sécurité avec quelqu'un qui s'occupe de DNS chez un NREN, il disait ceci : Au niveau opérationnel, les vues rendent le debug difficile. Ce que perçoit l'utilisateur à cause des vues (dont il ignore l'existence) n'est pas forcémment ce que perçoit le personne qui tente de l'aider (qui ignore également l'existence des vues). «[…] we don't encourage our member organizations to use views because of the risk of misconfiguration and difficulties in troubleshooting. Using views introduces failure modes that normally don't exist in DNS». -- Jean --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Besoin d'avis sur l'usage d'IP privée dans les DNS publics
Bonjour, Le mail du 21/09/2022 exprime entre autres: (cf. mail ID ): > Salut à tous, > J'ai une question liée à un cas d'usage que je rencontre chez un clients et > pour lequel j'ai du mal à trouver de arguments / contre-arguments. > Pour ne plus être emmerdé avec le split DNS et la gestion de serveurs DNS, > le client souhaite utiliser uniquement un resolver DNS public avec les > enregistrements publics et privés. > (sic) Beaucoup font ça avec BIND, mais c'est peut-être pas les mêmes raisons. Je dis ça pour mes 2 cts (vu que moi j'ai choisi unbound :). Ciao, -- Michel Soleilhavoup // Guichet ordinaire LPR du CTV --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] DNS adressage publique et privé d'un même domaine
https://www.mail-archive.com/search?q=split+DNS=frnog%40frnog.org <https://www.mail-archive.com/search?q=split+DNS=frnog@frnog.org> > Le 8 févr. 2019 à 15:27, AYANIDES, Jean-Philippe a > écrit : > > Bonjour, > > je n'arrive pas à trouver une réponse justifiée à la question suivante, alors > je m'adresse à vous sur conseil de mes collègues (désolé si ce sont des > questions bêtes et rebattues, je n'ai rien trouvé dans les archives de la > frnog) : > > dans le cadre d'une organisation example.com, à supposer que la zone > corp.example.com ne soit pas répliquée dans les DNS publiques example.com > ouverts sur internet, est-il possible et/ou non déconseillé, dans les DNS > internes > > - de résoudre un enregistrement A a.corp.example.com en adresse privée ? (de > façon générale, on a tendance à utiliser des noms locaux avec un TLD .local > mais l'IETF ne le recommande pas, cf. > https://tools.ietf.org/html/rfc6762#appendix-G). > > - de résoudre un même SOA corp.example.com avec une adresse IP privée depuis > le DNS interne privé et une adresse publique depuis le serveur DNS interne > publique ? > > - de résoudre certains enregistrements A du domaine corp.example.com en > adresses publiques et d'autres en adresses privées ? > > Si rien n'est possible proprement, quelle alternative peut-on trouver ? > faut-il segmenter en nommant par exemple tout ce qui est adressage publique > en pub.corp.example.com et tout ce qui est en adressage privé en > priv.example.com ? > > Je vous avoue que je ne suis pas familier avec la RFC… > > Merci > > Jean-Philippe > > This message contains information that may be privileged or confidential and > is the property of the Capgemini Group. It is intended only for the person to > whom it is addressed. If you are not the intended recipient, you are not > authorized to read, print, retain, copy, disseminate, distribute, or use this > message or any part thereof. If you receive this message in error, please > notify the sender immediately and delete all copies of this message. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Sous-zone DNS dédiée réseau interne via zone DNS gérée par tiers (eg. OVH)
Le 07/09/2021 à 15:36, David Ponzone a écrit : > Je crois qu’il manque des éléments pour pouvoir répondre exhaustivement. > La zone privée doit pouvoir être interrogée par des gens à l’extérieur > (ça a peu de sens puisqu’ils ne pourront pas atteindre la cible) ? > -> solution simple en mettant une IP publique à ston DNS interne > autoritaire sur interne.masociete.com <http://interne.masociete.com> > > Si c’est purement à usage interne, tu maitrises le résolveur utilisé par > les clients ? > -> si oui, alors la méthode du forward vers ton DNS interne pour > interne.masociete.com <http://interne.masociete.com>, ainsi c’est une > zone purement interne Zone purement interne qui ne peut pas être interrogée par des clients qui ne sont pas sur le LAN (en physique ou via un VPN). Je maîtrise bien le résolveur configuré sur les clients (si je ne le maîtrise pas ça serait pour un client type BYOD et le DHCP ferait quand même le job d'indiquer le bon serveur résolveur). Je compte donc mettre, sur mon résolveur, un forward de "interne.ma_societe.com" vers mon serveur DNS interne. Merci pour l'aide à la compréhension, le DNS c'est plutôt simple mais quand on veut faire des trucs compliqué (hybride privé/public, split-horizon, etc.) ça devient vite moins simple :P. -- DUVERGIER Claude --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Besoin d'avis sur l'usage d'IP privée dans les DNS publics
Salut à tous, J'ai une question liée à un cas d'usage que je rencontre chez un clients et pour lequel j'ai du mal à trouver de arguments / contre-arguments. Pour ne plus être emmerdé avec le split DNS et la gestion de serveurs DNS, le client souhaite utiliser uniquement un resolver DNS public avec les enregistrements publics et privés. En gros, ta bécane (laptop, serveur, ...) a le 1.1.1.1 en resolver DNS et quand elle recherche www.google.com, elle récupère 216.58.214.163. Par contre sur une recherche du genre "mon-serveur-interne.monentreprise.fr" et bien le serveur DNS répond 192.168.0.100. Techniquement, ça marche. Est-ce une bonne pratiqueje ne crois pas. (Mais comme AWS le fait avec les services privés (ELB, entre autres), certains ne voient pas de contraintes à faire pareil.) J'en viens donc à me demander si parmi vous certains ont déjà eu recours à cette pratique et si oui quels sont les arguments le justifiant. Si certains s'offusquent de ce genre de pratique, je suis preneur également des arguments et raisons techniques / sécurité. Merci de vos aides. -- *David* --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] NAT, IPv6 et autohébergement
On Mon, Sep 30, 2013 at 03:03:23PM +0200, Simon Perreault simon.perrea...@viagenie.ca wrote a message of 43 lines which said: Ça ressemble à un NAT qui ne fait pas de hairpinning. « Virage en épingle à cheveux » en français. (Le paquet va vers la box puis repart vers le réseau local.) Split DNS? Ouais. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Hôte pointant vers 127.0.0.1
❦ 23 septembre 2015 20:14 +0200, Pierre Emeriaud <petrus...@gmail.com> : >> un client me demande de créer un hôte DNS qui pointerait vers 127.0.0.1. > > Attention, certains resolvers comme par exemple[0] ceux de Free > filtrent certains[1] résultats[2], comme par exemple les entrées qui > pointent vers des entrées 1918. C'est mentionné dans la RFC, dans un > passage qui pourrait s'appliquer pour 127.0.0.1 : > >Prominent examples of such references are DNS Resource >Records and other information referring to internal private >addresses. In particular, Internet service providers should take >measures to prevent such leakage. Ce qui est casse-pied au possible dès qu'on utilise des VPN sur des OS dont le resolver ne sait pas faire de split DNS. C'est la raison principale pour laquelle je fais tourner Unbound en local. Exemple typique de position dogmatique qui empoisonne la vie des utilisateurs. -- All things that are, are with more spirit chased than enjoyed. -- Shakespeare, "Merchant of Venice" --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Besoin d'avis sur l'usage d'IP privée dans les DNS publics
21 septembre 2022 à 14:49 "David Neto" a écrit: > > Salut à tous, > > J'ai une question liée à un cas d'usage que je rencontre chez un clients et > pour lequel j'ai du mal à trouver de arguments / contre-arguments. > > Pour ne plus être emmerdé avec le split DNS et la gestion de serveurs DNS, > le client souhaite utiliser uniquement un resolver DNS public avec les > enregistrements publics et privés. > Le split DNS c'est quand même un nid à ennui ++ > En gros, ta bécane (laptop, serveur, ...) a le 1.1.1.1 en resolver DNS et > quand elle recherche www.google.com, elle récupère 216.58.214.163. Par > contre sur une recherche du genre "mon-serveur-interne.monentreprise.fr" et > bien le serveur DNS répond 192.168.0.100. > > Techniquement, ça marche. Oui plutôt pas mal, sauf avec les résolveurs de certains FAI qui veulent ton bien en répondant un NXDOMAIN (pas sur) quand c'est une IP RFC1918 (Coucou Free et Numericable). > Est-ce une bonne pratiqueje ne crois pas. (Mais comme AWS le fait avec > les services privés (ELB, entre autres), certains ne voient pas de > contraintes à faire pareil.) > Est-ce que le protocole ne le permet pas ? > J'en viens donc à me demander si parmi vous certains ont déjà eu recours à > cette pratique et si oui quels sont les arguments le justifiant. > Oui, je l'ai fait plusieurs fois, le seul soucis que je vois c'est de leaker à l'extérieur le plan d'adressage interne, mais bon ça ne me semble pas une information si utile à un attaquant (les ranges RFC 1918 sont pas si vastes) par rapport aux ennuis créés par le split dns. On n'est pas vendredi donc je ne vais pas parler de zero-trust. > Si certains s'offusquent de ce genre de pratique, je suis preneur également > des arguments et raisons techniques / sécurité. J'image que dig ad.maboite.com ça doit faire une ligne rouge dans le rapport de pentest > > Merci de vos aides. Gaëtan --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Besoin d'avis sur l'usage d'IP privée dans les DNS publics
My 2cents sur le sujet. 1) le split dns (avoir des zones dites privée et publique sur le meme nom dns) à mon avis c'est vraiment se tirer une belle balle dans le pieds. Je conseille de nettement séparer les zones publiques (qui ne devrait pas contenir grand chose normalement), et une zone avec des enregistrements rfc1918 (mais avec un vrai domaine et pas forcément un sous domaine de la 1ere. Par exemple : - masuperlicorne.io => public facing - priv-unikorne.net => private 2) est ce que les enregistrement de ton domaine "privé" doivent être accessible publiquement ? humm ca parait pratique mais en pratique c'est vite error prone (au delà du petit leak d'information). Comme on le mentionne de nombreux resolver de FAI vont les filtrer. Pire certaines box (coucou SFR/NC) font de l'inspection DNS et donc filtrer quoi qu'il arrive (meme si tu change pour pointer sur un resolver google ou cloudflare...). La ou ca devient plus embrouillant encore c'est que cela va résoudre depuis la plupart des navigateurs car ils font maintenant du DoH. Bref tant qu'à vouloir exposer des choses privés (via possiblement un vpn) autant fournir avec le résolveur imo. -- Raphael Mazelier On 21/09/2022 14:49, David Neto wrote: Salut à tous, J'ai une question liée à un cas d'usage que je rencontre chez un clients et pour lequel j'ai du mal à trouver de arguments / contre-arguments. Pour ne plus être emmerdé avec le split DNS et la gestion de serveurs DNS, le client souhaite utiliser uniquement un resolver DNS public avec les enregistrements publics et privés. En gros, ta bécane (laptop, serveur, ...) a le 1.1.1.1 en resolver DNS et quand elle recherchewww.google.com, elle récupère 216.58.214.163. Par contre sur une recherche du genre "mon-serveur-interne.monentreprise.fr" et bien le serveur DNS répond 192.168.0.100. Techniquement, ça marche. Est-ce une bonne pratiqueje ne crois pas. (Mais comme AWS le fait avec les services privés (ELB, entre autres), certains ne voient pas de contraintes à faire pareil.) J'en viens donc à me demander si parmi vous certains ont déjà eu recours à cette pratique et si oui quels sont les arguments le justifiant. Si certains s'offusquent de ce genre de pratique, je suis preneur également des arguments et raisons techniques / sécurité. Merci de vos aides. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] DNS adressage publique et privé d'un même domaine
Re, > Pour tout ce qui est Microsoft/Skype/ADFS, Microsoft demande de faire du > split DNS avec des serveurs proxy ADFS en DMZ pour le NDD principale. > Ici, on sur-écrit notre zone DNS publique en interne mais chaque > enregistrement est considéré comme une sous zone. Ainsi, si > l'enregistrement n'existe pas en Interne, le poste va résoudre le DNS > publique. C'est crade mais je ne vois pas trop d'alternative (sur du DNS > Microsoft). Oui, c'est bien ce que je décrivais... my bad si ce n'était pas clair :) En tout cas, avec toutes ces infos, la question originale est, je pense, totalement couverte... Si ça n'existe pas déjà, ça vaudrait presque le coup de faire un wiki avec ce type d'infos pour que les générations futures n'aient pas besoin de reposer la question... des gens motivés (=> PM) ? Cordialement, -- Philippe Bourcier web : http://sysctl.org/ blog : https://www.linkedin.com/today/author/philippebourcier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Filtrage DNS chez SFR
On 20/03/2020 20:53, Baptiste Chappe wrote: Bonsoir, J'ai eu la même ce jour avec un client sur une Freebox. Je monte le VPN avec un split. Seul le trafic vers le range precis passe dans le tunnel. Impossible de ping la ressource en DNS. Je change le DNS par Google et paf ca marche. Je suis un dingue en publiant dans le DNS des clients une IP privée ? J'ai rarement la chance d'avoir un DNS en local sur les sites (TPME 5 à 30 personnes). Ex : imprimante.toto.com = 192.168.1.2 Merci Messieurs merci de ne pas tous mélanger. Les résolveurs de Free sont connus pour filtrer les rfc1918. Les résolveurs de SFR/ex-NC semblent ok (et effectivement ne répondent que depuis le réseau SFR/ex-NC). A priori mais c'est à confirmer cela n'impacte qu'un certain type de box SFR (l'ingénierie SFR est sur le coup, merci à eux). PS : non ce n'est pas complètement fou comme pratique mais tu t'exposes à ce genre de problèmes. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] DNS adressage publique et privé d'un même domaine
désolé j'ai parcouru les discussions mais ça ne m'aide pas vraiment. Même une recherche sur DNS+public+privé n'ai pas de grande aide… Jean-Philippe > https://www.mail-archive.com/search?q=split+DNS=frnog%40frnog.org >> Le 8 févr. 2019 à 15:27, AYANIDES, Jean-Philippe a >> écrit : >> >> Bonjour, >> >> je n'arrive pas à trouver une réponse justifiée à la question suivante, >> alors je m'adresse à vous sur conseil de mes collègues (désolé si ce sont >> des questions bêtes et rebattues, je n'ai rien trouvé dans les archives de >> la frnog) : >> >> dans le cadre d'une organisation example.com, à supposer que la zone >> corp.example.com ne soit pas répliquée dans les DNS publiques example.com >> ouverts sur internet, est-il possible et/ou non déconseillé, dans les DNS >> internes >> >> - de résoudre un enregistrement A a.corp.example.com en adresse privée ? (de >> façon générale, on a tendance à utiliser des noms locaux avec un TLD .local >> mais l'IETF ne le recommande pas, cf. >> https://tools.ietf.org/html/rfc6762#appendix-G). >> >> - de résoudre un même SOA corp.example.com avec une adresse IP privée depuis >> le DNS interne privé et une adresse publique depuis le serveur DNS interne >> publique ? >> >> - de résoudre certains enregistrements A du domaine corp.example.com en >> adresses publiques et d'autres en adresses privées ? >> >> Si rien n'est possible proprement, quelle alternative peut-on trouver ? >> faut-il segmenter en nommant par exemple tout ce qui est adressage publique >> en pub.corp.example.com et tout ce qui est en adressage privé en >> priv.example.com ? >> >> Je vous avoue que je ne suis pas familier avec la RFC… >> >> Merci This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] DNS adressage publique et privé d'un même domaine
> Pour moi la best practice sur un AD (car j'ai l'impression que c'est de cela > dont on parle) c'est : > 1 - partir d'un domaine "racine" publique (example.com), sinon ca va être > compliqué/impossible d'utiliser les produits Cloud de Microsoft > 2 - avoir des DNS pub en DMZ ou chez n'importe quel hébergeur ou vendeur de > domaines... idéalement sur des AS différents > 3 - avoir une zone interne, type corp.example.com pour ton AD et tes Linux, > etc... donc en IP privées > 4 - ne surtout pas avoir de copie de ta zone pub (example.com) sur ton DNS > interne sinon il faut faire les modifs sur tes DNS pub et sur ton DNS interne > 5 - si besoin d'un record dans corp.example.com en IP pub, côté Internet, > alors tu crées corp.example.com sur le DNS pub et tu crées uniquement le > record nécessaire > > Voilà, là c'est propre et safe... Jusqu'au jour ou tu installes Lync/Skype For Business (ou son future nom quand un marketeux aura change d'avis) Ce machin oblige pour fonctionner d'avoir des enregistrements sur la zone racine example.com avec des contraintes a la con : - ceux qui doivent l'etre de l'extreieur et pas de l'interieur. - ceux qui doivent l'etre de l'interieur et pas de l'exterieur - ceux qui sont visible de l'intereiur et de l'exterieur mais avec des IPs differentes. Un enfer sans nom et qui casse le modele (notamment de la regle 4) Il devrait y avoir des lois contre ca. On a ete oblige d'introduire un split DNS rien que pr ca (et qui depuis n'a servi que pour ca) Youssef Ghorbal --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] DNS adressage publique et privé d'un même domaine
Hello, Pour tout ce qui est Microsoft/Skype/ADFS, Microsoft demande de faire du split DNS avec des serveurs proxy ADFS en DMZ pour le NDD principale. Ici, on sur-écrit notre zone DNS publique en interne mais chaque enregistrement est considéré comme une sous zone. Ainsi, si l'enregistrement n'existe pas en Interne, le poste va résoudre le DNS publique. C'est crade mais je ne vois pas trop d'alternative (sur du DNS Microsoft). Je voyais mal les milliers d'utilisateurs utiliser un login : us...@auth.hello.com pour envoyer en ger...@hello.com Baptiste, Le lun. 11 févr. 2019 à 10:59, Philippe Bourcier a écrit : > Re, > > > Attention, Maitre Capello passe : > > > >> Il n'y a aucun record dans cette sous zone > > > > Dans ce cas, ce n'est pas une zone mais juste un domaine. > > Oui, un sous-domaine, autant pour moi. > > >> sinon les records à la racine de celle-ci (. A IP). > > > > L'apex, pas la racine (qui a un autre sens pour le DNS). > > Là tu m'apprends carrément un nouveau mot :) > J'ai toujours entendu "racine du domaine" (qui est effectivement différent > de domaine racine). > > >> Ainsi on n'a pas besoin de recopier toute la zone racine > >> (example.com) > > > > Le suffixe public, pas la racine (qui a un autre sens pour le DNS). > > Ou plus simplement "tout le domaine" (voire "toute la zone")... > > Merci pour ce moment lexicologique :) > > > Cordialement, > -- > Philippe Bourcier > web : http://sysctl.org/ > blog : https://www.linkedin.com/today/author/philippebourcier > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Besoin d'avis sur l'usage d'IP privée dans les DNS publics
Salut, Chez nous, on utilise les zones de BIND9 pour séparer les entrées de notre réseau public de celles de nos réseaux privés. Du coup on se retrouve avec 1 seul serveur DNS à maintenir avec quand même une séparation enter les entrées. Pour le coup ça marche assez bien et étant une Asso étudiante on essaye de limiter le nombre de services afin d'assurer une passation des connaissances qui doit se faire chaque année et de manière optimum. Je ne sais pas si c'est la meilleure façon, je suis aussi preneur d'arguments et de retours. Viktor Association MiNET On 9/21/22 14:49, David Neto wrote: Salut à tous, J'ai une question liée à un cas d'usage que je rencontre chez un clients et pour lequel j'ai du mal à trouver de arguments / contre-arguments. Pour ne plus être emmerdé avec le split DNS et la gestion de serveurs DNS, le client souhaite utiliser uniquement un resolver DNS public avec les enregistrements publics et privés. En gros, ta bécane (laptop, serveur, ...) a le 1.1.1.1 en resolver DNS et quand elle recherche www.google.com, elle récupère 216.58.214.163. Par contre sur une recherche du genre "mon-serveur-interne.monentreprise.fr" et bien le serveur DNS répond 192.168.0.100. Techniquement, ça marche. Est-ce une bonne pratiqueje ne crois pas. (Mais comme AWS le fait avec les services privés (ELB, entre autres), certains ne voient pas de contraintes à faire pareil.) J'en viens donc à me demander si parmi vous certains ont déjà eu recours à cette pratique et si oui quels sont les arguments le justifiant. Si certains s'offusquent de ce genre de pratique, je suis preneur également des arguments et raisons techniques / sécurité. Merci de vos aides. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Split DNS
Bonjour Roger, Peut-être vais-je dire une bêtise, mais lors du dernier FR_NOG, nous avons eu une présentation fort sympathique de DNSDist. Je sais ce n'est pas son but que de délivrer des vues DNS, mais vu la panoplie d'outils qu'il intègre, on doit pouvoir faire quelque chose du genre pour un enregistrement particulier non ? (je n'ai pas creusé, je lance ça comme ça). C'est l'occasion de tester et éventuellement d'ajouter une couche qui peut te servir à autre chose dans ton infra DNS :) http://dnsdist.org/README/ Matthieu Le 31/05/2017 à 21:27, Roger YERBANGA a écrit : Bonjour à tous, Sur une infra de DNS (bind9) hébergeant quelques centaines de domaines, j'ai un enregistrement particulier qui doit donner 2 réponses différentes en fonction de l'IP source de la requête. Oui, ca se fait avec des views.En ce moment, je n'ai pas de vue sur les serveurs en question, et je ne souhaite pas dupliquer mes zones dans 2 vues différentes à cause d'un seul record dans une seule zone.Quelqu'un a-t-il une piste à me proposer ? Merci d'avance. ! roger --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] DNS Public et Adresse IPv4 privés.
Le 05/12/2019 à 14:58, Sylvain Grégoire a écrit : > Bonjour. > > Je me demande quel sont les incidence technique et règlementaires si l'on met > une adresse ip Privé ( un 172.16.X.X par exemple) dans un dns Public ? > > Je ne trouve que cette solution ou l'inscription dans un fichier host, pour > que les machine connectés par un plan d'adressage commun mais des dns > différents ce connectent à un serveur web interne. Rien de dramatique à faire. Par contre, l'idéal étant de ne pas envoyer cet enregistrement A sur le net, publiquement. Pour cela, il faut regarder du côté de split-horizon DNS mais c'est assez lourd à mettre en place juste pour un enregistrement. Peut être aussi voir si le resolver interne peut simplement aller piocher dans son fichier hosts pour répondre. Comme ça, les trucs moches en interne restent en interne ;-) Julien --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Split DNS
Bonjour Roger, Avec BIND j'utiliserais sortlist dans ton cas. En plus c'est plus facile si tu decides de signer ta zone dans le future. Jean-Yves > > > Le 31 mai 2017 à 21:27, Roger YERBANGA <roger_yerba...@yahoo.com> a > écrit : > > > > Bonjour à tous, > > Sur une infra de DNS (bind9) hébergeant quelques centaines de domaines, > j'ai un enregistrement particulier qui doit donner 2 réponses différentes > en fonction de l'IP source de la requête. > > Oui, ca se fait avec des views.En ce moment, je n'ai pas de vue sur les > serveurs en question, et je ne souhaite pas dupliquer mes zones dans 2 vues > différentes à cause d'un seul record dans une seule zone.Quelqu'un a-t-il > une piste à me proposer ? > > Merci d'avance. > > ! roger > > > > --- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Split DNS
La réponse est "view" Apres pour toutes les zones en commun, ça peut pointer vers les mêmes fichiers de zone. > Le 31 mai 2017 à 21:27, Roger YERBANGA <roger_yerba...@yahoo.com> a écrit : > > Bonjour à tous, > Sur une infra de DNS (bind9) hébergeant quelques centaines de domaines, j'ai > un enregistrement particulier qui doit donner 2 réponses différentes en > fonction de l'IP source de la requête. > Oui, ca se fait avec des views.En ce moment, je n'ai pas de vue sur les > serveurs en question, et je ne souhaite pas dupliquer mes zones dans 2 vues > différentes à cause d'un seul record dans une seule zone.Quelqu'un a-t-il une > piste à me proposer ? > Merci d'avance. > ! roger > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [ALERT] Un CDN Down ?
Ça depends aussi des numéros de version des enregistrements, de comment fonctionne le client du eyeballs, de la mise en place de Split dns (dans certains réseaux) etc etc etc Téléchargez Outlook pour Android<https://aka.ms/ghei36> From: Samuel Thibault Sent: Wednesday, June 9, 2021 1:12:27 PM To: Ludovic LACOSTE Cc: Damien Wetzel ; frnog-al...@frnog.org Subject: Re: [FRnOG] Re: [ALERT] Un CDN Down ? Ludovic LACOSTE, le mer. 09 juin 2021 11:08:53 +, a ecrit: > Non, ça marche pas comme ça le caching de Dns, en fonction du TTL Mais encore ? S'ils augmentent le TTL, c'est bien pour éviter des requêtes. Et pour toutes ces requêtes évitées, c'est autant de clients qui n'auront pas switché de CDN. Samuel --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Split DNS
l'enregistrement particulier il est pour les internes ou externes ? parce qu'effectivement avec bind, le split horizon, ça se fait avec des views. je comprend l'envie de pas dupliquer les zones, mais je t'assure avec un peu de python © c'est tout a fait gérable. quand a dnsdist, je peux que le recommander chaudement (comme toute la suite powerdns, pour avoir souffert des années sous le joug d'airain de bind, passer a powerdns c’était comme la caresse légère d'une brise printanière et provençale charriant les arômes de la lavande en fleur, tout ça) mais c'est pas son job de mentir au client. enfin si des fois, quand le client est méchant. On 06/01/2017 10:28 PM, Matthieu Racine wrote: > Bonjour Roger, > > Peut-être vais-je dire une bêtise, mais lors du dernier FR_NOG, nous > avons eu une présentation fort sympathique de DNSDist. Je sais ce > n'est pas son but que de délivrer des vues DNS, mais vu la panoplie > d'outils qu'il intègre, on doit pouvoir faire quelque chose du genre > pour un enregistrement particulier non ? (je n'ai pas creusé, je lance > ça comme ça). > C'est l'occasion de tester et éventuellement d'ajouter une couche qui > peut te servir à autre chose dans ton infra DNS :) > > http://dnsdist.org/README/ > > Matthieu > > Le 31/05/2017 à 21:27, Roger YERBANGA a écrit : >> Bonjour à tous, >> Sur une infra de DNS (bind9) hébergeant quelques centaines de >> domaines, j'ai un enregistrement particulier qui doit donner 2 >> réponses différentes en fonction de l'IP source de la requête. >> Oui, ca se fait avec des views.En ce moment, je n'ai pas de vue sur >> les serveurs en question, et je ne souhaite pas dupliquer mes zones >> dans 2 vues différentes à cause d'un seul record dans une seule >> zone.Quelqu'un a-t-il une piste à me proposer ? >> Merci d'avance. >> ! roger >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] DNS adressage publique et privé d'un même domaine
Bon alors ma réponse à moi va être: au diable les RFC. Tant que c’est ton choix de faire mentir ton DNS à tes utilisateurs internes, je ne vois pas le problème. > Le 8 févr. 2019 à 15:49, AYANIDES, Jean-Philippe a > écrit : > > désolé j'ai parcouru les discussions mais ça ne m'aide pas vraiment. > Même une recherche sur DNS+public+privé n'ai pas de grande aide… > > Jean-Philippe > >> https://www.mail-archive.com/search?q=split+DNS=frnog%40frnog.org > >>> Le 8 févr. 2019 à 15:27, AYANIDES, Jean-Philippe >>> a écrit : >>> >>> Bonjour, >>> >>> je n'arrive pas à trouver une réponse justifiée à la question suivante, >>> alors je m'adresse à vous sur conseil de mes collègues (désolé si ce sont >>> des questions bêtes et rebattues, je n'ai rien trouvé dans les archives de >>> la frnog) : >>> >>> dans le cadre d'une organisation example.com, à supposer que la zone >>> corp.example.com ne soit pas répliquée dans les DNS publiques example.com >>> ouverts sur internet, est-il possible et/ou non déconseillé, dans les DNS >>> internes >>> >>> - de résoudre un enregistrement A a.corp.example.com en adresse privée ? >>> (de façon générale, on a tendance à utiliser des noms locaux avec un TLD >>> .local mais l'IETF ne le recommande pas, cf. >>> https://tools.ietf.org/html/rfc6762#appendix-G). >>> >>> - de résoudre un même SOA corp.example.com avec une adresse IP privée >>> depuis le DNS interne privé et une adresse publique depuis le serveur DNS >>> interne publique ? >>> >>> - de résoudre certains enregistrements A du domaine corp.example.com en >>> adresses publiques et d'autres en adresses privées ? >>> >>> Si rien n'est possible proprement, quelle alternative peut-on trouver ? >>> faut-il segmenter en nommant par exemple tout ce qui est adressage publique >>> en pub.corp.example.com et tout ce qui est en adressage privé en >>> priv.example.com ? >>> >>> Je vous avoue que je ne suis pas familier avec la RFC… >>> >>> Merci > > This message contains information that may be privileged or confidential and > is the property of the Capgemini Group. It is intended only for the person to > whom it is addressed. If you are not the intended recipient, you are not > authorized to read, print, retain, copy, disseminate, distribute, or use this > message or any part thereof. If you receive this message in error, please > notify the sender immediately and delete all copies of this message. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] DNS adressage publique et privé d'un même domaine
Bonjour, Pour ce type de cas on peut créer un record qui serait en fait une sous-zone du domaine principal, côté extérieur. Côté intérieur on est sur une sous-zone du même type que corp.example.com. Par ex : chat-and-co.example.com Il n'y a aucun record dans cette sous zone sinon les records à la racine de celle-ci (. A IP). Ainsi on n'a pas besoin de recopier toute la zone racine (example.com) sur ton DNS interne... ==> problème résolu proprement February 10, 2019 2:15 AM, "Youssef Ghorbal" wrote: >> Pour moi la best practice sur un AD (car j'ai l'impression que c'est de cela >> dont on parle) c'est : >> 1 - partir d'un domaine "racine" publique (example.com), sinon ca va être >> compliqué/impossible >> d'utiliser les produits Cloud de Microsoft >> 2 - avoir des DNS pub en DMZ ou chez n'importe quel hébergeur ou vendeur de >> domaines... idéalement >> sur des AS différents >> 3 - avoir une zone interne, type corp.example.com pour ton AD et tes Linux, >> etc... donc en IP >> privées >> 4 - ne surtout pas avoir de copie de ta zone pub (example.com) sur ton DNS >> interne sinon il faut >> faire les modifs sur tes DNS pub et sur ton DNS interne >> 5 - si besoin d'un record dans corp.example.com en IP pub, côté Internet, >> alors tu crées >> corp.example.com sur le DNS pub et tu crées uniquement le record nécessaire >> >> Voilà, là c'est propre et safe... > > Jusqu'au jour ou tu installes Lync/Skype For Business (ou son future > nom quand un marketeux aura change d'avis) Ce machin oblige pour > fonctionner d'avoir des enregistrements sur la zone racine example.com > avec des contraintes a la con : > - ceux qui doivent l'etre de l'extreieur et pas de l'interieur. > - ceux qui doivent l'etre de l'interieur et pas de l'exterieur > - ceux qui sont visible de l'intereiur et de l'exterieur mais avec des > IPs differentes. > > Un enfer sans nom et qui casse le modele (notamment de la regle 4) Il > devrait y avoir des lois contre ca. > > On a ete oblige d'introduire un split DNS rien que pr ca (et qui > depuis n'a servi que pour ca) > > Youssef Ghorbal Cordialement, -- Philippe Bourcier web : http://sysctl.org/ blog : https://www.linkedin.com/today/author/philippebourcier --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Question résolution DNS ... particulière ...
Bonjour, En local, ton serveur DNS ( AD par exemple ) résoudra vers ton applicatif ( split-horizon ) En VPN, tu peux selon ta solution VPN forcer le serveur DNS pour faire résoudre vers ton applicatif, il n'y a donc pas de problème de NAT. Le même nom pourra donc résoudre vers ton serveur. Attention, si ton application est attaquée par un navigateur internet, ceux-ci vont vouloir faire du DoH ( rien a voir avec Homer simpson ) et donc vont refuser Split-horizon DNS Il faut donc configurer ton serveur DNS pour désactiver DoH : https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet Kévin -Message d'origine- De : frnog-requ...@frnog.org De la part de Pierrick CHOVELON Envoyé : jeudi 9 avril 2020 10:35 À : frnog-t...@frnog.org Objet : [FRnOG] [TECH] Question résolution DNS ... particulière ... Bonjour la liste, Je vous expose une situation à laquelle on va être confrontés. On a des pistes de travail (genre pistes forestières pas bien débroussaillées où on a du mal à faire un pied devant l'autre sans se prendre une racine ...). N'étant pas du tout du tout expert sur le DNS j'aimerai avoir vos conseils. On déploie des applications accessibles en HTTP/S sur des infra clients. Ces infras se trouver sur le réseau du client. Le client va ajouter un enregistrement dans son DNS interne pour résoudre *application.domaine.fr <http://application.domaine.fr>* (domaine interne du client) en IP interne (RFC1918 donc), et donner accès à ses utilisateurs. Ce nom sera utilisé dans le certificat HTTPS. On aura également besoin d'accéder à ces appli en web. Arrive donc la question : comment gérer (le plus "simplement" possible ) la résolution de *application.domaine.fr <http://application.domaine.fr>* depuis chez nous en sachant que : - on accède aux applis à travers un VPN lan to lan, il y a donc peut-être du NAT si overlapping - on voudrait éviter de gérer deux certificats HTTPS Nos pistes de réflexions sont : - Ajouter un sous-domaine en interne pour accéder à ces applications -> mais gestion de deux certificats côté appli - Récupérer les infos sur le DNS client avec une délégation -> mais se pose le problème du NAT - Déporter la résolution DNS chez le client en utilisant un proxy web configuré au même endroit que l'appli -> très contraignant à l'utilisation - Rester sur la modif de notre fichier /etc/hosts à la main ... ... ... ... On a bien fait le tour de la question, et on pense qu'il n'y aura pas de solution magique. Mais tant qu'à faire, autant mettre en place celle qui est le plus facile à maintenir. D'avance merci pour vos retours. Bonne journée. __ *Pierrick CHOVELON I *Ingénieur système *Advanced Software I IT* +33 4 77 43 27 05 <https://ligo.a-sis.eu/modules.php?op=modload=Annuaire=tel_TWSCaller=+33%204%2077%2043%2027%2005=CHOVELON%20Pierrick> pierrick.chove...@savoye.com *SAVOYE - 8, rue de la Richelandière - 42100 - Saint-Etienne - France* *Savoye recrute ! <https://careers.savoye.com/#!/fr/index> - *www.savoye.com --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [SPAM] [FRnOG] Re: [TECH] Pour prolonger le début de vendredi
>>> Parce qu'on peut en dire ce que l'on veut, actuellement, il n'existe >>> aucun moyen de prévenir un OS client qu'il dispose d'un serveur >>> DoH/DoT utilisable sur le réseau de l'opé/l'entreprise. >> >> Heureusement, car cela ne servirait à rien (ou plutôt à pas >> grand'chose). Split horizon DNS est-il une meilleure solution que le NAT Hairpinning ? Vous avez quatre heures. >Une utilisation que je vois à l'instant : se protéger contre un hack du CPE >qui permettrait d'y rajouter un DNS menteur ? >Mais on en revient à la problématique de split horizon qui va probablement >faire que personne ne s'amusera à ça. >J'anticipe simplement sur le moment au les gars de systemd-resolved vont >annoncer qu'ils utilisent le DoH de Google par défaut si aucun autre n'est >défini. En fait la problématique existe déjà : /etc/systemd/resolved.conf [Resolve] #DNS= #FallbackDNS= Vide sur deb', pour les copains qui utilisent Arch Linux ( pour ceux qui conaissent pas, Arch Linux, c'est comme courir dans la forêt amazonienne a poil, si tu survis, t'es un vrai, et t'auras des histoires-de-coin-du-feu sur 7 générations ) on trouve les informations suivantes dans la doc : *Note: The fallback DNS are in this order: Cloudflare, Quad9 (without filtering and without DNSSEC) and Google; see the systemd PKGBUILD where the servers are defined.* >>> Et pour ceux qui sont encore dans le brouillard, je propose un débat >>> sur le support des résolveurs DoH dans vos CPE préférés type krotik, >>> Cisco, Netgear, whatelse. Ca devrait nous occuper un moment. >> >> Un client DoH dans le CPE (s'il fait résolveur DNS), je vois >> l'intérêt, mais un serveur ? Ce n'est pas sur le réseau local qu'est >> l'adversaire. >Je pensais effectivement à la partie client DNS du CPE. Dans tous les cas, le >CPE ne pourrait pas avoir de certificat TLS valide (ou alors ce sera un >calvaire à gérer). +1 sur le calvaire du DNS en local. DoH demande forcément un certificat SSL valide, compliquant les déploiements en local. Microsoft en profitera sûrement pour Clouder les gens qui ont du DNS local. >Mais l'idée de faire confiance à son résolveur local (maîtrisable) qui est lui >même capable de résoudre avec DoH me paraît une chose intéressante à >atteindre, en particulier si DNSSEC décolle. >Mais comment donner l'adresse du serveur à ton CPE ? Il faut bien qu'il ai >(aussi) la possibilité de le récupérer de manière un minimum dynamique non ? Obligatoire pour les admins utilisant AD, DNS doit être le Contrôleur de Domaine. >> PS : https://doh.bortzmeyer.fr/, si vous voulez tester. Je promets >> qu'il n'y a pas de logs, puisque je n'ai pas compris comment les activer. > Et je suis censé te faire confiance ? Davantage qu'à Cloudflare ? ;-) Au niveau éthique, Bortzflare est sans équivalent. C'est que du bio en paquet IP, de la RFC en agriculture raisonnée, bref, du travail fait avec amour. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Re : Re: [FRnOG] [TECH] Split DNS
Re, Ce qui est bien avec Bind, c'est qu'il y a plein de doc : https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch06.html#multiple_views https://kb.isc.org/article/AA-00296/0/My-slave-server-for-both-an-internal-and-an-external-view-has-both-views-transferred-from-the-same-master-view-how-to-resolve-.html Quand même, gérer un DNS sans db, ça m'a rappelé ma jeunesse :) On 2017-05-31 21:51, Roger YERBANGA wrote: Oui et non.C'est vrai pour le maitre, mais bind donne une erreur de syntaxe pour les slaves.Donc, non. Marche pas comme ça. Roger Le mer., mai 31 2017 à 17:30, Guillaume Tournat<guilla...@ironie.org> a écrit : La réponse est "view" Apres pour toutes les zones en commun, ça peut pointer vers les mêmes fichiers de zone. Le 31 mai 2017 à 21:27, Roger YERBANGA <roger_yerba...@yahoo.com> a écrit : Bonjour à tous, Sur une infra de DNS (bind9) hébergeant quelques centaines de domaines, j'ai un enregistrement particulier qui doit donner 2 réponses différentes en fonction de l'IP source de la requête. Oui, ca se fait avec des views.En ce moment, je n'ai pas de vue sur les serveurs en question, et je ne souhaite pas dupliquer mes zones dans 2 vues différentes à cause d'un seul record dans une seule zone.Quelqu'un a-t-il une piste à me proposer ? Merci d'avance. ! roger Cordialement, -- Philippe Bourcier web : http://sysctl.org/ blog : https://www.linkedin.com/today/author/philippebourcier --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] Re: [ALERT] Un CDN Down ?
Et puis d’après l’analyse que j’ai pu lire, le problème est un problème de couche 7 (voir 8 , l’interface chaise/clavier, c’est terrible ) Erreur http 503, c’est un problème applicatif, pas réseau. Le DNS là-dedans … De : Ludovic LACOSTE Envoyé : mercredi 9 juin 2021 13:16 À : Samuel Thibault Cc : Damien Wetzel ; frnog-al...@frnog.org Objet : Re: [FRnOG] Re: [ALERT] Un CDN Down ? Ça depends aussi des numéros de version des enregistrements, de comment fonctionne le client du eyeballs, de la mise en place de Split dns (dans certains réseaux) etc etc etc Téléchargez Outlook pour Android<https://aka.ms/ghei36> From: Samuel Thibault mailto:samuel.thiba...@ens-lyon.org>> Sent: Wednesday, June 9, 2021 1:12:27 PM To: Ludovic LACOSTE mailto:ludoviclaco...@hotmail.com>> Cc: Damien Wetzel mailto:dwet...@atanar.com>>; frnog-al...@frnog.org<mailto:frnog-al...@frnog.org> mailto:frnog-al...@frnog.org>> Subject: Re: [FRnOG] Re: [ALERT] Un CDN Down ? Ludovic LACOSTE, le mer. 09 juin 2021 11:08:53 +, a ecrit: > Non, ça marche pas comme ça le caching de Dns, en fonction du TTL Mais encore ? S'ils augmentent le TTL, c'est bien pour éviter des requêtes. Et pour toutes ces requêtes évitées, c'est autant de clients qui n'auront pas switché de CDN. Samuel --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] [TECH] VRRP
On 16/01/2015 10:05, ay pierre wrote:
Non mais j'imaginé que de base il existait peut être un moyen
effectivement de faire de la haute disponibilitée mais rester dans un
environnement microsoft
Tu peux éventuellement faire du VRRP deux fois avec deux IP flottantes,
priorisées respectivement sur le serveur A et sur le serveur B, et
mettre deux A records sur ton entrée DNS en round robin.
Je fais ça avec du CARP et ça marche nickel.
Par contre c'est vraiment pas scalable (ça commence à être tordu si tu
rajoutes un 3eme site...) et il faut faire gaffe au split brain comme un
camarade l'a déjà mentionné.
M
--
Michel Blanc
{ :github = @leucos, :twitter = @b9m, :gpg = 0X24B35C22 }
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] NAT, IPv6 et autohébergement
Le 2013-09-30 14:53, Philippe Guillebert a écrit : Bonjour à tous, Un petit sujet peut-être un peu amateur pour cette liste, mais qui concerne ipv6, donc je me lance : J'essaye d'auto-héberger un petit blog chez moi derrière ma box. j'ai une entrée DNS mondomaine.com qui pointe sur l'adresse publique fixe de ma (free)box. Du coup, ca marche très bien, sauf depuis l'intérieur du réseau NATé par la box, ce qui est gênant pour mettre à jour le blog en pantoufles à la maison. Ça ressemble à un NAT qui ne fait pas de hairpinning. https://tools.ietf.org/html/rfc4787#section-6 Qu'a cela ne tienne, puisque le NAT c'est le mal, je rajoute une entrée qui pointe sur la même machine, et du coup ca devrait marcher de manière uniforme (intérieur et extérieur) puisque ipv6 (sans NAT) est, en principe, préféré par rapport à ipv4. Et là, patatras, ca ne marche pas toujours (du genre ca dépend des moments). Je suspecte que l'algorithme happy eyeballs qui fait préférer la connexion la plus rapide, sélectionne ipv4 parfois. Mon hypothèse vous parait-elle valable ? Oui. Ça serait facile à valider avec un peu de Wireshark... comment héberger un truc derrière un machinbox et y accéder depuis chez soi sans se prendre la tête ? Split DNS? Enlever IPv4 du LAN et faire du NAT64? ;) Simon --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeur pour PME
Bonjour, Le 21 janv. 2015 à 09:28, Pierre-Yves Le Dirach a écrit : On Wed, 21 Jan 2015 09:17:33 +0100, Michel Py mic...@arneill-py.sacramento.ca.us wrote: Alexis Lameire a écrit : - Relais DNS (si possible pouvoir gérer les nom interne aussi) Pour quelle raison ? surtout pour gérer les domaines internes (comme .local, à la grande consternation de notre Bortzmeyer national), je ne confierais pas çà au routeur. Michel. Tu m'intéresses. Pourquoi (dans le cas d'un domaine vraiment local, comme .kleber) ? Justement, .kleber n'est pas un domaine local, c'est un domaine éligible pour être TLD, et ça ne doit pas être utilisé en interne. Si tu veux un domaine *vraiment* local, tu utilises local.ma-compagnie.com, en t'étant assuré auparavant d'avoir le contrôle sur ma-compagnie.com. Par contre, je ne vois pas de problème à ce que le routeur gère les noms vraiment locaux, dans la mesure où cela te permet de faire facilement un split-horizon DNS entre les noms visibles depuis l'extérieur et les noms qui doivent n'être visibles qu'à l'intérieur seulement. Ajouter à cela la validation DNSSEC et tu as un résolveur parfait ! Cordialement Emmanuel Thierry --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Split DNS
Bonsoir, Oui, je ferais aussi 3 views : - Net1 - Net2 - Any (Net1+Net2) : toutes les zones sauf celle qui a le record spécifique Et si en plus tu ne veux pas te taper le boulot de modif 2 zones à chaque fois que tu veux modif un des record de la zone, tu fais une sous-zone uniquement pour le record en question, comme ça tu continues à avoir une seule zone "mondomaine.com" sur la view Any et tu as juste un fichier zone : - monrecordspecial.mondomaine.com-Net1.zone sur la view Net1 - monrecordspecial.mondomaine.com-Net2.zone sur la view Net2 "Piece of cake" dirait sieur Bortzmeyer :) La réponse est "view" Apres pour toutes les zones en commun, ça peut pointer vers les mêmes fichiers de zone. Bonjour à tous, Sur une infra de DNS (bind9) hébergeant quelques centaines de domaines, j'ai un enregistrement particulier qui doit donner 2 réponses différentes en fonction de l'IP source de la requête. Oui, ca se fait avec des views.En ce moment, je n'ai pas de vue sur les serveurs en question, et je ne souhaite pas dupliquer mes zones dans 2 vues différentes à cause d'un seul record dans une seule zone.Quelqu'un a-t-il une piste à me proposer ? Cordialement, -- Philippe Bourcier web : http://sysctl.org/ blog : https://www.linkedin.com/today/author/philippebourcier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re : Re: [FRnOG] [TECH] Split DNS
Oui et non.C'est vrai pour le maitre, mais bind donne une erreur de syntaxe pour les slaves.Donc, non. Marche pas comme ça. Roger Le mer., mai 31 2017 à 17:30, Guillaume Tournat<guilla...@ironie.org> a écrit : La réponse est "view" Apres pour toutes les zones en commun, ça peut pointer vers les mêmes fichiers de zone. > Le 31 mai 2017 à 21:27, Roger YERBANGA <roger_yerba...@yahoo.com> a écrit : > > Bonjour à tous, > Sur une infra de DNS (bind9) hébergeant quelques centaines de domaines, j'ai > un enregistrement particulier qui doit donner 2 réponses différentes en > fonction de l'IP source de la requête. > Oui, ca se fait avec des views.En ce moment, je n'ai pas de vue sur les > serveurs en question, et je ne souhaite pas dupliquer mes zones dans 2 vues > différentes à cause d'un seul record dans une seule zone.Quelqu'un a-t-il une > piste à me proposer ? > Merci d'avance. > ! roger > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] DNS adressage publique et privé d'un même domaine
- Il y a des raisons à faire du split DNS : pourquoi faire transiter par le routeur du trafic qui reste en interne ? C’est juste du bon sens, et une question de perf. Quand on a des backbone à 100 Gb/s ou plus, on a rarement la même chose en externe. Garder le même nom pour un service et ne pas y accéder par la même IP selon le lieu, je ne voit pas où est le souci. Tout le monde a l'air d'assumer que de maintenir des serveurs sur son réseau local d'entreprise semble aller de soi. Personnellement le moins d'IT locale j'ai à maintenir le mieux je me porte. Je pense aussi que le moins d'adhérence il y a entre les sites locaux et les infras de prod, le mieux c'est. Je considère que les locaux de l'entreprise fournissent une connectivité internet lambda, la même que celle d'un accès personnel. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Filtrage DNS chez SFR
Bonsoir, J'ai eu la même ce jour avec un client sur une Freebox. Je monte le VPN avec un split. Seul le trafic vers le range precis passe dans le tunnel. Impossible de ping la ressource en DNS. Je change le DNS par Google et paf ca marche. Je suis un dingue en publiant dans le DNS des clients une IP privée ? J'ai rarement la chance d'avoir un DNS en local sur les sites (TPME 5 à 30 personnes). Ex : imprimante.toto.com = 192.168.1.2 Merci Le ven. 20 mars 2020 à 19:59, Alarig Le Lay a écrit : > On ven. 20 mars 19:50:45 2020, Paul Rolland (ポール・ロラン) wrote: > > Hello, > > > > On Fri, 20 Mar 2020 19:43:17 +0100 > > Alarig Le Lay wrote: > > > > > [alarig@bsdcore3 ~]$ dig -t A roucool.int.no.swordarmor.fr @89.2.0.1 > > > > > > ; <<>> DiG 9.14.9 <<>> -t A roucool.int.no.swordarmor.fr @89.2.0.1 > > > ;; global options: +cmd > > > ;; connection timed out; no servers could be reached > > > > 89.2.0.1 ne repond apparemment que si tu es sur le reseau SFR. > > 54 [19:49] r...@riri.def:~> dig -t A www.google.fr @89.2.0.1 > > > > ; <<>> DiG 9.11.14-RedHat-9.11.14-2.fc31 <<>> -t A www.google.fr @ > 89.2.0.1 > > ;; global options: +cmd > > ;; connection timed out; no servers could be reached > > > > Paul > > La machine est bien sur le réseau de SFR, mais en fait le resolveur en > question, c’est celui de numéricâble ! > > [alarig@bsdcore3 ~]$ mtr -bzwe 89.2.0.1 > Start: 2020-03-20T19:53:55+0100 > HOST: bsdcore3.phaleon.org Loss% Snt > Last Avg Best Wrst StDev > 1. AS???192.168.1.1 0.0%10 > 0.3 0.4 0.3 0.5 0.1 > 2. AS??????100.010 > 0.0 0.0 0.0 0.0 0.0 > 3. AS15557 66.56.154.77.rev.sfr.net (77.154.56.66) 0.0%10 > 1.6 4.3 1.6 6.8 1.7 > 4. AS15557 210.61.6.109.rev.sfr.net (109.6.61.210) 0.0%10 > 1.8 3.2 1.8 6.5 1.4 > 5. AS15557 166.11.128.77.rev.sfr.net (77.128.11.166) 0.0%10 > 6.9 6.0 4.4 8.1 1.3 > 6. AS15557 217.10.136.77.rev.sfr.net (77.136.10.217) 0.0%10 > 18.1 18.3 16.1 20.1 1.2 > 7. AS15557 217.10.136.77.rev.sfr.net (77.136.10.217) 0.0%10 > 19.2 18.1 15.6 20.2 1.4 > 8. AS??????100.010 > 0.0 0.0 0.0 0.0 0.0 > [alarig@bsdcore3 ~]$ mtr -bzwe 109.0.66.10 > Start: 2020-03-20T19:56:01+0100 > HOST: bsdcore3.phaleon.org Loss% Snt > Last Avg Best Wrst StDev > 1. AS???192.168.1.10.0%10 > 0.4 0.4 0.3 0.5 0.0 > 2. AS?????? 100.010 > 0.0 0.0 0.0 0.0 0.0 > 3. AS15557 66.56.154.77.rev.sfr.net (77.154.56.66)0.0%10 > 5.2 7.3 1.5 35.4 10.0 > 4. AS15557 46.162.17.93.rev.sfr.net (93.17.162.46)0.0%10 > 17.4 17.8 15.9 19.7 1.4 > 5. AS15557 vip-dns-gp-primary.dns.sfr.net (109.0.66.10) 0.0%10 > 19.7 17.4 15.4 19.7 1.7 > [alarig@bsdcore3 ~]$ dig -t A roucool.int.no.swordarmor.fr @109.0.66.10 > > ; <<>> DiG 9.14.9 <<>> -t A roucool.int.no.swordarmor.fr @109.0.66.10 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51561 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;roucool.int.no.swordarmor.fr. IN A > > ;; ANSWER SECTION: > roucool.int.no.swordarmor.fr. 10800 IN A 10.0.4.0 > > ;; Query time: 114 msec > ;; SERVER: 109.0.66.10#53(109.0.66.10) > ;; WHEN: Fri Mar 20 19:55:52 CET 2020 > ;; MSG SIZE rcvd: 62 > > [alarig@bsdcore3 ~]$ dig -t A rfc1918.futomaki.net @109.0.66.10 > > ; <<>> DiG 9.14.9 <<>> -t A rfc1918.futomaki.net @109.0.66.10 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22396 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;rfc1918.futomaki.net. IN A > > ;; ANSWER SECTION: > rfc1918.futomaki.net. 1800IN A 192.168.0.43 > > ;; Query time: 64 msec > ;; SERVER: 109.0.66.10#53(109.0.66.10) > ;; WHEN: Fri Mar 20 19:57:37 CET 2020 > ;; MSG SIZE rcvd: 54 > > [alarig@bsdcore3 ~]$ > > Et donc au final, c’est même pas SFR qui fait du brin, c’est NC :D > > -- > Alarig > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] DNS adressage publique et privé d'un même domaine
Mmmhhh, je regarde ce débat depuis quelques jours, et j’aimerai apporter mon grain de sel (de sable ?). - Il y a des raisons à faire du split DNS : pourquoi faire transiter par le routeur du trafic qui reste en interne ? C’est juste du bon sens, et une question de perf. Quand on a des backbone à 100 Gb/s ou plus, on a rarement la même chose en externe. Garder le même nom pour un service et ne pas y accéder par la même IP selon le lieu, je ne voit pas où est le souci. - Sur le VPN… pour moi, et je sens que je vais lancer des débats, mais c’est juste le futur. C’est souple, performant, c’est pas juste des raisons économiques. On peut le déplacer si besoin, ajouter un site quand on veut, et ça permet malgré tout de maîtriser le chiffrement de point à point, le rendre redondant Le temps des MPLS qui ne sont pas interopérable est révolu…. La totalité des grands groupes que je connais migre 100% de leur infra vers des VPN. Allez, je viens de relancer le débat. ;) > Le 11 févr. 2019 à 19:05, Michel Py a > écrit : > >> Thierry Chich a écrit : >> Et donc, on a une infra qui se met à dépendre du VPN de >> manière beaucoup plus importante qu'elle ne le devrait. > > Certes, mais que faire d'autre ? Le VPN, çà n'existe que pour des raisons > économiques. Si je pouvais avoir de la fibre noire entre mes sites, c'est ce > que je ferais, mais c'est trop cher. > > Michel. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ <http://www.frnog.org/> --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] IPAM
Bien le bonjour, Je vais juste intervenir sur Ralph 3 pour donner un peu plus d'information. Le lien qui présente Ralph en Français concerne Ralph 2 (c'est moi qui l'ai écrit) néanmoins, ils sont en train de porter toutes les fonctionnalités majeures de Ralph 2. D'ailleurs Ralph 3 n'est pas encore sorti en stable pour cette raison, il reste quelques fonctionnalités à porter à 100%. Voici un état d'avancement de la Roadmap du 19 mai dernier : https://github.com/allegro/ralph/wiki/Ralph-3.x-roadmap Dans sa globalité, c'est assez stable et le projet semble de bonne qualité. Niveau activité, il est vraiment très actif et est supporté par une entreprise. Je pense franchement que Ralph 3 deviendra une référence dans la gestion de datacenter / cmdb Bonne journée à tous Le 20/06/2016 à 15:11, Phil Regnauld a écrit : Julien Schafer (j.schafer) writes: Bonjour Je voudrais savoir si certains ont un avis éclairé sur les solutions disponibles sur le marché (sachant qu'il y a du GPL, du payant etc) J'ai fini par compiler une liste des différents outils, avec des commentaires perso (en anglais), y compris des outils plus complets de gestion d'inventaire/configuration/data center. J'ai pas tout regardé, mais je retiens: - GestioIP - Ralph 3 - phpIPAM - opennetadmin - nocproject (usine à ga^H^Hplutonium) - NetDot (que je connais bien) # IPAM and CMDB software ## IPAM * HaCi http://haci.larsux.de/ - 2015-03 - IPAM only, v4/v6, multiple POPs, uses templates, space visualization * GestioIP http://haci.larsux.de/ - 2016-02 - IPAM w/ VLAN management, subnet disco. via SNMP, space visualization - BIND zone file generator fwd/ptr - Integration OCS Inventory NG * TeemIP - http://www.combodo.com/teemip-194 (2015-03), part of iTop or alone - request management w/portal systen for requestors - DNS - extensible * Subnetsmgt http://sourceforge.net/projects/subnetsmngr/ - 2013-05 - IPAM - PowerDNS integration * phpIPAM - http://phpipam.net - 2016-02 VLAN, VRF, visualization, RIPE, host scanning, etc... IP request form * netmagis - http://netmagis.org - 2015-09 Split DNS support DHCP/DNS integration VLAN maanagement Generate traffic graphs ## Inventory management / CMDB (possibly including IPAM) * iTop https://wiki.openitop.org/doku.php - 2014 (w/updates 2016) - Modular CMDB - Modules like TeemIP * Netdot - https://osl.uoregon.edu/redmine/projects/netdot - 2015-01 - great for campus networks - no overlapping IP/VLAN support - yet! - no VRF support - great integration to third party tools - actively maintained * Racktables - http://racktables.org/ - 2016-02 - active - Rack/DC specific (objects / IP / vlan / asset tags) - no built-in DNS integration * glpi - http://www.glpi-project.org - 2016-04 - active - Full fledged asset/inventory management - Modular, including Puppet integration - ITILish * OCS inventory-ng - Inventory / deployment - Integrates with GLPI - Lots of typos on website... - Download requires filling out a form, but it's on github * Ralph 3 - http://allegro.tech/ralph/ - 2016 - active - rack/asset mgmt - rack visualization - review http://blog.admin-linux.org/pilotage/ralph-systeme-de-gestion-d-actifs-pour-datacenter-cmdb-dcim * OpenDCIM - http://www.opendcim.org/ - - DC physical inventory - multi site support - calculate center of gravity for rack (!) - PDU integration * opennetadmin http://opennetadmin.com - 2016-03 - active - modular - support for hooks/host actions - config. backup - VLAN, etc. - CLI for interacting with system - DNS view support * nocproject - https://kb.nocproject.org/display/SITE/NOC - 2015-05 / active - this thing is in another class - it does *everything*, from configuration management to outage planning to inventory, provisioning, etc... 50 vendors+ supported - around for some years, written by Russians with some documentation in English, and even more in Russian - 120 people on the Telegram chat room! - for the new version, they built a deployment system called "Tower" just to manage Noc installations, based around ansible: https://bitbucket.org/nocproject/noc-tower * cmbuild http://www.cmdbuild.org/en/prodotti/cmdbuild - 2016-06 / active - this is a toolkit for building your own ITIL compliant CMDB - probably overkill for anyone Others: * tipp - https://github.com/tobez/tipp - 2014 - IPAM and only IPAM - In production for some years * ipplan (iptrack) http://iptrack.sourceforge.net/ - 2010 - dead ? - v6 support added later --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de di
[FRnOG] Re: [TECH] IPAM
Le 06/20/2016 à 03:11 PM, Phil Regnauld a écrit : > Julien Schafer (j.schafer) writes: >> Bonjour >> >> Je voudrais savoir si certains ont un avis éclairé sur les solutions >> disponibles sur le marché (sachant qu'il y a du GPL, du payant etc) > > J'ai fini par compiler une liste des différents outils, avec des > commentaires perso (en anglais), y compris des outils plus complets > de gestion d'inventaire/configuration/data center. > > J'ai pas tout regardé, mais je retiens: > > - GestioIP > - Ralph 3 > - phpIPAM > - opennetadmin > - nocproject (usine à ga^H^Hplutonium) > - NetDot (que je connais bien) > > # IPAM and CMDB software > > ## IPAM > > * HaCi http://haci.larsux.de/ - 2015-03 > > - IPAM only, v4/v6, multiple POPs, uses templates, space visualization > > * GestioIP http://haci.larsux.de/ - 2016-02 > > - IPAM w/ VLAN management, subnet disco. via SNMP, space visualization > - BIND zone file generator fwd/ptr > - Integration OCS Inventory NG > > * TeemIP - http://www.combodo.com/teemip-194 (2015-03), part of iTop or alone > > - request management w/portal systen for requestors > - DNS > - extensible > > * Subnetsmgt http://sourceforge.net/projects/subnetsmngr/ - 2013-05 > > - IPAM > - PowerDNS integration > > * phpIPAM - http://phpipam.net - 2016-02 > > VLAN, VRF, visualization, RIPE, host scanning, etc... > IP request form > > * netmagis - http://netmagis.org - 2015-09 > > Split DNS support > DHCP/DNS integration > VLAN maanagement > Generate traffic graphs > > ## Inventory management / CMDB (possibly including IPAM) > > * iTop https://wiki.openitop.org/doku.php - 2014 (w/updates 2016) > > - Modular CMDB > - Modules like TeemIP > > * Netdot - https://osl.uoregon.edu/redmine/projects/netdot - 2015-01 > > - great for campus networks > - no overlapping IP/VLAN support - yet! > - no VRF support > - great integration to third party tools > - actively maintained > > * Racktables - http://racktables.org/ - 2016-02 - active > > - Rack/DC specific (objects / IP / vlan / asset tags) > - no built-in DNS integration > > * glpi - http://www.glpi-project.org - 2016-04 - active > > - Full fledged asset/inventory management > - Modular, including Puppet integration > - ITILish > > * OCS inventory-ng > > - Inventory / deployment > - Integrates with GLPI > - Lots of typos on website... > - Download requires filling out a form, but it's on github > > * Ralph 3 - http://allegro.tech/ralph/ - 2016 - active > > - rack/asset mgmt > - rack visualization > - review > http://blog.admin-linux.org/pilotage/ralph-systeme-de-gestion-d-actifs-pour-datacenter-cmdb-dcim > > * OpenDCIM - http://www.opendcim.org/ - > > - DC physical inventory > - multi site support > - calculate center of gravity for rack (!) > - PDU integration > > * opennetadmin http://opennetadmin.com - 2016-03 - active > > - modular > - support for hooks/host actions > - config. backup > - VLAN, etc. > - CLI for interacting with system > - DNS view support > > * nocproject - https://kb.nocproject.org/display/SITE/NOC - 2015-05 / active > > - this thing is in another class - it does *everything*, > from configuration management to outage planning to > inventory, provisioning, etc... 50 vendors+ supported > - around for some years, written by Russians with > some documentation in English, and even more in Russian > - 120 people on the Telegram chat room! > > - for the new version, they built a deployment system called > "Tower" just to manage Noc installations, based around ansible: > > https://bitbucket.org/nocproject/noc-tower > > * cmbuild http://www.cmdbuild.org/en/prodotti/cmdbuild - 2016-06 / active > > - this is a toolkit for building your own ITIL compliant > CMDB > - probably overkill for anyone > > Others: > > * tipp - https://github.com/tobez/tipp - 2014 > > - IPAM and only IPAM > - In production for some years > > * ipplan (iptrack) http://iptrack.sourceforge.net/ - 2010 > > - dead ? > - v6 support added later > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > La partie Ipv4 space de racktables (racktables.org) ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] IPAM
Julien Schafer (j.schafer) writes:
> Bonjour
>
> Je voudrais savoir si certains ont un avis éclairé sur les solutions
> disponibles sur le marché (sachant qu'il y a du GPL, du payant etc)
J'ai fini par compiler une liste des différents outils, avec des
commentaires perso (en anglais), y compris des outils plus complets
de gestion d'inventaire/configuration/data center.
J'ai pas tout regardé, mais je retiens:
- GestioIP
- Ralph 3
- phpIPAM
- opennetadmin
- nocproject (usine à ga^H^Hplutonium)
- NetDot (que je connais bien)
# IPAM and CMDB software
## IPAM
* HaCi http://haci.larsux.de/ - 2015-03
- IPAM only, v4/v6, multiple POPs, uses templates, space visualization
* GestioIP http://haci.larsux.de/ - 2016-02
- IPAM w/ VLAN management, subnet disco. via SNMP, space visualization
- BIND zone file generator fwd/ptr
- Integration OCS Inventory NG
* TeemIP - http://www.combodo.com/teemip-194 (2015-03), part of iTop or alone
- request management w/portal systen for requestors
- DNS
- extensible
* Subnetsmgt http://sourceforge.net/projects/subnetsmngr/ - 2013-05
- IPAM
- PowerDNS integration
* phpIPAM - http://phpipam.net - 2016-02
VLAN, VRF, visualization, RIPE, host scanning, etc...
IP request form
* netmagis - http://netmagis.org - 2015-09
Split DNS support
DHCP/DNS integration
VLAN maanagement
Generate traffic graphs
## Inventory management / CMDB (possibly including IPAM)
* iTop https://wiki.openitop.org/doku.php - 2014 (w/updates 2016)
- Modular CMDB
- Modules like TeemIP
* Netdot - https://osl.uoregon.edu/redmine/projects/netdot - 2015-01
- great for campus networks
- no overlapping IP/VLAN support - yet!
- no VRF support
- great integration to third party tools
- actively maintained
* Racktables - http://racktables.org/ - 2016-02 - active
- Rack/DC specific (objects / IP / vlan / asset tags)
- no built-in DNS integration
* glpi - http://www.glpi-project.org - 2016-04 - active
- Full fledged asset/inventory management
- Modular, including Puppet integration
- ITILish
* OCS inventory-ng
- Inventory / deployment
- Integrates with GLPI
- Lots of typos on website...
- Download requires filling out a form, but it's on github
* Ralph 3 - http://allegro.tech/ralph/ - 2016 - active
- rack/asset mgmt
- rack visualization
- review
http://blog.admin-linux.org/pilotage/ralph-systeme-de-gestion-d-actifs-pour-datacenter-cmdb-dcim
* OpenDCIM - http://www.opendcim.org/ -
- DC physical inventory
- multi site support
- calculate center of gravity for rack (!)
- PDU integration
* opennetadmin http://opennetadmin.com - 2016-03 - active
- modular
- support for hooks/host actions
- config. backup
- VLAN, etc.
- CLI for interacting with system
- DNS view support
* nocproject - https://kb.nocproject.org/display/SITE/NOC - 2015-05 / active
- this thing is in another class - it does *everything*,
from configuration management to outage planning to
inventory, provisioning, etc... 50 vendors+ supported
- around for some years, written by Russians with
some documentation in English, and even more in Russian
- 120 people on the Telegram chat room!
- for the new version, they built a deployment system called
"Tower" just to manage Noc installations, based around ansible:
https://bitbucket.org/nocproject/noc-tower
* cmbuild http://www.cmdbuild.org/en/prodotti/cmdbuild - 2016-06 / active
- this is a toolkit for building your own ITIL compliant
CMDB
- probably overkill for anyone
Others:
* tipp - https://github.com/tobez/tipp - 2014
- IPAM and only IPAM
- In production for some years
* ipplan (iptrack) http://iptrack.sourceforge.net/ - 2010
- dead ?
- v6 support added later
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] IPAM
Bonsoir, Je viens de voir passer Netbox (IPAM+DCIM), un projet sous Apache de Digital Ocean. https://github.com/digitalocean/netbox ++ F/ 2016-06-21 10:55 GMT+02:00 Pierre-Yves Dubreucq <pydubre...@odiso.com>: > Bien le bonjour, > > Je vais juste intervenir sur Ralph 3 pour donner un peu plus d'information. > > Le lien qui présente Ralph en Français concerne Ralph 2 (c'est moi qui > l'ai écrit) néanmoins, ils sont en train de porter toutes les > fonctionnalités majeures de Ralph 2. > > D'ailleurs Ralph 3 n'est pas encore sorti en stable pour cette raison, il > reste quelques fonctionnalités à porter à 100%. > > Voici un état d'avancement de la Roadmap du 19 mai dernier : > > https://github.com/allegro/ralph/wiki/Ralph-3.x-roadmap > > Dans sa globalité, c'est assez stable et le projet semble de bonne > qualité. Niveau activité, il est vraiment très actif et est supporté par > une entreprise. > > Je pense franchement que Ralph 3 deviendra une référence dans la gestion > de datacenter / cmdb > > Bonne journée à tous > > > > Le 20/06/2016 à 15:11, Phil Regnauld a écrit : > >> Julien Schafer (j.schafer) writes: >> >>> Bonjour >>> >>> Je voudrais savoir si certains ont un avis éclairé sur les solutions >>> disponibles sur le marché (sachant qu'il y a du GPL, du payant etc) >>> >> J'ai fini par compiler une liste des différents outils, avec des >> commentaires perso (en anglais), y compris des outils plus complets >> de gestion d'inventaire/configuration/data center. >> >> J'ai pas tout regardé, mais je retiens: >> >> - GestioIP >> - Ralph 3 >> - phpIPAM >> - opennetadmin >> - nocproject (usine à ga^H^Hplutonium) >> - NetDot (que je connais bien) >> >> # IPAM and CMDB software >> >> ## IPAM >> >> * HaCi http://haci.larsux.de/ - 2015-03 >> >> - IPAM only, v4/v6, multiple POPs, uses templates, space >> visualization >> >> * GestioIP http://haci.larsux.de/ - 2016-02 >> >> - IPAM w/ VLAN management, subnet disco. via SNMP, space >> visualization >> - BIND zone file generator fwd/ptr >> - Integration OCS Inventory NG >> >> * TeemIP - http://www.combodo.com/teemip-194 (2015-03), part of iTop or >> alone >> >> - request management w/portal systen for requestors >> - DNS >> - extensible >> >> * Subnetsmgt http://sourceforge.net/projects/subnetsmngr/ - 2013-05 >> >> - IPAM >> - PowerDNS integration >> >> * phpIPAM - http://phpipam.net - 2016-02 >> >> VLAN, VRF, visualization, RIPE, host scanning, etc... >> IP request form >> >> * netmagis - http://netmagis.org - 2015-09 >> >> Split DNS support >> DHCP/DNS integration >> VLAN maanagement >> Generate traffic graphs >> >> ## Inventory management / CMDB (possibly including IPAM) >> >> * iTop https://wiki.openitop.org/doku.php - 2014 (w/updates 2016) >> >> - Modular CMDB >> - Modules like TeemIP >> >> * Netdot - https://osl.uoregon.edu/redmine/projects/netdot - 2015-01 >> >> - great for campus networks >> - no overlapping IP/VLAN support - yet! >> - no VRF support >> - great integration to third party tools >> - actively maintained >> >> * Racktables - http://racktables.org/ - 2016-02 - active >> >> - Rack/DC specific (objects / IP / vlan / asset tags) >> - no built-in DNS integration >> >> * glpi - http://www.glpi-project.org - 2016-04 - active >> >> - Full fledged asset/inventory management >> - Modular, including Puppet integration >> - ITILish >> >> * OCS inventory-ng >> >> - Inventory / deployment >> - Integrates with GLPI >> - Lots of typos on website... >> - Download requires filling out a form, but it's on github >> >> * Ralph 3 - http://allegro.tech/ralph/ - 2016 - active >> >> - rack/asset mgmt >> - rack visualization >> - review >> http://blog.admin-linux.org/pilotage/ralph-systeme-de-gestion-d-actifs-pour-datacenter-cmdb-dcim >> >> * OpenDCIM - http://www.opendcim.org/ - >> >> - DC physical inventory >> - multi site support >> - calculate center of gravity for rack (!) >> - PDU integration >> >> * opennetadmin http://opennetadmin.com - 2016-03 - active >> >>
[FRnOG] Re: [TECH] Pour prolonger le début de vendredi
Le 16/09/2019 à 11:44, Stephane Bortzmeyer a écrit : > On Mon, Sep 16, 2019 at 11:11:26AM +0200, > Julien Escario wrote > a message of 63 lines which said: > >> Pour ceux qui ont décuité, je soumets la lecture d'un draft IETF visant >> à définir la déclaration d'un serveur DoH dans les réponses DHCP/RA : >> https://datatracker.ietf.org/doc/draft-peterson-doh-dhcp/ > > C'est vraiment une idée bizarre. Si on utilise DoH, c'est parce qu'on > ne fait pas confiance au réseau d'accès, son résolveur DNS et son > serveur DHCP. Faire du DoH avec le résolveur d'un FAI qui a un > résolveur DNS menteur n'a que guère d'intérêt. > > [Note politique : la vraie motivation des FAI qui proposent cela est de > prétendre « on a du DoH ».] Ou de mutualiser les requêtes d'un grand nombre de clients sur un seul (ou un pool de) resolver DoH de façon à 'noyer' le trafic pour qu'il soit inexploitable en terme de vie privée ? (si on fait confiance à son FAI, pas forcément grozop) >> Parce qu'on peut en dire ce que l'on veut, actuellement, il n'existe >> aucun moyen de prévenir un OS client qu'il dispose d'un serveur DoH/DoT >> utilisable sur le réseau de l'opé/l'entreprise. > > Heureusement, car cela ne servirait à rien (ou plutôt à pas > grand'chose). Une utilisation que je vois à l'instant : se protéger contre un hack du CPE qui permettrait d'y rajouter un DNS menteur ? Mais on en revient à la problématique de split horizon qui va probablement faire que personne ne s'amusera à ça. J'anticipe simplement sur le moment au les gars de systemd-resolved vont annoncer qu'ils utilisent le DoH de Google par défaut si aucun autre n'est défini. >> Et pour ceux qui sont encore dans le brouillard, je propose un débat >> sur le support des résolveurs DoH dans vos CPE préférés type krotik, >> Cisco, Netgear, whatelse. Ca devrait nous occuper un moment. > > Un client DoH dans le CPE (s'il fait résolveur DNS), je vois > l'intérêt, mais un serveur ? Ce n'est pas sur le réseau local qu'est > l'adversaire. Je pensais effectivement à la partie client DNS du CPE. Dans tous les cas, le CPE ne pourrait pas avoir de certificat TLS valide (ou alors ce sera un calvaire à gérer). Mais l'idée de faire confiance à son résolveur local (maîtrisable) qui est lui même capable de résoudre avec DoH me paraît une chose intéressante à atteindre, en particulier si DNSSEC décolle. Mais comment donner l'adresse du serveur à ton CPE ? Il faut bien qu'il ai (aussi) la possibilité de le récupérer de manière un minimum dynamique non ? >> Tout ça pour dire que si on veut faire barrière à des choix douteux de >> browsers, il faut peut être se bouger pour proposer une alternative. > > L'alternative, ce sont des serveurs DoH gérés par des associations, > des syndicats, des ONG, des individus, etc. Et sur le même modèle que les root servers, c'est has-been ? *Pick one* Tout ça pour dire que la peinture sur tout ça n'est vraiment pas sèche et qu'un peu de retenue de la part des browsers serait la bienvenue. > PS : https://doh.bortzmeyer.fr/, si vous voulez tester. Je promets > qu'il n'y a pas de logs, puisque je n'ai pas compris comment les activer. Et je suis censé te faire confiance ? Davantage qu'à Cloudflare ? ;-) Julien signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker
On 24/11/2022 18:09, David Ponzone wrote: Ben non, on vient pas de dire qu’on avait besoin du lien inter-DC pour que le /32 soit accessible, même si on arrive par le mauvais site (celui sur lequel est est HS ou en mauvais état) ? Quoi qu'il arrive en réseau il faut que ton AS reste non disjoint d'une manière ou d'une autre (enfin à part configuration très particulière). Donc le split brain de DC n'est pas une option (quitte à passer over internet). Ceci dit, on peut aussi se demander si le choix d’Anycast est judicieux. Anycast pour moi, c’est quand on veut servir rapidement un grand nombre d’utilisateurs qui vont accéder autoBGPmagiquement au serveur le plus proche d’eux. Anycast pour de la redondance pure en actif / passif c'est curieux en effet. Par contre pour annoncer des services (meme internes) au plus proche (et de manière redondé donc) c'est courant (exemple courant le dns, ou autre truc stateless). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, …) pour le staff en télétravail ?
Bonjour, comme tout le monde, je +1 sur le split tunneling. cependant cette solution ne fonctionne plus quand la destination est derrière un CDN: ça devient compliqué de split tunneler les milliers d'IPs de Cloudfront. Si t'as un smart cloud-based VPN ChatGPT-powered et bien intrusif surtout, il arrive à le faire quand même à base d'interception DNS. sinon, la default dans le VPN si tu ne fais pas dans la dentelle. @+ Le mer. 29 mars 2023 à 14:41, DUVERGIER Claude a écrit : > Bonjour la liste, > > Certains de nos clients limitent les accès a leur SI (site en > préproduction, backoffice web, serveur FTP, etc.) par adresse IPv4. > > On leur communique donc nos adresses IP publiques (celles pour l'accès à > Internet), il les autorisent et voilà. > > Sauf qu'avec le télétravail, le staff qui travaille depuis leur > connexion Internet personnelle n'utilisent pas l'une des adresse IP > autorisée et sont donc bloqués. > > On a bien un service VPN qui permet aux collaborateurs en télétravail > d’accéder au LAN et SI de la société, mais il est configuré pour ne pas > recevoir le trafic réseau "autres" (celui qui irait sur Internet) : > l'idée étant que l'employé qui veut se mater une vidéo musicale en fond > ou se faire un film en streaming pendant sa pause n'utilise pas > inutilement la bande passante du service VPN. > > Historiquement le problème ne concernait que l'accès HTTP : on a donc > installé un proxy web (Squid) en interne (accessible en VPN) que > l'employé peut utiliser. Le trafic passe donc de son ordinateur au > serveur proxy via le tunnel VPN, et après ce serveur accède au SI du > client via une adresse autorisée. > > Mais avec le temps, se pose la question de l'accès à un serveur FTP, > puis en SSH, puis en RDP, etc. > > J'ai l'impression que pour chaque protocole je vais devoir installer un > nouveau serveur intermédiaire. Et que tant qu'à faire dans ce cas là, > autant leur configurer une session utilisateur sur un Ubuntu (accessible > en bureau à distance) qui utilise une des adresses IPs publiques > autorisée et ça fonctionnera pour tout les protocoles. > Mais bon, le RDP c'est peu pratique pour l'utilisateur. > > Vous avez une façon de faire pour ces cas là ? Une solution technique > (tel qu'un proxy TCP ou un genre de logiciel bastion qui gère plein de > protocole) ? Ou alors reconfigurer le VPN pour qu'il accepte tout le > trafic et puis c'est marre ? > > -- > Duvergier Claude > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] IPAM
Hello, On utilise Patch-Manager (https://patchmanager.com/product/) pour une centaine de baies. Gestion du rackage, câblage, pré-câblage et des prises de courant. Affichage en vue de dessus ou latérale. Appli Java avec un serveur + DB + client + API rest Support hyper-réactif. ++ F/ Le 30 juin 2016 à 14:26, Jean-Baptiste COUPIAC < jeanbaptiste.coup...@nfrance.com> a écrit : > Pour rebondir sur ce topic, > > Quel est pour vous le meilleur outil DCIM / le plus abouti (qu'il soit > open-source ou non ...) ? > > Merci, > > __ > > [image: NFrance Conseil] <http://www.nfrance.com/> > > *Jean-Baptiste COUPIAC* > Tél. : +33 5 34 45 55 00 <%20+33534455500> > 4 rue Kennedy 31000 Toulouse - France | www.nfrance.com > > > Le 30 juin 2016 à 14:19, Florian Cauzard <florian.cauzardja...@gmail.com> > a > écrit : > > > Hello, > > > > Nous on utilise PHPIPAM. Ca fait le boulot, simple a upgrade. Tu peux y > > renseigner tes VLAN, IPv4, IPv6. Si tu choisis la mauvaise IP il te le > dit > > donc tu ne peux pas faire n'importe quoi. Analyse du RIPE pour recuperer > > tes sugnets automatiquement. Peut se coupler avec un annuaire. > > > > Celle de digital Ocean est top car mélanger IPAM et Racktables (en gros) > > plus une gestion des secrets mais pas ne peut pas se coupler (sauf si je > me > > trompe) a un annuaire. > > > > 2016-06-27 19:08 GMT+02:00 Foucault de Bonneval <fouca...@thaumiers.com > >: > > > > > Bonsoir, > > > > > > Je viens de voir passer Netbox (IPAM+DCIM), un projet sous Apache de > > > Digital Ocean. > > > > > > https://github.com/digitalocean/netbox > > > > > > > > > > > > ++ > > > F/ > > > > > > 2016-06-21 10:55 GMT+02:00 Pierre-Yves Dubreucq <pydubre...@odiso.com > >: > > > > > > > Bien le bonjour, > > > > > > > > Je vais juste intervenir sur Ralph 3 pour donner un peu plus > > > d'information. > > > > > > > > Le lien qui présente Ralph en Français concerne Ralph 2 (c'est moi > qui > > > > l'ai écrit) néanmoins, ils sont en train de porter toutes les > > > > fonctionnalités majeures de Ralph 2. > > > > > > > > D'ailleurs Ralph 3 n'est pas encore sorti en stable pour cette > raison, > > il > > > > reste quelques fonctionnalités à porter à 100%. > > > > > > > > Voici un état d'avancement de la Roadmap du 19 mai dernier : > > > > > > > > https://github.com/allegro/ralph/wiki/Ralph-3.x-roadmap > > > > > > > > Dans sa globalité, c'est assez stable et le projet semble de bonne > > > > qualité. Niveau activité, il est vraiment très actif et est supporté > > par > > > > une entreprise. > > > > > > > > Je pense franchement que Ralph 3 deviendra une référence dans la > > gestion > > > > de datacenter / cmdb > > > > > > > > Bonne journée à tous > > > > > > > > > > > > > > > > Le 20/06/2016 à 15:11, Phil Regnauld a écrit : > > > > > > > >> Julien Schafer (j.schafer) writes: > > > >> > > > >>> Bonjour > > > >>> > > > >>> Je voudrais savoir si certains ont un avis éclairé sur les > solutions > > > >>> disponibles sur le marché (sachant qu'il y a du GPL, du payant etc) > > > >>> > > > >> J'ai fini par compiler une liste des différents outils, avec > des > > > >> commentaires perso (en anglais), y compris des outils plus > > complets > > > >> de gestion d'inventaire/configuration/data center. > > > >> > > > >> J'ai pas tout regardé, mais je retiens: > > > >> > > > >> - GestioIP > > > >> - Ralph 3 > > > >> - phpIPAM > > > >> - opennetadmin > > > >> - nocproject (usine à ga^H^Hplutonium) > > > >> - NetDot (que je connais bien) > > > >> > > > >> # IPAM and CMDB software > > > >> > > > >> ## IPAM > > > >> > > > >> * HaCi http://haci.larsux.de/ - 2015-03 > > > >> > > > >> - IPAM only, v4/v6, multiple POPs, uses templates, space > > > >> visualization > > > >> > > > >> * GestioIP http://haci.larsux.de/ - 2
Re: [FRnOG] [TECH] IPAM
Hello, Nous on utilise PHPIPAM. Ca fait le boulot, simple a upgrade. Tu peux y renseigner tes VLAN, IPv4, IPv6. Si tu choisis la mauvaise IP il te le dit donc tu ne peux pas faire n'importe quoi. Analyse du RIPE pour recuperer tes sugnets automatiquement. Peut se coupler avec un annuaire. Celle de digital Ocean est top car mélanger IPAM et Racktables (en gros) plus une gestion des secrets mais pas ne peut pas se coupler (sauf si je me trompe) a un annuaire. 2016-06-27 19:08 GMT+02:00 Foucault de Bonneval <fouca...@thaumiers.com>: > Bonsoir, > > Je viens de voir passer Netbox (IPAM+DCIM), un projet sous Apache de > Digital Ocean. > > https://github.com/digitalocean/netbox > > > > ++ > F/ > > 2016-06-21 10:55 GMT+02:00 Pierre-Yves Dubreucq <pydubre...@odiso.com>: > > > Bien le bonjour, > > > > Je vais juste intervenir sur Ralph 3 pour donner un peu plus > d'information. > > > > Le lien qui présente Ralph en Français concerne Ralph 2 (c'est moi qui > > l'ai écrit) néanmoins, ils sont en train de porter toutes les > > fonctionnalités majeures de Ralph 2. > > > > D'ailleurs Ralph 3 n'est pas encore sorti en stable pour cette raison, il > > reste quelques fonctionnalités à porter à 100%. > > > > Voici un état d'avancement de la Roadmap du 19 mai dernier : > > > > https://github.com/allegro/ralph/wiki/Ralph-3.x-roadmap > > > > Dans sa globalité, c'est assez stable et le projet semble de bonne > > qualité. Niveau activité, il est vraiment très actif et est supporté par > > une entreprise. > > > > Je pense franchement que Ralph 3 deviendra une référence dans la gestion > > de datacenter / cmdb > > > > Bonne journée à tous > > > > > > > > Le 20/06/2016 à 15:11, Phil Regnauld a écrit : > > > >> Julien Schafer (j.schafer) writes: > >> > >>> Bonjour > >>> > >>> Je voudrais savoir si certains ont un avis éclairé sur les solutions > >>> disponibles sur le marché (sachant qu'il y a du GPL, du payant etc) > >>> > >> J'ai fini par compiler une liste des différents outils, avec des > >> commentaires perso (en anglais), y compris des outils plus complets > >> de gestion d'inventaire/configuration/data center. > >> > >> J'ai pas tout regardé, mais je retiens: > >> > >> - GestioIP > >> - Ralph 3 > >> - phpIPAM > >> - opennetadmin > >> - nocproject (usine à ga^H^Hplutonium) > >> - NetDot (que je connais bien) > >> > >> # IPAM and CMDB software > >> > >> ## IPAM > >> > >> * HaCi http://haci.larsux.de/ - 2015-03 > >> > >> - IPAM only, v4/v6, multiple POPs, uses templates, space > >> visualization > >> > >> * GestioIP http://haci.larsux.de/ - 2016-02 > >> > >> - IPAM w/ VLAN management, subnet disco. via SNMP, space > >> visualization > >> - BIND zone file generator fwd/ptr > >> - Integration OCS Inventory NG > >> > >> * TeemIP - http://www.combodo.com/teemip-194 (2015-03), part of iTop or > >> alone > >> > >> - request management w/portal systen for requestors > >> - DNS > >> - extensible > >> > >> * Subnetsmgt http://sourceforge.net/projects/subnetsmngr/ - 2013-05 > >> > >> - IPAM > >> - PowerDNS integration > >> > >> * phpIPAM - http://phpipam.net - 2016-02 > >> > >> VLAN, VRF, visualization, RIPE, host scanning, etc... > >> IP request form > >> > >> * netmagis - http://netmagis.org - 2015-09 > >> > >> Split DNS support > >> DHCP/DNS integration > >> VLAN maanagement > >> Generate traffic graphs > >> > >> ## Inventory management / CMDB (possibly including IPAM) > >> > >> * iTop https://wiki.openitop.org/doku.php - 2014 (w/updates 2016) > >> > >> - Modular CMDB > >> - Modules like TeemIP > >> > >> * Netdot - https://osl.uoregon.edu/redmine/projects/netdot - 2015-01 > >> > >> - great for campus networks > >> - no overlapping IP/VLAN support - yet! > >> - no VRF support > >> - great integration to third party tools > >> - actively maintained > >> > >> * Racktables - http://racktables.org/ - 2016-02 - active > >> > >> - Rack/D
Re: [FRnOG] [TECH] IPAM
Pour rebondir sur ce topic, Quel est pour vous le meilleur outil DCIM / le plus abouti (qu'il soit open-source ou non ...) ? Merci, __ [image: NFrance Conseil] <http://www.nfrance.com/> *Jean-Baptiste COUPIAC* Tél. : +33 5 34 45 55 00 <%20+33534455500> 4 rue Kennedy 31000 Toulouse - France | www.nfrance.com Le 30 juin 2016 à 14:19, Florian Cauzard <florian.cauzardja...@gmail.com> a écrit : > Hello, > > Nous on utilise PHPIPAM. Ca fait le boulot, simple a upgrade. Tu peux y > renseigner tes VLAN, IPv4, IPv6. Si tu choisis la mauvaise IP il te le dit > donc tu ne peux pas faire n'importe quoi. Analyse du RIPE pour recuperer > tes sugnets automatiquement. Peut se coupler avec un annuaire. > > Celle de digital Ocean est top car mélanger IPAM et Racktables (en gros) > plus une gestion des secrets mais pas ne peut pas se coupler (sauf si je me > trompe) a un annuaire. > > 2016-06-27 19:08 GMT+02:00 Foucault de Bonneval <fouca...@thaumiers.com>: > > > Bonsoir, > > > > Je viens de voir passer Netbox (IPAM+DCIM), un projet sous Apache de > > Digital Ocean. > > > > https://github.com/digitalocean/netbox > > > > > > > > ++ > > F/ > > > > 2016-06-21 10:55 GMT+02:00 Pierre-Yves Dubreucq <pydubre...@odiso.com>: > > > > > Bien le bonjour, > > > > > > Je vais juste intervenir sur Ralph 3 pour donner un peu plus > > d'information. > > > > > > Le lien qui présente Ralph en Français concerne Ralph 2 (c'est moi qui > > > l'ai écrit) néanmoins, ils sont en train de porter toutes les > > > fonctionnalités majeures de Ralph 2. > > > > > > D'ailleurs Ralph 3 n'est pas encore sorti en stable pour cette raison, > il > > > reste quelques fonctionnalités à porter à 100%. > > > > > > Voici un état d'avancement de la Roadmap du 19 mai dernier : > > > > > > https://github.com/allegro/ralph/wiki/Ralph-3.x-roadmap > > > > > > Dans sa globalité, c'est assez stable et le projet semble de bonne > > > qualité. Niveau activité, il est vraiment très actif et est supporté > par > > > une entreprise. > > > > > > Je pense franchement que Ralph 3 deviendra une référence dans la > gestion > > > de datacenter / cmdb > > > > > > Bonne journée à tous > > > > > > > > > > > > Le 20/06/2016 à 15:11, Phil Regnauld a écrit : > > > > > >> Julien Schafer (j.schafer) writes: > > >> > > >>> Bonjour > > >>> > > >>> Je voudrais savoir si certains ont un avis éclairé sur les solutions > > >>> disponibles sur le marché (sachant qu'il y a du GPL, du payant etc) > > >>> > > >> J'ai fini par compiler une liste des différents outils, avec des > > >> commentaires perso (en anglais), y compris des outils plus > complets > > >> de gestion d'inventaire/configuration/data center. > > >> > > >> J'ai pas tout regardé, mais je retiens: > > >> > > >> - GestioIP > > >> - Ralph 3 > > >> - phpIPAM > > >> - opennetadmin > > >> - nocproject (usine à ga^H^Hplutonium) > > >> - NetDot (que je connais bien) > > >> > > >> # IPAM and CMDB software > > >> > > >> ## IPAM > > >> > > >> * HaCi http://haci.larsux.de/ - 2015-03 > > >> > > >> - IPAM only, v4/v6, multiple POPs, uses templates, space > > >> visualization > > >> > > >> * GestioIP http://haci.larsux.de/ - 2016-02 > > >> > > >> - IPAM w/ VLAN management, subnet disco. via SNMP, space > > >> visualization > > >> - BIND zone file generator fwd/ptr > > >> - Integration OCS Inventory NG > > >> > > >> * TeemIP - http://www.combodo.com/teemip-194 (2015-03), part of iTop > or > > >> alone > > >> > > >> - request management w/portal systen for requestors > > >> - DNS > > >> - extensible > > >> > > >> * Subnetsmgt http://sourceforge.net/projects/subnetsmngr/ - 2013-05 > > >> > > >> - IPAM > > >> - PowerDNS integration > > >> > > >> * phpIPAM - http://phpipam.net - 2016-02 > > >> > > >> VLAN, VRF, visualization, RIPE, host scanning, etc... > > >> IP request form > > &g
Re: [FRnOG] [TECH] IPAM
pour les gens qui ont plein de sous, y'a ericson adaptive inventory. (anciennement granite. jamais entendu un mec l'appeller adaptive machin) mais alors, plein de sous hein. On 06/30/2016 02:26 PM, Jean-Baptiste COUPIAC wrote: Pour rebondir sur ce topic, Quel est pour vous le meilleur outil DCIM / le plus abouti (qu'il soit open-source ou non ...) ? Merci, __ [image: NFrance Conseil] <http://www.nfrance.com/> *Jean-Baptiste COUPIAC* Tél. : +33 5 34 45 55 00 <%20+33534455500> 4 rue Kennedy 31000 Toulouse - France | www.nfrance.com Le 30 juin 2016 à 14:19, Florian Cauzard <florian.cauzardja...@gmail.com> a écrit : Hello, Nous on utilise PHPIPAM. Ca fait le boulot, simple a upgrade. Tu peux y renseigner tes VLAN, IPv4, IPv6. Si tu choisis la mauvaise IP il te le dit donc tu ne peux pas faire n'importe quoi. Analyse du RIPE pour recuperer tes sugnets automatiquement. Peut se coupler avec un annuaire. Celle de digital Ocean est top car mélanger IPAM et Racktables (en gros) plus une gestion des secrets mais pas ne peut pas se coupler (sauf si je me trompe) a un annuaire. 2016-06-27 19:08 GMT+02:00 Foucault de Bonneval <fouca...@thaumiers.com>: Bonsoir, Je viens de voir passer Netbox (IPAM+DCIM), un projet sous Apache de Digital Ocean. https://github.com/digitalocean/netbox ++ F/ 2016-06-21 10:55 GMT+02:00 Pierre-Yves Dubreucq <pydubre...@odiso.com>: Bien le bonjour, Je vais juste intervenir sur Ralph 3 pour donner un peu plus d'information. Le lien qui présente Ralph en Français concerne Ralph 2 (c'est moi qui l'ai écrit) néanmoins, ils sont en train de porter toutes les fonctionnalités majeures de Ralph 2. D'ailleurs Ralph 3 n'est pas encore sorti en stable pour cette raison, il reste quelques fonctionnalités à porter à 100%. Voici un état d'avancement de la Roadmap du 19 mai dernier : https://github.com/allegro/ralph/wiki/Ralph-3.x-roadmap Dans sa globalité, c'est assez stable et le projet semble de bonne qualité. Niveau activité, il est vraiment très actif et est supporté par une entreprise. Je pense franchement que Ralph 3 deviendra une référence dans la gestion de datacenter / cmdb Bonne journée à tous Le 20/06/2016 à 15:11, Phil Regnauld a écrit : Julien Schafer (j.schafer) writes: Bonjour Je voudrais savoir si certains ont un avis éclairé sur les solutions disponibles sur le marché (sachant qu'il y a du GPL, du payant etc) J'ai fini par compiler une liste des différents outils, avec des commentaires perso (en anglais), y compris des outils plus complets de gestion d'inventaire/configuration/data center. J'ai pas tout regardé, mais je retiens: - GestioIP - Ralph 3 - phpIPAM - opennetadmin - nocproject (usine à ga^H^Hplutonium) - NetDot (que je connais bien) # IPAM and CMDB software ## IPAM * HaCi http://haci.larsux.de/ - 2015-03 - IPAM only, v4/v6, multiple POPs, uses templates, space visualization * GestioIP http://haci.larsux.de/ - 2016-02 - IPAM w/ VLAN management, subnet disco. via SNMP, space visualization - BIND zone file generator fwd/ptr - Integration OCS Inventory NG * TeemIP - http://www.combodo.com/teemip-194 (2015-03), part of iTop or alone - request management w/portal systen for requestors - DNS - extensible * Subnetsmgt http://sourceforge.net/projects/subnetsmngr/ - 2013-05 - IPAM - PowerDNS integration * phpIPAM - http://phpipam.net - 2016-02 VLAN, VRF, visualization, RIPE, host scanning, etc... IP request form * netmagis - http://netmagis.org - 2015-09 Split DNS support DHCP/DNS integration VLAN maanagement Generate traffic graphs ## Inventory management / CMDB (possibly including IPAM) * iTop https://wiki.openitop.org/doku.php - 2014 (w/updates 2016) - Modular CMDB - Modules like TeemIP * Netdot - https://osl.uoregon.edu/redmine/projects/netdot - 2015-01 - great for campus networks - no overlapping IP/VLAN support - yet! - no VRF support - great integration to third party tools - actively maintained * Racktables - http://racktables.org/ - 2016-02 - active - Rack/DC specific (objects / IP / vlan / asset tags) - no built-in DNS integration * glpi - http://www.glpi-project.org - 2016-04 - active - Full fledged asset/inventory management - Modular, including Puppet integration - ITILish * OCS inventory-ng - Inventory / deployment - Integrates with GLPI - Lots of typos on website... - Download requires filling out a form, but it's on github * Ralph 3 - http://allegro.tech/ralph/ - 2016 - active - rack/asset mgmt - rack visualization - review http://blog.admin-linux.org/pilotage/ralph-systeme-de-gestion-d-actifs-pour-datacenter-cmdb-dcim * OpenDCIM - http://www.opendcim.org/ - - DC physical invent
RE: [FRnOG] [TECH] IPAM
> ## IPAM > > >> > > >> * HaCi http://haci.larsux.de/ - 2015-03 > > >> > > >> - IPAM only, v4/v6, multiple POPs, uses templates, space > > >> visualization > > >> > > >> * GestioIP http://haci.larsux.de/ - 2016-02 > > >> > > >> - IPAM w/ VLAN management, subnet disco. via SNMP, space > > >> visualization > > >> - BIND zone file generator fwd/ptr > > >> - Integration OCS Inventory NG > > >> > > >> * TeemIP - http://www.combodo.com/teemip-194 (2015-03), part of > > >> iTop > or > > >> alone > > >> > > >> - request management w/portal systen for requestors > > >> - DNS > > >> - extensible > > >> > > >> * Subnetsmgt http://sourceforge.net/projects/subnetsmngr/ - > > >> 2013-05 > > >> > > >> - IPAM > > >> - PowerDNS integration > > >> > > >> * phpIPAM - http://phpipam.net - 2016-02 > > >> > > >> VLAN, VRF, visualization, RIPE, host scanning, etc... > > >> IP request form > > >> > > >> * netmagis - http://netmagis.org - 2015-09 > > >> > > >> Split DNS support > > >> DHCP/DNS integration > > >> VLAN maanagement > > >> Generate traffic graphs > > >> > > >> ## Inventory management / CMDB (possibly including IPAM) > > >> > > >> * iTop https://wiki.openitop.org/doku.php - 2014 (w/updates 2016) > > >> > > >> - Modular CMDB > > >> - Modules like TeemIP > > >> > > >> * Netdot - https://osl.uoregon.edu/redmine/projects/netdot - > > >> 2015-01 > > >> > > >> - great for campus networks > > >> - no overlapping IP/VLAN support - yet! > > >> - no VRF support > > >> - great integration to third party tools > > >> - actively maintained > > >> > > >> * Racktables - http://racktables.org/ - 2016-02 - active > > >> > > >> - Rack/DC specific (objects / IP / vlan / asset tags) > > >> - no built-in DNS integration > > >> > > >> * glpi - http://www.glpi-project.org - 2016-04 - active > > >> > > >> - Full fledged asset/inventory management > > >> - Modular, including Puppet integration > > >> - ITILish > > >> > > >> * OCS inventory-ng > > >> > > >> - Inventory / deployment > > >> - Integrates with GLPI > > >> - Lots of typos on website... > > >> - Download requires filling out a form, but it's on github > > >> > > >> * Ralph 3 - http://allegro.tech/ralph/ - 2016 - active > > >> > > >> - rack/asset mgmt > > >> - rack visualization > > >> - review > > >> > > > http://blog.admin-linux.org/pilotage/ralph-systeme-de-gestion-d-actifs > -pour-datacenter-cmdb-dcim > > >> > > >> * OpenDCIM - http://www.opendcim.org/ - > > >> > > >> - DC physical inventory > > >> - multi site support > > >> - calculate center of gravity for rack (!) > > >> - PDU integration > > >> > > >> * opennetadmin http://opennetadmin.com - 2016-03 - active > > >> > > >> - modular > > >> - support for hooks/host actions > > >> - config. backup > > >> - VLAN, etc. > > >> - CLI for interacting with system > > >> - DNS view support > > >> > > >> * nocproject - https://kb.nocproject.org/display/SITE/NOC - > > >> 2015-05 / active > > >> > > >> - this thing is in another class - it does *everything*, > > >>from configuration management to outage planning to > > >>inventory, provisioning, etc... 50 vendors+ supported > > >> - around for some years, written by Russians with > > >>some documentation in English, and even more in Russian > > >> - 120 people on the Telegram chat room! > > >> > > >> - for the new version, they built a deployment system called > > >>"Tower" just to manage Noc installations, based around ansible: > > >> > > >> https://bitbucket.org/nocproject/noc-tower > > >> > > >> * cmbuild http://www.cmdbuild.org/en/prodotti/cmdbuild - 2016-06 > > >> / > > active > > >> > > >> - this is a toolkit for building your own ITIL compliant > > >>CMDB > > >> - probably overkill for anyone > > >> > > >> Others: > > >> > > >> * tipp - https://github.com/tobez/tipp - 2014 > > >> > > >> - IPAM and only IPAM > > >> - In production for some years > > >> > > >> * ipplan (iptrack) http://iptrack.sourceforge.net/ - 2010 > > >> > > >> - dead ? > > >> - v6 support added later > > >> > > >> > > >> --- > > >> Liste de diffusion du FRnOG > > >> http://www.frnog.org/ > > >> > > > > > > > > > --- > > > Liste de diffusion du FRnOG > > > http://www.frnog.org/ > > > > > > > --- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ > > > > > > -- > Florian CAUZARD-JARRY > 1 rue des Brouets > 78711 Mantes la Ville > 06-71-71-04-80 > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] Questionnement d 'un administrateur système sur l'IPv6
contre tu peux le router comme tu veux sur ton réseau). En gros, comme les adresses privées IPv4 sauf qu'en plus le préfixe a très peu de chances d'être le même que celui d'une autre boite. Comment est-il annoncé ce préfixe local ? On peut donc se baser sur ce lien local pour monter toute l'archi interne (nom DNS interne pour le split, etc) et laisser l'autoconf gérer pour l'adresse routable sur Internet. Existe-t-il un service DHCPv6 pour l'adresse locale ? Il me semblait avoir lu qu'une IPv6 incomplète est recomposée à partir du préfixe actuel, est-ce le cas ? Je ne suis pas sûr de comprendre la question... Une IPv6 c'est 64 bits de préfixe et 64 bits d'identifiant d'interface. Les 64 bits du début sont donnés par le routeur, et les 64 bits de la fin sont au choix de la machine (à condition de ne pas créer une adresse en double). Je précise ma question, lorsque j'ai commencé à m'intéresser à l'IPv6 j'ai lu un article disant que lors d'un accès à une IPv6, si le début était le même que l'adresse locale, alors on pouvait l'éviter En gros si mon IP local est 2001:0db8::85a3:::ac1f:8001 et que je cherche à contacter 2001:0db8::85a3:030a:0020:ac1f:8001 je pourrais écrire simplement :::030a:0020:ac1f:8001. Est-ce vrai ? (Quelques problèmes quant à savoir quelle source sont valables sur le net à ce sujet) Pour un premier message sur cette liste je vais commencer par me présenter brièvement, je suis Yoann Gini, formateur et consultant Apple sur tout ce qui concerne Mac OS X et Mac OS X Server en entreprise OSX a un bon support v6 et apple se sert de v6 pour back to my mac http://www.ietf.org/id/draft-zhu-mobileme-doc-02.txt Curieux que vous n'ayez pas d'info de leur part ! Ça fait partie des joies du travail avec Apple (je travaille en freelance, pas en salarié). Ils ont plein de trucs super fun en interne, mais ils n'en donnent que la moitié, voir moins… - Sans forcément avoir de multiWAN, si je change de FAI je change de préfixe IPv6, or le réseau a été construit à partir de ce préfixe (service interne, DNS, etc.). Actuellement si je change de FAI je n'ai aucun problème puisqu'en interne je n'ai que des IP privés. Avec l'IPv6 je ne vois pas trop comment on peut gérer ce cas, est-ce qu'il faut refaire tout l'adressage avec le changement de fournisseur ? Premièrement vous devriez utiliser un DNS interne pour ne pas utliser les IP directement. Dans ce cas le changement est facile, c'est juste l'ajout de nouvelles IP, et un changement des enregistrement DNS. Mais dans la plupart des cas seules quelques IP sont présentées au net pour les services. Dans le cas d'un applicatif web, personne n'a besoin de savoir les IPs des serveurs SQL, etc. Il est possible de garder les IPs que votre premier FAI vous a fourni, même si elle ne sont alors plus routable globalement, d'ajouter de nouvelles IP au interfaces pour ajouter un accès net (mise a jour de securite, etc.) mais les applications marcheront toujours en interne en utilisant l'adressage du premier FAI. Ceci dit je ne vois aucune raison pour utiliser les IPs dans les applications. Bien évidement je n'utilise que du DNS en interne, jamais d'IP ! C'est surtout pour savoir s'il y a un moyen de rendre le changement de préfixe transparent pour le DNS interne. Bien que ça n'arrive pas souvent et qu'il n'y a généralement pas beaucoup d'entrée dans le DNS, j'essaye toujours de prendre la solution qui nécessite le moins d'action de ma part :-) Maintenant l'utilisation de l'adresse MAC n'est qu'un option d'auto-configuration, pour des machines qui fournissent des services publiques ce n'est surement pas très judicieux. Router les IP en V6 comme en V4 avec DHCPv6 ou une configuration des machines avec des IPs statiques me parait plus judicieux. L'auto configuration c'est bien pour les cas de plug and play. C'est plus ou moins ce que je pensais faire. Les serveurs en statique, c'est plus pour les postes clients que je pensais user de l'autoconf (sauf nécessité de pousser des infos en plus) - Dans le cas plus spécifique du multiWAN. Comment est-il possible de gérer la répartition de charge sans faire de NAT ? Je ne vois pas de difference avec v4 - pourquoi penses-tu que c'est plus dur en IPV6 ? Comment fais-tu normalement ta répartition de charge ? Actuellement ma répartition de charge se fait sur le routeur, il s'occupe de prendre la connexion WAN la moins occupée et fait le NAT en fonction. Sans NAT et avec deux préfixes différents, comment le routeur va gérer l'histoire ? Si la connexion est émise depuis le client avec le préfixe de la connexion A alors qu'il faut user du B, ça se passe comment ? Rien ne garantit qu'un client ai le même identifiant peu importe le préfixe, si ? Tout le monde n'a pas de service publique. Beaucoup des services sont utilise via DNS, alors un changement c'est un changement le TTL, puis un changement d'IP et voila
RE: [FRnOG] Re: [TECH] NAT et IP hors RFC-1918
Bonjour Adrien, Énormément d'entreprises utilisent le double nat sur la chaine d'accès à internet. Exemple Français: la majorité des banques utilisent des IP publiques d'autrui en interne. Certaines uniquement pour les agences / campus, d'autres également pour leur DC... En général la majorité des structures de plus de 100k personnes et avec un historique lourd (achats, filiales,...) s'est déjà retrouvée au pied du mur. Faire du double NAT impose de centraliser la chaine d'accès internet pour l'ensemble du groupe ou d'obliger à ce que le design de cette chaine soit reproduit à l'identique si des filiales veulent leur propre accès par exemple. Typiquement, on chaine 2 lots de proxy (interne et externe) Les 2 lots se voient entre eux via des IP 1918 Le lot interne est exposé aux clients via du privé ou du faux public, pas d'importance. Le lot externe exploite de vrais IP publiques pour aller sur le web (sauf si on re nat encore l'exposition externe du proxy, ce qui est rare...), ce lot externe n'a aucune route vers le réseau interne, en dehors des proxy internes et de réseaux de management et supervision. Pour exposer des serveurs à l'extérieur, même bricolage, on double NAT (par exemple FW en entrée DMZ puis 2nde fois sur des SLB) Certaines entreprises n'ont pas pris de précautions, et ont dû mettre en œuvre ce double chainage un beau jour en urgence. D'ailleurs quand cloudflare a sorti son 1.1.1.1, certains ont découvert qu'ils routaient déjà cette IP en interne, car elle a longtemps été hard codé dans les WLC wifi Cisco. Chez les habitués de ce bricolage, on tape souvent dans les IP du DoD US, sauf que celui-ci indique dans divers documents passés au congrès qu'ils veulent vendre une bonne partie de leur IP publiques dans la dizaine d'année qui vient. En vérité ça ne devrait pas se faire beaucoup plus vite que leur nombreuses tentatives de migration vers IPv6. Nouveau problème aujourd'hui, ces grandes entreprises commencent à devoir annoncer de vraies IP publiques dans leur backbone interne (par exemple pour faire du MS Teams en UDP via des G-IX, ce qui est plus performant qu'en TCP) Mais si demain MS utilise une IP qui existe en interne ? ... et MS annonce les nouvelles IP et URL Office 365 seulement 4 à 6 semaines à l'avance. Idéalement les adeptes du "bricolage double nat" vont donc devoir lancer un script chaque semaine pour vérifier qu'aucune de leur fausse IP publique n'est nouvellement affectée dans le monde réel à l'AS de leur provider préféré (MS, Amazon, ...) histoire de déclencher l'alerte tsunami à temps (oxymore power) Et notre ami l'UDP qui force la main pour teams, il arrive à grands pas grâce à QUIC, dans quelque temps on interrogera plein d'API publiques ou de ressources cloud via QUIC, et bien sûr on naviguera avec, les équipes pare-feu et backbone vont alors pouvoir partager l'apéro avec les équipes proxy... Quic a bien un connection ID, mais il sert à la mobilité et n'est pas visible des middlebox... Ha, et si tu comptes faire du split tunneling avec le VPN, il faut veiller à surveiller le non-recouvrement de la même façon que pour les vraies routes publiques apprises en backbone. (pour du SaaS en général) Une raison plus de s'intéresser à IPv6 dans les grosses structures, sauf si on veut garder un réseau qui ressemble à un film de Christopher Nolan. Concernant le NAT-DNS dont tu parles, il est utile pour exposer un serveur d'une entité A à une entité B avec de l'overlapp. Le principal intérêt étant que certaines solutions (F5, Palo,..) permettent de tout gérer sur la même appliance de façon consistante, car toute la "truanderie" nat et dns hérite de la même règle sur la même boite, et qu'il n'y a donc pas besoin de demander à l'administrateur DNS et aux équipes FW etc de se synchroniser. C'est extrêmement utilisé, notamment quand les structures A et B n'ont plus trop de comptes à se rendre, mais que la force des choses les oblige à collaborer. Ce mode limite fortement les interactions nécessaires et le nombre de gestes à droite et gauche. Reste un cas qui pose problème, le SIP. Il y'a bien des ALG pour natter aussi l'intérieur de la signalisation SIP, mais bon... On va vers un monde où on aura de meilleures performances à la maison (IPv6 + QUIC) qu'au bureau (NAT + TCP) pour tout ce qui est web, que ça soit application, appels API,... Une sorte d'apartheid protocolaire que certains utilisateurs de Saas et leur direction ont déjà noté grâce au confinement. Jean-Charles Bisecco --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, …) pour le staff en télétravail ?
Tu as plusieurs choix qui s’offrent à toi mais l’idée de faire du Split tunneling et de fournir lip wan des users en délégation chez tes clients et pas une bonne pratique La meilleure serait de faire de lip sec en mode gateway avec un premier filtrage de la remediation du dns sec du proxy web et un bastion rdp qui lui est comme en local chez vous et que votre client n’autorise que le serveur netscaler ou Wallix derrière ou cyberhark Le mer. 29 mars 2023 à 16:43, DUVERGIER Claude a écrit : > Au vu des réponses, je comprends que j'ai mélangé différents points sans > être totalement clair alors je reprends avec plus de contexte. > > Dans le cadre de nos prestations des collègues sont amenés à travailler > (pendant quelques jours, semaines ou mois) sur les sites des clients > (production ou préproduction) et notamment se connecter au backoffice > web, ou serveur de stockage FTP. > > A. Parfois c'est un accès direct sans filtrage d'adresse IP. > B. Parfois c'est un accès direct mais uniquement autorisé depuis des > adresses IP préalablement déclarées. > C. Parfois c'est via un serveur bastion du client (j'ai eu les cas d'un > accès SSH et d'autres via RDP) dont l'accès et uniquement autorisé > depuis des adresses IP préalablement déclarées. > > Pour le cas A : aucun problème (sauf à la limite quand notre staff > télétravaille depuis des pays "exotiques" que le client aurait par > défaut bloqué de son côté : mais c'est rare). > > Pour les cas B et C : on communique au client les adresses IP publiques > qu'utilisent nos agences pour accéder à Internet, le client les autorise > et tout fonctionne (généralement pas du premier coup il est vrai :P). > > Mais quand le collègue est en télétravail il surfe via sa connexion > Internet personnelle et donc via une IP que le client ne connaît pas. > > Il pourrait communiquer son IP personnelle au client qui n'aurait qu'à > la rajouter : mais ça prends généralement du temps (le client doit > contacter son prestataire, etc.) et parfois le collègue n'a carrément > pas d'adresse IP fixe (certains FAI, ou les clients nomades en connexion > cellulaire). > > Alors, ce qu'on a fait dans un premier temps c'est mettre en place un > serveur proxy HTTP (Squid) dont l'accès à Internet passe par une des > adresses IP communiquées au client (le serveur est hébergé en local dans > nos locaux). Ça fonctionne pour l'HTTP, pas pour le FTP, SSH, RDP qui > sont des protocoles d'accès que certains clients nous demandent d'utiliser. > > Pour éviter d'ouvrir à tout vent ce serveur proxy, il n'est pas > accessible sur Internet : pour le contacter alors qu'on est en > télétravail/nomade on doit passer par notre service de VPN. > > Ce service VPN existait déjà avant ces problématique d'accès aux BO des > clients et réponds à un tout autre besoin : permettre aux > télétravailleurs/nomades d'accéder à certaines ressources locales (auto > hébergées) du SI de notre société. Et il est configuré pour que seul le > trafic destiné au LAN y arrive (avec l'exemple d'une vidéo YouTube > consultée pendant le télétravail qui ne passerait donc pas via le VPN). > > Mes solutions envisagées : > > * Trouver un outil qui "sache" proxyfier de l'HTTP, FTP, SSH, RDP, etc. > Un proxy en SOCKS5 peut faire tout ça ? > * Mettre en place, en interne, un bastion sous la forme d'un bureau > virtuel où l'utilisateur aurait navigateur web, client FTP/SSH/RDP > * Capter tout le trafic réseau via le tunnel VPN : ainsi les > collaborateurs apparaissent comme étant tout le temps "au bureau". > > Vu le nombre de prestation et la durée de celle-ci, je préfère avoir une > solution qui ne me demande pas de configuration dédiée à chaque besoin. > > Il existe évidemment plein de solutions techniques que le client > auraient pu mettre en place pour simplifier le tout (dans le style de > Boundary de HashiCorp, Envoy Proxy de Lyft, etc.) mais je dois > généralement composer avec ce qu'ils ont. > > Je me dis que je ne dois pas être le seul à avoir ces problématiques > d'accès filtrés aux ressources des clients ? Si ? > > -- > Duvergier Claude > > Le 29/03/2023 à 14:41, DUVERGIER Claude a écrit : > > Bonjour la liste, > > > > Certains de nos clients limitent les accès a leur SI (site en > > préproduction, backoffice web, serveur FTP, etc.) par adresse IPv4. > > > > On leur communique donc nos adresses IP publiques (celles pour l'accès > > à Internet), il les autorisent et voilà. > > > > Sauf qu'avec le télétravail, le staff qui travaille depuis leur > > connexion Internet personnelle n'utilisent pas l'une des adresse IP > > autorisée et sont donc bloqués. > > > > On a bien un service VPN qui perme
[FRnOG] [TECH] RFC 7337: CDN Interconnection Requirements
Bon, le cahier des charges est fini, ya plus qu'à terminer la spec' et développer. RFC 7337 : Content Distribution Network Interconnection (CDNI) Requirements http://www.bortzmeyer.org/7337.html Auteur(s) du RFC: K. Leung (Cisco), Y. Lee (Comcast) Le projet IETF CDNI (Content Delivery Network Interconnection) vise à permettre l'interconnexion de CDN, ces réseaux de serveurs répartis dans le monde qui servent à amortir la charge des serveurs Internet les plus populaires. CDNI a été expliqué dans le RFC 6707 et trois études de cas ont fait l'objet du RFC 6770. Ce troisième RFC du projet décrit les exigences formelles, le cahier des charges du projet. (Le cadre général de la solution technique adoptée est dans le RFC 7336.) Le projet est important car, aujourd'hui, les CDN ne coopèrent pas, en partie en raison du manque d'interfaces standards. Si un CDN très présent en Amérique veut s'associer avec un autre CDN fort en Europe, à la grande joie de leurs clients respectifs, qui auront ainsi un meilleur service dans les deux cas, ils doivent développer un système ad hoc. Le but de CDNI est de développer cette interface standard (RFC 7336), de manière à ce que plusieurs CDN puissent coopérer et apparaître à l'utilisateur comme un seul service. Dans le futur, une fois le projet complété, le CDN d'origine (« CDN amont ») pourra faire en sorte que le CDN qui l'aide (« CDN aval ») ait accès au même contenu et puisse le servir lui-même aux clients. Les exigences listées par ce cahier des charges sont classées par priorité : « haute » signifie que cette exigence est impérative, même si elle est compliquée à réaliser, « moyenne » que l'exigence est importante, qu'elle doit être satisfaite sauf si, par sa complexité, elle entraîne un retard dans le projet et, enfin, « basse » est utilisé pour les exigences certes utiles mais pas nécessaires au projet. Les exigences sont rangées selon l'interface à laquelle elles s'applique. Une interface (RFC 7336) est un ensemble de fonctions du CDN, qu'on peut appeler en utilisant des mécanismes normalisés, et qui correspondent à un ensemble de services proches. Par exemple, LI (Logging Interface) regroupe les services de journalisation, permettant à un CDN amont d'avoir des informations sur l'activité d'un CDN aval associé. Je ne vais pas ici recopier les nombreuses exigences, me focalisant sur celles de niveau élevé, donc impératives à satisfaire. D'abord, en section 3, les exigences générales, indépendantes de l'interface. La solution ne doit évidemment pas nécessiter de changer les clients (exigence GEN-2), par exemple les navigateurs Web. Elle ne doit pas nécessiter que le fournisseur de contenu change son système de publication (GEN-3) : si celui-ci permet de publier dans un CDN, il doit permettre de profiter de l'interconnexion. Elle doit être assez abstraite pour que chaque CDN soit une « boîte noire » pour les autres, sans avoir besoin de publier de l'information interne. Elle doit marcher au moins lorsque la délivrance au client est faite en HTTP (exigence GEN-5, il existe d'autres protocoles - voir GEN-7 - mais moins cruciaux), et elle doit éviter de créer des boucles entre CDN et elle doit fonctionner même quand les références à une tierce partie sont cassées (exigence GEN-12), par exemple à cause du NAT ou du split DNS. Suivent en section 4 les exigences pour la CI. CI (Control Interface) est l'interface qui contrôle les autres interfaces, par exemple pour les opérations de démarrage. Elle doit permettre au CDN amont de demander le nettoyage (la destruction de contenu, exigence CI-1), et elle doit fournir un mécanisme de rétroaction par lequel le CDN aval informe le CDN amont de ce qu'il a fait (CI-4). En section 5, la RI (Request routing indirection Interface) est l'interface vers le système de routage des requêtes. Elle doit fonctionner rapidement quelle que soit la taille du contenu (exigence RI-1) ce qui veut dire qu'il faut un mécanisme de redirection ultra-léger pour les objets de petite taille (ceux où le temps de redirection risque de dépasser le temps de transfert des données), et qu'il faut pouvoir choisir le compromis entre fraîcheur des données et rapidité. Pour les gros objets (exigence RI-2) où le temps de transfert sera long, il faut bien choisir le CDN d'où il sera servi et il faut donc que la solution permette un choix précis, lié aux caractéristiques de la requête. Autrement dit, un mode où on passe du temps à sélectionner la source des données, pour que le transfert aille ensuite plus vite. Il faut aussi que cette redirection puisse être récursive (exigence RI-3), c'est-à-dire que la cible d'une redirection va elle-même suivre les éventuelles nouvelles redirections, et itérative (RI-4), c'est-à-dire que l'initiateur suive lui même les redirections multiples. Cela implique que le CDN aval reçoive du CDN amont toutes les
Re: [FRnOG] [TECH] IP Nat sur Cisco
Tu peux pas, vlan102 a déjà ip nat inside, tu peux pas mettre ip nat outside en plus. C’est justement là qu’il faut utiliser le NAT NVI et son: ip nat enable magique. Et là, tout se joue sur les ACL que tu utilises pour le NAT donc attention… Et NAT NVI évidemment n’est pas disponible sur toutes les plateformes (pas sur ASR par exemple). > Le 8 avr. 2016 à 14:23, Antoine Durant <antoine.duran...@yahoo.fr > <mailto:antoine.duran...@yahoo.fr>> a écrit : > > J'ai déjà mal à la tête en fait...Si j'ajoute une règle de NAT entre vlan101 > et vlan102 ca va passer ? > > NAT NVI je ne connais pas je vais regarder Google ! > > > De : David Ponzone <david.ponz...@gmail.com <mailto:david.ponz...@gmail.com>> > À : Antoine Durant <antoine.duran...@yahoo.fr > <mailto:antoine.duran...@yahoo.fr>> > Cc : "frnog-t...@frnog.org <mailto:frnog-t...@frnog.org>" > <frnog-t...@frnog.org <mailto:frnog-t...@frnog.org>> > Envoyé le : Vendredi 8 avril 2016 14h13 > Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco > > Ton problème est vieux comme le monde :) > Ca s’appelle le NAT HAIRPINNING. > > Quand le paquet venant de 192.168.1.1 vers 1.1.1.1 rencontre la règle de NAT > 1-to-1: > ip nat inside source static 10.0.1.1 1.1.1.1 extendable > L’IP Source du paquet est à ce moment là 10.0.1.5 (NAT sur R2). > l’IP destination du paquet va être modifiée pour 10.0.1.1 (R1) qui à son tour > va le modifier en 192.168.1.1 (server0). > Le paquet retour va partir de 192.168.1.1 (server0) à destination de > 10.0.1.5, R1 va changer l’IP source en 10.0.1.1. > Puis ROUTEUR-NAT ne va rien faire à l’IP SOURCE car tu n’a pas de NAT de > VLAN101 vers VLAN102. > Donc ton PC va recevoir une réponse qui vient de 10.0.1.1 alors qu’il avait > envoyé un paquet à 1.1.1.1. > > En fait, c’est le problème fondamental qui consiste à accéder à une IP > publique qui donne accès à une ressource interne grâce à du NAT, en étant > soi-même pas de l’autre côté du NAT, mais en interne. > > Prends de l’aspirine et: > > https://supportforums.cisco.com/discussion/12102421/nat-hairpinning > <https://supportforums.cisco.com/discussion/12102421/nat-hairpinning> > > Pour moi tu as 2 solutions: > -DNS split-horizon > -ou utilise le NAT NVI sur les Cisco, mais va falloir encore un peu > d’aspirine pour par pondre une grosse bouse > > > > Le 8 avr. 2016 à 13:43, Antoine Durant <antoine.duran...@yahoo.fr > > <mailto:antoine.duran...@yahoo.fr>> a écrit : > > > > Bonjour David, > > > > Je comprend ta remarque et me doute bien que vous avez tous des > > occupations. J'ai cherché mais en vain, c'est pour cela que je m'adresse à > > frnog pour avoir un coup de pouce... > > > > Voici le schéma : http://hpics.li/82254e6 > > <http://hpics.li/82254e6><http://hpics.li/82254e6 <http://hpics.li/82254e6>> > > > > Depuis PC0 je peux ouvrir l'url 1.1.1.1:80 situé sur le serveur 192.168.1.1 > > connecté derrière R1, donc le NAT/access-list fonctionne. > > > > Le problème est que lorsque depuis Laptop0 connecté derrière R2 j'essaye > > d'ouvrir l'url 1.1.1.1:80 cela ne fonctionne pas. Le problème est à mon > > avis situé dans ma conf du routeur ROUTEUR-NAT, mais je n'arrive pas à > > résoudre ça :( > > > > Merci d'avance à tous. > > > > > > > > De : David Ponzone <david.ponz...@gmail.com > > <mailto:david.ponz...@gmail.com>> > > À : Antoine Durant <antoine.duran...@yahoo.fr > > <mailto:antoine.duran...@yahoo.fr>> > > Cc : "frnog-t...@frnog.org <mailto:frnog-t...@frnog.org>" > > <frnog-t...@frnog.org <mailto:frnog-t...@frnog.org>> > > Envoyé le : Vendredi 8 avril 2016 12h48 > > Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco > > > > Antoine, > > > > je pense que plusieurs sur cette liste pourront te régler ce problème en > > 3/5 minutes max, mais ils ont comme beaucoup un métier et un patron (ou pas > > de patron, mais des clients et une femme, ou pas de patron, pas de femme, > > pas de clients, mais un banquier, etc….) et donc s’il faut se plonger dans > > tes confs pour comprendre l’archi, ça prend tout de suite un peu plus de > > temps. > > > > Tu peux juste détailler un peu mieux qui est connecté à quoi, par un petit > > schéma par exemple ? > > > > > > > Le 8 avr. 2016 à 11:32, Antoine Durant <antoine.duran...@yahoo.fr > > > <mailto:antoine.duran...@yahoo.fr> <mailto:antoine.duran...@yahoo.fr > > > <mailto:antoine.duran...@yahoo.fr>
Re: [FRnOG] [TECH] IP Nat sur Cisco
Bonjour Xavier, Je vais dans un premier temps éviter le VPN, je suis en train de regarder NAT NVI comme suggéré par David...mais c'est assez compliqué au premier abord... Je vais avoir besoin de plusieurs boites d'aspirines !!! De : Xavier ROCA <x.r...@sdi.fr> À : frnog-t...@frnog.org Envoyé le : Vendredi 8 avril 2016 15h04 Objet : RE: [FRnOG] [TECH] IP Nat sur Cisco Bonjour, Je ne sais pas ton objectif final donc voici une idée mais pas forcément adaptée mais relativement simple. VPN entre R1 et R2. Puis un double NAT sur R1 et R2 pour passer par le VPN, ca le fait. Xavier -Message d'origine- De : Antoine Durant [mailto:antoine.duran...@yahoo.fr] Envoyé : vendredi 8 avril 2016 14:23 À : David Ponzone Cc : frnog-t...@frnog.org Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco J'ai déjà mal à la tête en fait...Si j'ajoute une règle de NAT entre vlan101 et vlan102 ca va passer ? NAT NVI je ne connais pas je vais regarder Google ! De : David Ponzone <david.ponz...@gmail.com> À : Antoine Durant <antoine.duran...@yahoo.fr> Cc : "frnog-t...@frnog.org" <frnog-t...@frnog.org> Envoyé le : Vendredi 8 avril 2016 14h13 Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco Ton problème est vieux comme le monde :) Ca s’appelle le NAT HAIRPINNING. Quand le paquet venant de 192.168.1.1 vers 1.1.1.1 rencontre la règle de NAT 1-to-1: ip nat inside source static 10.0.1.1 1.1.1.1 extendable L’IP Source du paquet est à ce moment là 10.0.1.5 (NAT sur R2). l’IP destination du paquet va être modifiée pour 10.0.1.1 (R1) qui à son tour va le modifier en 192.168.1.1 (server0). Le paquet retour va partir de 192.168.1.1 (server0) à destination de 10.0.1.5, R1 va changer l’IP source en 10.0.1.1. Puis ROUTEUR-NAT ne va rien faire à l’IP SOURCE car tu n’a pas de NAT de VLAN101 vers VLAN102. Donc ton PC va recevoir une réponse qui vient de 10.0.1.1 alors qu’il avait envoyé un paquet à 1.1.1.1. En fait, c’est le problème fondamental qui consiste à accéder à une IP publique qui donne accès à une ressource interne grâce à du NAT, en étant soi-même pas de l’autre côté du NAT, mais en interne. Prends de l’aspirine et: https://supportforums.cisco.com/discussion/12102421/nat-hairpinning Pour moi tu as 2 solutions: -DNS split-horizon -ou utilise le NAT NVI sur les Cisco, mais va falloir encore un peu d’aspirine pour par pondre une grosse bouse > Le 8 avr. 2016 à 13:43, Antoine Durant <antoine.duran...@yahoo.fr> a écrit : > > Bonjour David, > > Je comprend ta remarque et me doute bien que vous avez tous des occupations. > J'ai cherché mais en vain, c'est pour cela que je m'adresse à frnog pour > avoir un coup de pouce... > > Voici le schéma : http://hpics.li/82254e6<http://hpics.li/82254e6> > > Depuis PC0 je peux ouvrir l'url 1.1.1.1:80 situé sur le serveur 192.168.1.1 > connecté derrière R1, donc le NAT/access-list fonctionne. > > Le problème est que lorsque depuis Laptop0 connecté derrière R2 > j'essaye d'ouvrir l'url 1.1.1.1:80 cela ne fonctionne pas. Le problème > est à mon avis situé dans ma conf du routeur ROUTEUR-NAT, mais je > n'arrive pas à résoudre ça :( > > Merci d'avance à tous. > > > > De : David Ponzone <david.ponz...@gmail.com> À : Antoine Durant > <antoine.duran...@yahoo.fr> Cc : "frnog-t...@frnog.org" > <frnog-t...@frnog.org> Envoyé le : Vendredi 8 avril 2016 12h48 Objet : > Re: [FRnOG] [TECH] IP Nat sur Cisco > > Antoine, > > je pense que plusieurs sur cette liste pourront te régler ce problème en 3/5 > minutes max, mais ils ont comme beaucoup un métier et un patron (ou pas de > patron, mais des clients et une femme, ou pas de patron, pas de femme, pas de > clients, mais un banquier, etc….) et donc s’il faut se plonger dans tes confs > pour comprendre l’archi, ça prend tout de suite un peu plus de temps. > > Tu peux juste détailler un peu mieux qui est connecté à quoi, par un petit > schéma par exemple ? > > > > Le 8 avr. 2016 à 11:32, Antoine Durant <antoine.duran...@yahoo.fr > > <mailto:antoine.duran...@yahoo.fr>> a écrit : > > > > Bonjour,J'essaye de reproduire un réseau en employant du NAT, j'ai 4 > > routeurs pour le test : > > ROUTEUR-TEST => Une machine est derrière lui (1.1.1.10) > > : > > ROUTEUR-NAT => Celui interconnecte deux autres routeurs R1/R2 > > :R1 => LAN_1 > > :R2 => LAN_2 > > Depuis une machine (1.1.1.10) sur le ROUTEUR-TEST j'arrive à acceder au > > serveur web (1.1.1.1) branché derrière le routeur R1. Maintenant je > > voudrais accéder au serveur web 1.1.1.1 depuis le LAN_2 du routeur R2 qui > > doit sortir via 1.1.1.2. > > Cela ne fonctionne pas, je n'arrive pas à trouver le bon réglage sur ip nat > > insid
RE: [FRnOG] [TECH] IP Nat sur Cisco
Bonjour, Je ne sais pas ton objectif final donc voici une idée mais pas forcément adaptée mais relativement simple. VPN entre R1 et R2. Puis un double NAT sur R1 et R2 pour passer par le VPN, ca le fait. Xavier -Message d'origine- De : Antoine Durant [mailto:antoine.duran...@yahoo.fr] Envoyé : vendredi 8 avril 2016 14:23 À : David Ponzone Cc : frnog-t...@frnog.org Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco J'ai déjà mal à la tête en fait...Si j'ajoute une règle de NAT entre vlan101 et vlan102 ca va passer ? NAT NVI je ne connais pas je vais regarder Google ! De : David Ponzone <david.ponz...@gmail.com> À : Antoine Durant <antoine.duran...@yahoo.fr> Cc : "frnog-t...@frnog.org" <frnog-t...@frnog.org> Envoyé le : Vendredi 8 avril 2016 14h13 Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco Ton problème est vieux comme le monde :) Ca s’appelle le NAT HAIRPINNING. Quand le paquet venant de 192.168.1.1 vers 1.1.1.1 rencontre la règle de NAT 1-to-1: ip nat inside source static 10.0.1.1 1.1.1.1 extendable L’IP Source du paquet est à ce moment là 10.0.1.5 (NAT sur R2). l’IP destination du paquet va être modifiée pour 10.0.1.1 (R1) qui à son tour va le modifier en 192.168.1.1 (server0). Le paquet retour va partir de 192.168.1.1 (server0) à destination de 10.0.1.5, R1 va changer l’IP source en 10.0.1.1. Puis ROUTEUR-NAT ne va rien faire à l’IP SOURCE car tu n’a pas de NAT de VLAN101 vers VLAN102. Donc ton PC va recevoir une réponse qui vient de 10.0.1.1 alors qu’il avait envoyé un paquet à 1.1.1.1. En fait, c’est le problème fondamental qui consiste à accéder à une IP publique qui donne accès à une ressource interne grâce à du NAT, en étant soi-même pas de l’autre côté du NAT, mais en interne. Prends de l’aspirine et: https://supportforums.cisco.com/discussion/12102421/nat-hairpinning Pour moi tu as 2 solutions: -DNS split-horizon -ou utilise le NAT NVI sur les Cisco, mais va falloir encore un peu d’aspirine pour par pondre une grosse bouse > Le 8 avr. 2016 à 13:43, Antoine Durant <antoine.duran...@yahoo.fr> a écrit : > > Bonjour David, > > Je comprend ta remarque et me doute bien que vous avez tous des occupations. > J'ai cherché mais en vain, c'est pour cela que je m'adresse à frnog pour > avoir un coup de pouce... > > Voici le schéma : http://hpics.li/82254e6<http://hpics.li/82254e6> > > Depuis PC0 je peux ouvrir l'url 1.1.1.1:80 situé sur le serveur 192.168.1.1 > connecté derrière R1, donc le NAT/access-list fonctionne. > > Le problème est que lorsque depuis Laptop0 connecté derrière R2 > j'essaye d'ouvrir l'url 1.1.1.1:80 cela ne fonctionne pas. Le problème > est à mon avis situé dans ma conf du routeur ROUTEUR-NAT, mais je > n'arrive pas à résoudre ça :( > > Merci d'avance à tous. > > > > De : David Ponzone <david.ponz...@gmail.com> À : Antoine Durant > <antoine.duran...@yahoo.fr> Cc : "frnog-t...@frnog.org" > <frnog-t...@frnog.org> Envoyé le : Vendredi 8 avril 2016 12h48 Objet : > Re: [FRnOG] [TECH] IP Nat sur Cisco > > Antoine, > > je pense que plusieurs sur cette liste pourront te régler ce problème en 3/5 > minutes max, mais ils ont comme beaucoup un métier et un patron (ou pas de > patron, mais des clients et une femme, ou pas de patron, pas de femme, pas de > clients, mais un banquier, etc….) et donc s’il faut se plonger dans tes confs > pour comprendre l’archi, ça prend tout de suite un peu plus de temps. > > Tu peux juste détailler un peu mieux qui est connecté à quoi, par un petit > schéma par exemple ? > > > > Le 8 avr. 2016 à 11:32, Antoine Durant <antoine.duran...@yahoo.fr > > <mailto:antoine.duran...@yahoo.fr>> a écrit : > > > > Bonjour,J'essaye de reproduire un réseau en employant du NAT, j'ai 4 > > routeurs pour le test : > > ROUTEUR-TEST => Une machine est derrière lui (1.1.1.10) > > : > > ROUTEUR-NAT => Celui interconnecte deux autres routeurs R1/R2 > > :R1 => LAN_1 > > :R2 => LAN_2 > > Depuis une machine (1.1.1.10) sur le ROUTEUR-TEST j'arrive à acceder au > > serveur web (1.1.1.1) branché derrière le routeur R1. Maintenant je > > voudrais accéder au serveur web 1.1.1.1 depuis le LAN_2 du routeur R2 qui > > doit sortir via 1.1.1.2. > > Cela ne fonctionne pas, je n'arrive pas à trouver le bon réglage sur ip nat > > inside/access-list. > > Une petite idée ? j'ai épuisé toute mes solutions... Merci > >ROUTEUR-TEST > > interface FastEthernet4 > > ip address 172.16.3.30 255.255.255.252 > > no ip redirects > > no ip unreachables > > no ip proxy-arp > > duplex auto > > speed auto > > ! > > interface Vlan1 > > ip
Re: [FRnOG] [TECH] IP Nat sur Cisco
Ton problème est vieux comme le monde :) Ca s’appelle le NAT HAIRPINNING. Quand le paquet venant de 192.168.1.1 vers 1.1.1.1 rencontre la règle de NAT 1-to-1: ip nat inside source static 10.0.1.1 1.1.1.1 extendable L’IP Source du paquet est à ce moment là 10.0.1.5 (NAT sur R2). l’IP destination du paquet va être modifiée pour 10.0.1.1 (R1) qui à son tour va le modifier en 192.168.1.1 (server0). Le paquet retour va partir de 192.168.1.1 (server0) à destination de 10.0.1.5, R1 va changer l’IP source en 10.0.1.1. Puis ROUTEUR-NAT ne va rien faire à l’IP SOURCE car tu n’a pas de NAT de VLAN101 vers VLAN102. Donc ton PC va recevoir une réponse qui vient de 10.0.1.1 alors qu’il avait envoyé un paquet à 1.1.1.1. En fait, c’est le problème fondamental qui consiste à accéder à une IP publique qui donne accès à une ressource interne grâce à du NAT, en étant soi-même pas de l’autre côté du NAT, mais en interne. Prends de l’aspirine et: https://supportforums.cisco.com/discussion/12102421/nat-hairpinning Pour moi tu as 2 solutions: -DNS split-horizon -ou utilise le NAT NVI sur les Cisco, mais va falloir encore un peu d’aspirine pour par pondre une grosse bouse > Le 8 avr. 2016 à 13:43, Antoine Durant <antoine.duran...@yahoo.fr> a écrit : > > Bonjour David, > > Je comprend ta remarque et me doute bien que vous avez tous des occupations. > J'ai cherché mais en vain, c'est pour cela que je m'adresse à frnog pour > avoir un coup de pouce... > > Voici le schéma : http://hpics.li/82254e6 <http://hpics.li/82254e6> > > Depuis PC0 je peux ouvrir l'url 1.1.1.1:80 situé sur le serveur 192.168.1.1 > connecté derrière R1, donc le NAT/access-list fonctionne. > > Le problème est que lorsque depuis Laptop0 connecté derrière R2 j'essaye > d'ouvrir l'url 1.1.1.1:80 cela ne fonctionne pas. Le problème est à mon avis > situé dans ma conf du routeur ROUTEUR-NAT, mais je n'arrive pas à résoudre ça > :( > > Merci d'avance à tous. > > > > De : David Ponzone <david.ponz...@gmail.com> > À : Antoine Durant <antoine.duran...@yahoo.fr> > Cc : "frnog-t...@frnog.org" <frnog-t...@frnog.org> > Envoyé le : Vendredi 8 avril 2016 12h48 > Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco > > Antoine, > > je pense que plusieurs sur cette liste pourront te régler ce problème en 3/5 > minutes max, mais ils ont comme beaucoup un métier et un patron (ou pas de > patron, mais des clients et une femme, ou pas de patron, pas de femme, pas de > clients, mais un banquier, etc….) et donc s’il faut se plonger dans tes confs > pour comprendre l’archi, ça prend tout de suite un peu plus de temps. > > Tu peux juste détailler un peu mieux qui est connecté à quoi, par un petit > schéma par exemple ? > > > > Le 8 avr. 2016 à 11:32, Antoine Durant <antoine.duran...@yahoo.fr > > <mailto:antoine.duran...@yahoo.fr>> a écrit : > > > > Bonjour,J'essaye de reproduire un réseau en employant du NAT, j'ai 4 > > routeurs pour le test : > > ROUTEUR-TEST => Une machine est derrière lui (1.1.1.10) > > : > > ROUTEUR-NAT => Celui interconnecte deux autres routeurs R1/R2 > > :R1 => LAN_1 > > :R2 => LAN_2 > > Depuis une machine (1.1.1.10) sur le ROUTEUR-TEST j'arrive à acceder au > > serveur web (1.1.1.1) branché derrière le routeur R1. Maintenant je > > voudrais accéder au serveur web 1.1.1.1 depuis le LAN_2 du routeur R2 qui > > doit sortir via 1.1.1.2. > > Cela ne fonctionne pas, je n'arrive pas à trouver le bon réglage sur ip nat > > inside/access-list. > > Une petite idée ? j'ai épuisé toute mes solutions... Merci > > ROUTEUR-TEST > > interface FastEthernet4 > > ip address 172.16.3.30 255.255.255.252 > > no ip redirects > > no ip unreachables > > no ip proxy-arp > > duplex auto > > speed auto > > ! > > interface Vlan1 > > ip address 1.1.1.100 255.255.255.128 > > ! > > ip forward-protocol nd > > no ip http server > > no ip http secure-server > > ! > > ip route 1.1.1.1 255.255.255.255 172.16.3.29 > > ip route 1.1.1.2 255.255.255.255 172.16.3.29 > > ROUTEUR-NAT > > interface Loopback0 > > ip address 1.1.1.1 255.255.255.255 > > ! > > interface Loopback1 > > ip address 1.1.1.2 255.255.255.255 > > ! > > interface FastEthernet0 > > description * UPLINK R1 * > > switchport access vlan 101 > > no ip address > > ! > > interface FastEthernet1 > > description * UPLINK R2 * > > switchport access vlan 102 > > no ip address > > ! > > interface FastEthernet4 > > description ** UPLINK ROUTEUR-TEST ** > > ip a
Re: [FRnOG] [TECH] IP Nat sur Cisco
Tu peux pas, vlan102 a déjà ip nat inside, tu peux pas mettre ip nat outside en plus. C’est justement là qu’il faut utiliser le NAT NVI et son: ip nat enable magique. Et là, tout se joue sur les ACL que tu utilises pour le NAT donc attention… Et NAT NVI évidemment n’est pas disponible sur toutes les plateformes (pas sur ASR par exemple). > Le 8 avr. 2016 à 14:23, Antoine Durant <antoine.duran...@yahoo.fr> a écrit : > > J'ai déjà mal à la tête en fait...Si j'ajoute une règle de NAT entre vlan101 > et vlan102 ca va passer ? > > NAT NVI je ne connais pas je vais regarder Google ! > > > De : David Ponzone <david.ponz...@gmail.com> > À : Antoine Durant <antoine.duran...@yahoo.fr> > Cc : "frnog-t...@frnog.org" <frnog-t...@frnog.org> > Envoyé le : Vendredi 8 avril 2016 14h13 > Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco > > Ton problème est vieux comme le monde :) > Ca s’appelle le NAT HAIRPINNING. > > Quand le paquet venant de 192.168.1.1 vers 1.1.1.1 rencontre la règle de NAT > 1-to-1: > ip nat inside source static 10.0.1.1 1.1.1.1 extendable > L’IP Source du paquet est à ce moment là 10.0.1.5 (NAT sur R2). > l’IP destination du paquet va être modifiée pour 10.0.1.1 (R1) qui à son tour > va le modifier en 192.168.1.1 (server0). > Le paquet retour va partir de 192.168.1.1 (server0) à destination de > 10.0.1.5, R1 va changer l’IP source en 10.0.1.1. > Puis ROUTEUR-NAT ne va rien faire à l’IP SOURCE car tu n’a pas de NAT de > VLAN101 vers VLAN102. > Donc ton PC va recevoir une réponse qui vient de 10.0.1.1 alors qu’il avait > envoyé un paquet à 1.1.1.1. > > En fait, c’est le problème fondamental qui consiste à accéder à une IP > publique qui donne accès à une ressource interne grâce à du NAT, en étant > soi-même pas de l’autre côté du NAT, mais en interne. > > Prends de l’aspirine et: > > https://supportforums.cisco.com/discussion/12102421/nat-hairpinning > <https://supportforums.cisco.com/discussion/12102421/nat-hairpinning> > > Pour moi tu as 2 solutions: > -DNS split-horizon > -ou utilise le NAT NVI sur les Cisco, mais va falloir encore un peu > d’aspirine pour par pondre une grosse bouse > > > > Le 8 avr. 2016 à 13:43, Antoine Durant <antoine.duran...@yahoo.fr > > <mailto:antoine.duran...@yahoo.fr>> a écrit : > > > > Bonjour David, > > > > Je comprend ta remarque et me doute bien que vous avez tous des > > occupations. J'ai cherché mais en vain, c'est pour cela que je m'adresse à > > frnog pour avoir un coup de pouce... > > > > Voici le schéma : http://hpics.li/82254e6 > > <http://hpics.li/82254e6><http://hpics.li/82254e6 <http://hpics.li/82254e6>> > > > > Depuis PC0 je peux ouvrir l'url 1.1.1.1:80 situé sur le serveur 192.168.1.1 > > connecté derrière R1, donc le NAT/access-list fonctionne. > > > > Le problème est que lorsque depuis Laptop0 connecté derrière R2 j'essaye > > d'ouvrir l'url 1.1.1.1:80 cela ne fonctionne pas. Le problème est à mon > > avis situé dans ma conf du routeur ROUTEUR-NAT, mais je n'arrive pas à > > résoudre ça :( > > > > Merci d'avance à tous. > > > > > > > > De : David Ponzone <david.ponz...@gmail.com > > <mailto:david.ponz...@gmail.com>> > > À : Antoine Durant <antoine.duran...@yahoo.fr > > <mailto:antoine.duran...@yahoo.fr>> > > Cc : "frnog-t...@frnog.org <mailto:frnog-t...@frnog.org>" > > <frnog-t...@frnog.org <mailto:frnog-t...@frnog.org>> > > Envoyé le : Vendredi 8 avril 2016 12h48 > > Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco > > > > Antoine, > > > > je pense que plusieurs sur cette liste pourront te régler ce problème en > > 3/5 minutes max, mais ils ont comme beaucoup un métier et un patron (ou pas > > de patron, mais des clients et une femme, ou pas de patron, pas de femme, > > pas de clients, mais un banquier, etc….) et donc s’il faut se plonger dans > > tes confs pour comprendre l’archi, ça prend tout de suite un peu plus de > > temps. > > > > Tu peux juste détailler un peu mieux qui est connecté à quoi, par un petit > > schéma par exemple ? > > > > > > > Le 8 avr. 2016 à 11:32, Antoine Durant <antoine.duran...@yahoo.fr > > > <mailto:antoine.duran...@yahoo.fr> <mailto:antoine.duran...@yahoo.fr > > > <mailto:antoine.duran...@yahoo.fr>>> a écrit : > > > > > > Bonjour,J'essaye de reproduire un réseau en employant du NAT, j'ai 4 > > > routeurs pour le test : > > > ROUTEUR-TEST => Une
Re: [FRnOG] [TECH] IP Nat sur Cisco
J'ai déjà mal à la tête en fait...Si j'ajoute une règle de NAT entre vlan101 et vlan102 ca va passer ? NAT NVI je ne connais pas je vais regarder Google ! De : David Ponzone <david.ponz...@gmail.com> À : Antoine Durant <antoine.duran...@yahoo.fr> Cc : "frnog-t...@frnog.org" <frnog-t...@frnog.org> Envoyé le : Vendredi 8 avril 2016 14h13 Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco Ton problème est vieux comme le monde :) Ca s’appelle le NAT HAIRPINNING. Quand le paquet venant de 192.168.1.1 vers 1.1.1.1 rencontre la règle de NAT 1-to-1: ip nat inside source static 10.0.1.1 1.1.1.1 extendable L’IP Source du paquet est à ce moment là 10.0.1.5 (NAT sur R2). l’IP destination du paquet va être modifiée pour 10.0.1.1 (R1) qui à son tour va le modifier en 192.168.1.1 (server0). Le paquet retour va partir de 192.168.1.1 (server0) à destination de 10.0.1.5, R1 va changer l’IP source en 10.0.1.1. Puis ROUTEUR-NAT ne va rien faire à l’IP SOURCE car tu n’a pas de NAT de VLAN101 vers VLAN102. Donc ton PC va recevoir une réponse qui vient de 10.0.1.1 alors qu’il avait envoyé un paquet à 1.1.1.1. En fait, c’est le problème fondamental qui consiste à accéder à une IP publique qui donne accès à une ressource interne grâce à du NAT, en étant soi-même pas de l’autre côté du NAT, mais en interne. Prends de l’aspirine et: https://supportforums.cisco.com/discussion/12102421/nat-hairpinning Pour moi tu as 2 solutions: -DNS split-horizon -ou utilise le NAT NVI sur les Cisco, mais va falloir encore un peu d’aspirine pour par pondre une grosse bouse > Le 8 avr. 2016 à 13:43, Antoine Durant <antoine.duran...@yahoo.fr> a écrit : > > Bonjour David, > > Je comprend ta remarque et me doute bien que vous avez tous des occupations. > J'ai cherché mais en vain, c'est pour cela que je m'adresse à frnog pour > avoir un coup de pouce... > > Voici le schéma : http://hpics.li/82254e6<http://hpics.li/82254e6> > > Depuis PC0 je peux ouvrir l'url 1.1.1.1:80 situé sur le serveur 192.168.1.1 > connecté derrière R1, donc le NAT/access-list fonctionne. > > Le problème est que lorsque depuis Laptop0 connecté derrière R2 j'essaye > d'ouvrir l'url 1.1.1.1:80 cela ne fonctionne pas. Le problème est à mon avis > situé dans ma conf du routeur ROUTEUR-NAT, mais je n'arrive pas à résoudre ça > :( > > Merci d'avance à tous. > > > > De : David Ponzone <david.ponz...@gmail.com> > À : Antoine Durant <antoine.duran...@yahoo.fr> > Cc : "frnog-t...@frnog.org" <frnog-t...@frnog.org> > Envoyé le : Vendredi 8 avril 2016 12h48 > Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco > > Antoine, > > je pense que plusieurs sur cette liste pourront te régler ce problème en 3/5 > minutes max, mais ils ont comme beaucoup un métier et un patron (ou pas de > patron, mais des clients et une femme, ou pas de patron, pas de femme, pas de > clients, mais un banquier, etc….) et donc s’il faut se plonger dans tes confs > pour comprendre l’archi, ça prend tout de suite un peu plus de temps. > > Tu peux juste détailler un peu mieux qui est connecté à quoi, par un petit > schéma par exemple ? > > > > Le 8 avr. 2016 à 11:32, Antoine Durant <antoine.duran...@yahoo.fr > > <mailto:antoine.duran...@yahoo.fr>> a écrit : > > > > Bonjour,J'essaye de reproduire un réseau en employant du NAT, j'ai 4 > > routeurs pour le test : > > ROUTEUR-TEST => Une machine est derrière lui (1.1.1.10) > > : > > ROUTEUR-NAT => Celui interconnecte deux autres routeurs R1/R2 > > :R1 => LAN_1 > > :R2 => LAN_2 > > Depuis une machine (1.1.1.10) sur le ROUTEUR-TEST j'arrive à acceder au > > serveur web (1.1.1.1) branché derrière le routeur R1. Maintenant je > > voudrais accéder au serveur web 1.1.1.1 depuis le LAN_2 du routeur R2 qui > > doit sortir via 1.1.1.2. > > Cela ne fonctionne pas, je n'arrive pas à trouver le bon réglage sur ip nat > > inside/access-list. > > Une petite idée ? j'ai épuisé toute mes solutions... Merci > > ROUTEUR-TEST > > interface FastEthernet4 > > ip address 172.16.3.30 255.255.255.252 > > no ip redirects > > no ip unreachables > > no ip proxy-arp > > duplex auto > > speed auto > > ! > > interface Vlan1 > > ip address 1.1.1.100 255.255.255.128 > > ! > > ip forward-protocol nd > > no ip http server > > no ip http secure-server > > ! > > ip route 1.1.1.1 255.255.255.255 172.16.3.29 > > ip route 1.1.1.2 255.255.255.255 172.16.3.29 > > ROUTEUR-NAT > > interface Loopback0 > > ip address 1.1.1.1 255.255.255.255 > > ! > > interface Loopback1 > > ip addr
Re: [FRnOG] [TECH] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, …) pour le staff en télétravail ?
Bonjour, Regarde coté SOFTETHER en mettant des Bridges chez vos clients vous pouvez rebondir de façon sécurise via VPN IPSEC L2TP. Je t'invite a lire la DOC de Softether pour mieux comprendre, l'avantage c'est simple a mettre en place et tu as une gestion d’accès via utilisateur. De plus c'est gratuit: SoftEther VPN is one of the most powerful and easiest VPN software in the world. It is freeware, developed as an academic research project in University of Tsukuba, Japan. Bon VPN. - Mail original - De: "sofiane JALID" À: "DUVERGIER Claude" , "frnog-tech" Envoyé: Mercredi 29 Mars 2023 10:53:56 Objet: Re: [FRnOG] [TECH] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, …) pour le staff en télétravail ? Je dis cela d’avance car si vous avez une PSSI lideal est de faire de la rétention de logs chez vous avant même d’aller sur les serveurs de vos clients. Ce qui vous permets de faire un premier niveau de cloisonnement etc … Tu peux utiliser un ipsec plus du proxy ssl avec double authentification pour que les flux match avec un groupe ou un users par exemple et autoriser dans ton ipsec uniquement le bastion qui lui a les flux vers ton client. Le mer. 29 mars 2023 à 16:48, sofiane JALID a écrit : > Tu as plusieurs choix qui s’offrent à toi mais l’idée de faire du Split > tunneling et de fournir lip wan des users en délégation chez tes clients et > pas une bonne pratique > > La meilleure serait de faire de lip sec en mode gateway avec un premier > filtrage de la remediation du dns sec du proxy web et un bastion rdp qui > lui est comme en local chez vous et que votre client n’autorise que le > serveur netscaler ou Wallix derrière ou cyberhark > > > > Le mer. 29 mars 2023 à 16:43, DUVERGIER Claude < > frnog...@claude.duvergier.fr> a écrit : > >> Au vu des réponses, je comprends que j'ai mélangé différents points sans >> être totalement clair alors je reprends avec plus de contexte. >> >> Dans le cadre de nos prestations des collègues sont amenés à travailler >> (pendant quelques jours, semaines ou mois) sur les sites des clients >> (production ou préproduction) et notamment se connecter au backoffice >> web, ou serveur de stockage FTP. >> >> A. Parfois c'est un accès direct sans filtrage d'adresse IP. >> B. Parfois c'est un accès direct mais uniquement autorisé depuis des >> adresses IP préalablement déclarées. >> C. Parfois c'est via un serveur bastion du client (j'ai eu les cas d'un >> accès SSH et d'autres via RDP) dont l'accès et uniquement autorisé >> depuis des adresses IP préalablement déclarées. >> >> Pour le cas A : aucun problème (sauf à la limite quand notre staff >> télétravaille depuis des pays "exotiques" que le client aurait par >> défaut bloqué de son côté : mais c'est rare). >> >> Pour les cas B et C : on communique au client les adresses IP publiques >> qu'utilisent nos agences pour accéder à Internet, le client les autorise >> et tout fonctionne (généralement pas du premier coup il est vrai :P). >> >> Mais quand le collègue est en télétravail il surfe via sa connexion >> Internet personnelle et donc via une IP que le client ne connaît pas. >> >> Il pourrait communiquer son IP personnelle au client qui n'aurait qu'à >> la rajouter : mais ça prends généralement du temps (le client doit >> contacter son prestataire, etc.) et parfois le collègue n'a carrément >> pas d'adresse IP fixe (certains FAI, ou les clients nomades en connexion >> cellulaire). >> >> Alors, ce qu'on a fait dans un premier temps c'est mettre en place un >> serveur proxy HTTP (Squid) dont l'accès à Internet passe par une des >> adresses IP communiquées au client (le serveur est hébergé en local dans >> nos locaux). Ça fonctionne pour l'HTTP, pas pour le FTP, SSH, RDP qui >> sont des protocoles d'accès que certains clients nous demandent >> d'utiliser. >> >> Pour éviter d'ouvrir à tout vent ce serveur proxy, il n'est pas >> accessible sur Internet : pour le contacter alors qu'on est en >> télétravail/nomade on doit passer par notre service de VPN. >> >> Ce service VPN existait déjà avant ces problématique d'accès aux BO des >> clients et réponds à un tout autre besoin : permettre aux >> télétravailleurs/nomades d'accéder à certaines ressources locales (auto >> hébergées) du SI de notre société. Et il est configuré pour que seul le >> trafic destiné au LAN y arrive (avec l'exemple d'une vidéo YouTube >> consultée pendant le télétravail qui ne passerait donc pas via le VPN). >> >> Mes solutions envisagées : >> >> * Trouver un outil qui "sache" proxyfier de l'HTTP, FTP, SSH, RDP, etc. &g
Re: [FRnOG] [TECH] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, …) pour le staff en télétravail ?
Je dis cela d’avance car si vous avez une PSSI lideal est de faire de la rétention de logs chez vous avant même d’aller sur les serveurs de vos clients. Ce qui vous permets de faire un premier niveau de cloisonnement etc … Tu peux utiliser un ipsec plus du proxy ssl avec double authentification pour que les flux match avec un groupe ou un users par exemple et autoriser dans ton ipsec uniquement le bastion qui lui a les flux vers ton client. Le mer. 29 mars 2023 à 16:48, sofiane JALID a écrit : > Tu as plusieurs choix qui s’offrent à toi mais l’idée de faire du Split > tunneling et de fournir lip wan des users en délégation chez tes clients et > pas une bonne pratique > > La meilleure serait de faire de lip sec en mode gateway avec un premier > filtrage de la remediation du dns sec du proxy web et un bastion rdp qui > lui est comme en local chez vous et que votre client n’autorise que le > serveur netscaler ou Wallix derrière ou cyberhark > > > > Le mer. 29 mars 2023 à 16:43, DUVERGIER Claude < > frnog...@claude.duvergier.fr> a écrit : > >> Au vu des réponses, je comprends que j'ai mélangé différents points sans >> être totalement clair alors je reprends avec plus de contexte. >> >> Dans le cadre de nos prestations des collègues sont amenés à travailler >> (pendant quelques jours, semaines ou mois) sur les sites des clients >> (production ou préproduction) et notamment se connecter au backoffice >> web, ou serveur de stockage FTP. >> >> A. Parfois c'est un accès direct sans filtrage d'adresse IP. >> B. Parfois c'est un accès direct mais uniquement autorisé depuis des >> adresses IP préalablement déclarées. >> C. Parfois c'est via un serveur bastion du client (j'ai eu les cas d'un >> accès SSH et d'autres via RDP) dont l'accès et uniquement autorisé >> depuis des adresses IP préalablement déclarées. >> >> Pour le cas A : aucun problème (sauf à la limite quand notre staff >> télétravaille depuis des pays "exotiques" que le client aurait par >> défaut bloqué de son côté : mais c'est rare). >> >> Pour les cas B et C : on communique au client les adresses IP publiques >> qu'utilisent nos agences pour accéder à Internet, le client les autorise >> et tout fonctionne (généralement pas du premier coup il est vrai :P). >> >> Mais quand le collègue est en télétravail il surfe via sa connexion >> Internet personnelle et donc via une IP que le client ne connaît pas. >> >> Il pourrait communiquer son IP personnelle au client qui n'aurait qu'à >> la rajouter : mais ça prends généralement du temps (le client doit >> contacter son prestataire, etc.) et parfois le collègue n'a carrément >> pas d'adresse IP fixe (certains FAI, ou les clients nomades en connexion >> cellulaire). >> >> Alors, ce qu'on a fait dans un premier temps c'est mettre en place un >> serveur proxy HTTP (Squid) dont l'accès à Internet passe par une des >> adresses IP communiquées au client (le serveur est hébergé en local dans >> nos locaux). Ça fonctionne pour l'HTTP, pas pour le FTP, SSH, RDP qui >> sont des protocoles d'accès que certains clients nous demandent >> d'utiliser. >> >> Pour éviter d'ouvrir à tout vent ce serveur proxy, il n'est pas >> accessible sur Internet : pour le contacter alors qu'on est en >> télétravail/nomade on doit passer par notre service de VPN. >> >> Ce service VPN existait déjà avant ces problématique d'accès aux BO des >> clients et réponds à un tout autre besoin : permettre aux >> télétravailleurs/nomades d'accéder à certaines ressources locales (auto >> hébergées) du SI de notre société. Et il est configuré pour que seul le >> trafic destiné au LAN y arrive (avec l'exemple d'une vidéo YouTube >> consultée pendant le télétravail qui ne passerait donc pas via le VPN). >> >> Mes solutions envisagées : >> >> * Trouver un outil qui "sache" proxyfier de l'HTTP, FTP, SSH, RDP, etc. >> Un proxy en SOCKS5 peut faire tout ça ? >> * Mettre en place, en interne, un bastion sous la forme d'un bureau >> virtuel où l'utilisateur aurait navigateur web, client FTP/SSH/RDP >> * Capter tout le trafic réseau via le tunnel VPN : ainsi les >> collaborateurs apparaissent comme étant tout le temps "au bureau". >> >> Vu le nombre de prestation et la durée de celle-ci, je préfère avoir une >> solution qui ne me demande pas de configuration dédiée à chaque besoin. >> >> Il existe évidemment plein de solutions techniques que le client >> auraient pu mettre en place pour simplifier le tout (dans le style de >> Boundary de HashiCorp, Envoy Proxy de Lyft, etc.) mais
[FRnOG] RFC 6296: IPv6-to-IPv6 Network Prefix Translation
données comme SIP ; ceux-ci auront besoin d'un ALG, * La configuration du DNS va être pénible car il faudra prévoir une vue externe et une interne (split DNS). Bref, NPTv6 n'est pas une solution parfaite et c'est pour cela que ce RFC reste au statut Expérimental. Si on décide de poursuivre cette voie, il faut choisir les adresses à utiliser en interne. Les ULA du RFC 4193 semblent la solution idéale, maximisant l'indépendance. Voici pour les grands principes. Quelques détails pratiques maintenant. Prenons l'exemple simple de la section 2.1 : un réseau interne, utilisant un préfixe ULA, fd01:203:405:/48, est connecté à l'Internet via un unique FAI, et un routeur qui fait du NPTv6. Le préfixe PA alloué par le FAI et routable publiquement est 2001:0db8:1:/48 (notez que NPT n'impose pas que les deux préfixes aient la même longueur, cf. section 3.7). Lorsqu'un paquet « sort » (va du réseau local vers l'Internet), l'adresse IP source est remplacée par une adresse IP prise dans le préfixe du FAI. Les autres champs de l'en-tête IP ne sont pas modifiés. En sens inverse, lorsqu'un paquet « entre » (vient de l'Internet vers le réseau local), c'est l'adresse de destination qui est touchée, pour être remplacée par une adresse du réseau local. La partie identifiant la machine sur le réseau local (80 bits dans cet exemple) n'est en général pas conservée telle quelle. Ainsi, si fd01:203:405:1::1234 écrit à 2a00:1450:8007::13, Gmail, le destinataire, verra le paquet venant de 2001:0db8:1:d550::1234 Image (, http://www.bortzmeyer.org/images/nat66) En effet, la traduction est neutre pour la somme de contrôle. Si on suit l'algorithme standard du RFC 1071, on veut obtenir la même somme de contrôle avant et après traduction. Les protocoles qui utilisent une somme calculée sur une partie de l'en-tête IP (c'est le cas de TCP) ne seront donc pas affectés. Astuce amusante, pour atteindre cet objectif de neutralité, 16 bits de l'adresse sont réservés pour pouvoir y faire les modifications qui annuleront les autres changements faits dans l'adresse. L'algorithme exact de calcul est dans les sections 3.1 et suivantes. Une mise en #339;uvre en C figure en annexe B. À noter qu'elle ne prétend pas être optimale, faisant par exemple les calculs de somme de contrôle avec du code portable et pas de l'assembleur adapté à une machine particulière. On peut avoir des cas plus compliqués que ce simple réseau, par exemple du multi-homing, où le réseau local est connecté à deux FAI (section 2.4). Chacun de ces deux FAI alloue un préfixe PA différent. Les liens avec les deux FAI passent par deux routeurs NPT différents, tous les deux configurés avec le même préfixe interne mais différents préfixes externes. Une machine du réseau local ne pourra pas savoir sous quelle adresse elle apparaitra à l'extérieur, sauf à utiliser une technique comme STUN (RFC 5389). La décision de sortir par un FAI ou l'autre peut être prise comme on veut. Par contre, par rapport à du vrai multi-homing, avec adresses PI et BGP, un changement de FAI de sortie entraîne un changement de l'adresse IP vue par l'extérieur et coupe donc toutes les sessions en cours. Continuons avec les considérations de déploiement et de configuration (section 4). Le plus probable est que NPTv6 sera mis en #339;uvre dans les routeurs, comme dans l'exemple ci-dessus, et, pour les particuliers et petites organisations dans le CPE. Les obligations du RFC 6204 s'appliquent donc à l'engin qui fait la traduction. Cela implique entre autres que le traducteur NPT soit capable de faire des virages en épingle à cheveux (renvoyer vers le réseau local un paquet qui était à destination du réseau local, cf. RFC 4787), afin que des machines du réseau local puissent se parler en utilisant leurs adresses publiques. Comme NPT ne tripote pas les ports, la plupart des autres exigences des RFC du groupe BEHAVE http://www.bortzmeyer.org/behave-wg.html ne s'appliquent pas à lui. Et pour les applications, quelles sont les conséquences (section 5) ? Plusieurs des problèmes classiques de la traduction, qui avaient déjà été décrits dans le RFC 2993 sont toujours présents. Les applications ne verront pas les mêmes adresses, selon qu'elles sont situées d'un côté ou de l'autre du traducteur. Par exemple, si un ordinateur portable se déplace de part et d'autre du traducteur, il verra ses connexions s'interrompre, son adresse IP ayant changé. Mais les problèmes les plus fréquents et les plus sérieux seront pour les protocoles applicatifs qui utilisent des *références*, c'est-à-dire qui indiquent dans les données à quelle adresse IP envoyer les paquets. Les cas les plus connus sont FTP et SIP. Si un client SIP envoie à un autre son adresse interne, pour recevoir un flux RTP, cette adresse ne sera pas traduite, et le flux ne joindra pas la destination. Que peut-on faire pour limiter les dégâts ? * Comme avec le NAT44, les applications peuvent utiliser STUN
Re: [FRnOG] [TECH] IP Nat sur Cisco
En fait ip nat enable n'est pas si magique que ça... Sur ROUTEUR-NAT j'ai bien activé "ip nat enable" sur toute les interfaces en lieu et place des Inside/outside J'ai changé les access-list ansi que ip nat Inside par : ip nat source list 10 interface FastEthernet4 overloadip nat source static 10.0.1.1 1.1.1.1 extendable ip nat source static 10.0.1.5 1.1.1.2 extendableaccess-list 10 permit 10.0.1.4 0.0.0.3 Depuis laptop0 du Lan2 je ne peux pas pinguer 1.1.1.100. Sur routeur NAT je peux pinguer 1.1.1.100 sauf si j'utilise ping 1.1.1.100 source vlan 102 Est-ce que j'ai un problème dans mon access-list/ip nat source ? De : David Ponzone <david.ponz...@gmail.com> À : Antoine Durant <antoine.duran...@yahoo.fr> Cc : "frnog-t...@frnog.org" <frnog-t...@frnog.org> Envoyé le : Vendredi 8 avril 2016 14h29 Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco Tu peux pas, vlan102 a déjà ip nat inside, tu peux pas mettre ip nat outside en plus. C’est justement là qu’il faut utiliser le NAT NVI et son: ip nat enable magique. Et là, tout se joue sur les ACL que tu utilises pour le NAT donc attention… Et NAT NVI évidemment n’est pas disponible sur toutes les plateformes (pas sur ASR par exemple). > Le 8 avr. 2016 à 14:23, Antoine Durant <antoine.duran...@yahoo.fr> a écrit : > > J'ai déjà mal à la tête en fait...Si j'ajoute une règle de NAT entre vlan101 > et vlan102 ca va passer ? > > NAT NVI je ne connais pas je vais regarder Google ! > > > De : David Ponzone <david.ponz...@gmail.com> > À : Antoine Durant <antoine.duran...@yahoo.fr> > Cc : "frnog-t...@frnog.org" <frnog-t...@frnog.org> > Envoyé le : Vendredi 8 avril 2016 14h13 > Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco > > Ton problème est vieux comme le monde :) > Ca s’appelle le NAT HAIRPINNING. > > Quand le paquet venant de 192.168.1.1 vers 1.1.1.1 rencontre la règle de NAT > 1-to-1: > ip nat inside source static 10.0.1.1 1.1.1.1 extendable > L’IP Source du paquet est à ce moment là 10.0.1.5 (NAT sur R2). > l’IP destination du paquet va être modifiée pour 10.0.1.1 (R1) qui à son tour > va le modifier en 192.168.1.1 (server0). > Le paquet retour va partir de 192.168.1.1 (server0) à destination de > 10.0.1.5, R1 va changer l’IP source en 10.0.1.1. > Puis ROUTEUR-NAT ne va rien faire à l’IP SOURCE car tu n’a pas de NAT de > VLAN101 vers VLAN102. > Donc ton PC va recevoir une réponse qui vient de 10.0.1.1 alors qu’il avait > envoyé un paquet à 1.1.1.1. > > En fait, c’est le problème fondamental qui consiste à accéder à une IP > publique qui donne accès à une ressource interne grâce à du NAT, en étant > soi-même pas de l’autre côté du NAT, mais en interne. > > Prends de l’aspirine et: > > https://supportforums.cisco.com/discussion/12102421/nat-hairpinning<https://supportforums.cisco.com/discussion/12102421/nat-hairpinning> > > Pour moi tu as 2 solutions: > -DNS split-horizon > -ou utilise le NAT NVI sur les Cisco, mais va falloir encore un peu > d’aspirine pour par pondre une grosse bouse > > > > Le 8 avr. 2016 à 13:43, Antoine Durant <antoine.duran...@yahoo.fr > > <mailto:antoine.duran...@yahoo.fr>> a écrit : > > > > Bonjour David, > > > > Je comprend ta remarque et me doute bien que vous avez tous des > > occupations. J'ai cherché mais en vain, c'est pour cela que je m'adresse à > > frnog pour avoir un coup de pouce... > > > > Voici le schéma : > > http://hpics.li/82254e6<http://hpics.li/82254e6><http://hpics.li/82254e6<http://hpics.li/82254e6>> > > > > Depuis PC0 je peux ouvrir l'url 1.1.1.1:80 situé sur le serveur 192.168.1.1 > > connecté derrière R1, donc le NAT/access-list fonctionne. > > > > Le problème est que lorsque depuis Laptop0 connecté derrière R2 j'essaye > > d'ouvrir l'url 1.1.1.1:80 cela ne fonctionne pas. Le problème est à mon > > avis situé dans ma conf du routeur ROUTEUR-NAT, mais je n'arrive pas à > > résoudre ça :( > > > > Merci d'avance à tous. > > > > > > > > De : David Ponzone <david.ponz...@gmail.com > > <mailto:david.ponz...@gmail.com>> > > À : Antoine Durant <antoine.duran...@yahoo.fr > > <mailto:antoine.duran...@yahoo.fr>> > > Cc : "frnog-t...@frnog.org <mailto:frnog-t...@frnog.org>" > > <frnog-t...@frnog.org <mailto:frnog-t...@frnog.org>> > > Envoyé le : Vendredi 8 avril 2016 12h48 > > Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco > > > > Antoine, > > > > je pense que plusieurs sur cette liste pourront te régler ce problème en > > 3/5 minutes max, mais ils ont c
Re: [FRnOG] [TECH] IP Nat sur Cisco
Tu dois surtout ajouter de quoi nater le trafic qui va de vlan101 vers vlan102! > Le 8 avr. 2016 à 17:20, Antoine Durant <antoine.duran...@yahoo.fr> a écrit : > > En fait ip nat enable n'est pas si magique que ça... > > Sur ROUTEUR-NAT j'ai bien activé "ip nat enable" sur toute les interfaces en > lieu et place des Inside/outside > > J'ai changé les access-list ansi que ip nat Inside par : > > ip nat source list 10 interface FastEthernet4 overload > ip nat source static 10.0.1.1 1.1.1.1 extendable > ip nat source static 10.0.1.5 1.1.1.2 extendable > access-list 10 permit 10.0.1.4 0.0.0.3 > > Depuis laptop0 du Lan2 je ne peux pas pinguer 1.1.1.100. Sur routeur NAT je > peux pinguer 1.1.1.100 sauf si j'utilise ping 1.1.1.100 source vlan 102 > > Est-ce que j'ai un problème dans mon access-list/ip nat source ? > > > De : David Ponzone <david.ponz...@gmail.com> > À : Antoine Durant <antoine.duran...@yahoo.fr> > Cc : "frnog-t...@frnog.org" <frnog-t...@frnog.org> > Envoyé le : Vendredi 8 avril 2016 14h29 > Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco > > Tu peux pas, vlan102 a déjà ip nat inside, tu peux pas mettre ip nat outside > en plus. > C’est justement là qu’il faut utiliser le NAT NVI et son: > ip nat enable > magique. > > Et là, tout se joue sur les ACL que tu utilises pour le NAT donc attention… > > Et NAT NVI évidemment n’est pas disponible sur toutes les plateformes (pas > sur ASR par exemple). > > > > > Le 8 avr. 2016 à 14:23, Antoine Durant <antoine.duran...@yahoo.fr > > <mailto:antoine.duran...@yahoo.fr>> a écrit : > > > > J'ai déjà mal à la tête en fait...Si j'ajoute une règle de NAT entre > > vlan101 et vlan102 ca va passer ? > > > > NAT NVI je ne connais pas je vais regarder Google ! > > > > > > De : David Ponzone <david.ponz...@gmail.com > > <mailto:david.ponz...@gmail.com>> > > À : Antoine Durant <antoine.duran...@yahoo.fr > > <mailto:antoine.duran...@yahoo.fr>> > > Cc : "frnog-t...@frnog.org <mailto:frnog-t...@frnog.org>" > > <frnog-t...@frnog.org <mailto:frnog-t...@frnog.org>> > > Envoyé le : Vendredi 8 avril 2016 14h13 > > Objet : Re: [FRnOG] [TECH] IP Nat sur Cisco > > > > Ton problème est vieux comme le monde :) > > Ca s’appelle le NAT HAIRPINNING. > > > > Quand le paquet venant de 192.168.1.1 vers 1.1.1.1 rencontre la règle de > > NAT 1-to-1: > > ip nat inside source static 10.0.1.1 1.1.1.1 extendable > > L’IP Source du paquet est à ce moment là 10.0.1.5 (NAT sur R2). > > l’IP destination du paquet va être modifiée pour 10.0.1.1 (R1) qui à son > > tour va le modifier en 192.168.1.1 (server0). > > Le paquet retour va partir de 192.168.1.1 (server0) à destination de > > 10.0.1.5, R1 va changer l’IP source en 10.0.1.1. > > Puis ROUTEUR-NAT ne va rien faire à l’IP SOURCE car tu n’a pas de NAT de > > VLAN101 vers VLAN102. > > Donc ton PC va recevoir une réponse qui vient de 10.0.1.1 alors qu’il avait > > envoyé un paquet à 1.1.1.1. > > > > En fait, c’est le problème fondamental qui consiste à accéder à une IP > > publique qui donne accès à une ressource interne grâce à du NAT, en étant > > soi-même pas de l’autre côté du NAT, mais en interne. > > > > Prends de l’aspirine et: > > > > https://supportforums.cisco.com/discussion/12102421/nat-hairpinning > > <https://supportforums.cisco.com/discussion/12102421/nat-hairpinning><https://supportforums.cisco.com/discussion/12102421/nat-hairpinning > > <https://supportforums.cisco.com/discussion/12102421/nat-hairpinning>> > > > > Pour moi tu as 2 solutions: > > -DNS split-horizon > > -ou utilise le NAT NVI sur les Cisco, mais va falloir encore un peu > > d’aspirine pour par pondre une grosse bouse > > > > > > > Le 8 avr. 2016 à 13:43, Antoine Durant <antoine.duran...@yahoo.fr > > > <mailto:antoine.duran...@yahoo.fr> <mailto:antoine.duran...@yahoo.fr > > > <mailto:antoine.duran...@yahoo.fr>>> a écrit : > > > > > > Bonjour David, > > > > > > Je comprend ta remarque et me doute bien que vous avez tous des > > > occupations. J'ai cherché mais en vain, c'est pour cela que je m'adresse > > > à frnog pour avoir un coup de pouce... > > > > > > Voici le schéma : http://hpics.li/82254e6 > > > <http://hpics.li/82254e6><http://hpics.li/82254e6 > > > <http://hpics.li/82254e6>><http://hpics.li/82254e6 > >
