Routage sur nom de domaine



  • Bonjour,

    Je suis dans une configuration simple :

    Un LAN + mon PF avec 2 WAN : 1 ADSL, ma gateway par défaut et 1 SDSL.

    Je désire faire passer le flux O365 par la SDSL. Comment puis-je faire?

    Routage par adresse IP : vu la liste, je ne suis pas sûr que ce soir le plus simple.

    Routage par nom de domaine?

    D'avance merci.

    Nusa



  • Je ne connais pas de solution simple à ce problème  :-[

    Dans le cas d'une configuration mutli-Wan, le choix du WAN dépend soit des options "routing" dans les groupes de routes en fonction des tiers dans lesquels sont affectées chacune des gateway (et dans ce cas il n'y as pas de répartition en fonction de la source ou de la destination, c'est juste du fail-over / load-balancing)
    soit au travers des policy routing mais dans ce cas, c'est une IP.

    Si j'avais absolument à mettre en œuvre ta contrainte, voici comment je m'y prendrais.

    En t'appuyant sur un proxy.pac qui redirige tes flux HTTPS vers différents proxy internes en fonction de la destination, tu seras vu du firewall avec 2 sources IP différentes, une par proxy.
    Il te suffit alors de créer une règle par IP source avec des policy routing pointant vers chaque gateway.

    Pas sur que ce soit la solution la plus "light" mais ça fonctionne grâce au proxy.pac qui sait faire de la redirection basée sur un nom de domaine  ;)

    est-ce bien réaliste de mettre ça en place ? ça dépend de la force de ta contrainte. Le coût, c'est uniquement 2 process Squid  ;D

    Note qu'il y a des "variations" possibles à cette approche:

    • tu fais passer tout le flux ADSL vers n proxy et le flux Office365 en direct ou le contraire mais le principe des règle de FW avec policy routing reste le même.

    et je n'ai pas d'autre idée pour le moment  8)



  • Je complète :

    Contexte : milieu associatif.

    Niveau expertise de l'administrateur : j'utilise PF depuis ….. un certain temps, 2006 d'après mon profil.

    Age de la solution firewall : 3 mois en prod, c'est une évolution de l'infra.

    Besoin : Asso utilisant Office 365, l'upload de l'ADSL n'est pas satisfaisant pour la mise en ligne de document, nous cherchons donc à séparer les fluxs.

    Schéma :

    WAN 1 : ADSL simple.

    WAN2 : SDSL

    LAN : 1 LAN avec borne wifi, pas de serveur, que des postes clients.

    DMZ : NA

    WIFI : même plan d'adressage IP que le LAN.

    Autres interfaces : DHCP pour le PF pour le LAN et le WIFI.

    Règles NAT : NON

    Règles Firewall : RAS

    Packages ajoutés : RAS

    Autres fonctions assignées au pfSense : NON

    Question : Comment séparer les fluxs : le surf pour l'ADSL et les fluxs vers Office 365 via la SDSL?

    Solution envisagée :

    Routage par IP?

    Routage basé sur les noms de domaines de Microsoft?

    Nusa



  • @Nusa:

    Je complète : …/...

    :)  c'était déjà clair et le routage "par nom de domaine" au niveau des policy routing, ça ne va pas marcher.

    Tu peux essayer avec des Alias et utiliser ces alias dans tes règle de FW mais comme la résolution des alias est asynchrone, pour autant que je comprenne, il y a un risque pour que parfois ça ne fonctionne pas comme prévu.

    Si quelqu'un a déjà essayé…



  • Bravo Nusa pour présenter selon le formulaire (avec les sections en gras, cela aurait été plus découpé).

    La question est claire :

    • le trafic web doit être dispatché sur plusieurs interfaces selon la destination (= le site web cherché).

    NB : le policy routing, c'est quoi ?
    Le policy routing est une règle (donc une source, une destination, un protocole) pour laquelle on choisit la 'gateway' c'est à dire l'interface de sortie.
    Exemple : SMTP -> interface 1, HTTP + FTP -> interface 2
    Attention, peut être couplé : HTTP pour la machine 1 -> interface 1, et, autre règle, HTTP pour machine 2 -> interface 2.

    La réponse avec pfSense :

    • pfSense sait faire du 'policy routing' : cf au dessus.
        => ne répond pas à la question parce que le critère est le protocole et pas la destination !

    => pfSense n'est pas la réponse

    La réponse avec Squid :

    • Squid est L'outil adapté quand il s'agit de protocole HTTP
    • Squid sait utiliser, selon la destination, un proxy 'père' (ICP)

    => Squid est la réponse … mais il faudra plusieurs Serveurs Squid et du policy routing

    Exemple :

    • le 'Squid général (1)' identifie la destination : si Office365 -> passage par 'Squid Office (2)'
    • pour le reste 'Squid (1)' traite par lui-même
    • Policy routing : HTTP pour 'Squid (1) -> interface 1 et HTTP pour 'Squid (2)' -> interface 2

    Il faudra être capable de spécifier la destination ... avec le nom de domaine.



  • JDH => cela faisait longtemps que je n'étais pas venu.

    cela casse un peu mon enthousiasme ces histoire de proxy…

    Autrement j'ai la liste des IP...

    https://support.content.office.net/en-us/static/O365IPAddresses.xml

    Mais vu le nombre....

    Bon je retour ne à ma réflexion et merci encore.

    Nusa

    nb : Vous remarquerez que je n'ai même pas poussé la blague à dire : nickel, je vais mettre Squid sur le Pf :-)



  • Autrement il y a une solution mais qui est hors sujet sur ce forum :

    Je fais un script, un petit .pac.

    je check l'ip du poste.
    Si je suis bien au sein du LAN de l'asso : pour le surfe je passe sur telle gateway, si je vais vers *.office365.com je passe par une seconde gateway.

    Cela implique de mettre ma SDSL directement sur le LAN sans passer par le PF.

    J'écris en réfléchissant, c'est mon côté participatif.

    Je reviens après avoir fait des tests.

    Nusa



  • mais pourquoi n'essaies-tu pas juste avec les alias si l'approche proxy ne te convient pas ?

    A mon avis, le seul risque se situe au niveau de l'aspect asynchrone de la résolution du fqdn. Comme dans ton cas il ne s'agit que d'un problème de performance, ça peut être acceptable.



  • @Nusa:

    nb : Vous remarquerez que je n'ai même pas poussé la blague à dire : nickel, je vais mettre Squid sur le Pf :-)

    En l’occurrence tu as bien fait…. car dans ce cas précis, ça ne marche pas  :P
    la raison étant que la règle qui permet de choisir la gateway se configure au niveau de l'interface et qu'avec le proxy sur pfSense, cette fonctionnalité n'est pas disponible.
    Il y a d'ailleurs un bug ouvert chez pfSense du fait que le proxy "embarqué" ne peut pas bénéficier des fonctionnalités de fail-over et load-balancing  :-X



  • Bonjour,

    Je vais essayer la piste des alias que je ne connaissais pas. Donc si je résume :

    comme expliqué ici :

    https://forum.pfsense.org/index.php?topic=38720.0

    Je créé un fichier contenant les IP utilisées par O365 donne ici :

    https://support.content.office.net/en-us/static/O365IPAddresses.xml

    Ensuite je créé un alias de type URL pointant vers mon fichier du type :

    http://www.fileserver.com/my_url_alias.txt

    Ensuite, je n'ai plus qu'à créer une rule pour indiquer que le traffic vers mon alias donc les IP contenu dans mon fichier texte doit passer par mon WAN2.

    J'ai bon?

    Si cela fonctionne, cela me parait trop simple….

    Nusa



  • @Nusa:

    Ensuite, je n'ai plus qu'à créer une rule pour indiquer que le traffic vers mon alias donc les IP contenu dans mon fichier texte doit passer par mon WAN2.

    J'ai bon?

    J'avoue ne pas avoir cliqué sur tous tes liens  :-[

    Dans pfSense, tu peux directement définir un [url=https://doc.pfsense.org/index.php/Aliases]alias à partir d'un fqdn.
    L'interface s'occupe de la résolution de nom pour convertir ça en IP afin que les règle de FW, qui définitivement ne connaissent que des IP, fonctionnent.

    C'est cette partie du process qui est asynchrone et qui fait que tu peux avoir un désalignement entre ton fqdn et les vraies IP correspondant.

    For Host and Network type aliases, a fully qualified domain name (FQDN) may be entered instead of an IP address.
    The FQDN will be resolved by DNS every 5 minutes (300 seconds) and updated internally.
    This can be useful for tracking dynamic DNS entries to identify sites or users that are unable to use a static IP.

    Si ce mode de fonctionnement te convient, alors tu n'as même pas besoin de gérer un fichier externe  ;)