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 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 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 ? > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
