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/