RE: [FRnOG] [TECH] Recherche modèle antenne WiFi

2023-03-29 Par sujet Michel KOENIG 
Merci, je vais prendre contact

Michel

De : David Ponzone 
Envoyé : lundi 27 mars 2023 23:52
À : Michel KOENIG 
Cc : frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] Recherche modèle antenne WiFi

Jamais fait en WIFI mais ce genre là:

https://www.ssb.de/en/wifi-products/wifi-antennas/wifi-sectorial-antenna
https://www.tesswave.com/products/wifi-antennas/sector-wifi-antennas/
https://www.wifi-shop24.com/24ghz-wifi-sector-antennas

?

Le 27 mars 2023 à 22:39, Michel KOENIG < 
michel.koe...@ncc-info.com> a écrit :

Bonjour,



J'ai besoin de couvrir un parking où l'on va faire du scan avec des douchettes 
WiFi



J'ai un seul lampadaire au milieu



L'idée, mettre 4 bornes WiFi sur le mat et 4 antennes mini 90°



[cid:image001.png@01D960FD.0809C270]



J'ai des bornes 4x4 MIMO avec connecteurs type N



Je ne trouve pas la bonne antenne qui va bien pour cette config



Quelqu'un a déjà fait ?



Michel

---
Liste de diffusion du FRnOG
http://www.frnog.org/






































---
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 ?

2023-03-29 Par sujet Axel Vittecoq 
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] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, …) pour le staff en télétravail ?

2023-03-29 Par sujet Xavier Beaudouin via frnog 
Est-ce que j’ai dis que c’était juste suffisant ?
Vous pouvez très bien ajouter une couche VPN. 
Après si les clef ssh c’est compliqué à déployer sous Windows… y a peut-être 
autre chose qui fait changer ?

Envoyé de mon iPhone

> Le 29 mars 2023 à 18:02, Hosman Beyrouti  
> a écrit :
> 
> Re Hello,
> 
> bastion SSH avec tunnel SSH suffit. De mon point de vue NOP NOP NOP!
> 
> Alors en ce moment penser que ceci est plus sécurisé qu'un VPN vous faite une 
> grosse erreur stratégique.
> Dans nos métier la sécurité est importante.
> 
> Le tunnel SSH est plus du dépannage de mon point de vue qu'un remote access 
> securisé.
> Il va falloir des certificats et leur gestion est problématique et peu 
> sécurisé surtout si vous finissait par vous les envoyer par email ou les 
> stocké sur des PC Windows peu sécurisés...
> Bref hacker SSH surtout sur de l’itinérant est loin d’être difficile...
> Si vous passé par des WIFI publique vous risquez de changer d'avis rapidement 
> sur les tunnels SSH.
> 
> CDLT Hosman.
> 
> 
> 
> - Mail original -
> De: "frnog" 
> À: "frnog" 
> Envoyé: Mercredi 29 Mars 2023 11:42:51
> Objet: Re: [FRnOG] [TECH] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, 
> …) pour le staff en télétravail ?
> 
> Hello
> 
> > J'ai peut être mal compris la problématique mais une solution simple
> > serait de fournir un vpn hébergé dans vos infras avec une IP fixe que
> > vous avez déjà fourni à vos clients.
> > 
> > Chacun de tes collaborateur en remote se connecte donc via le vpn fourni
> > et default tout dedans. Soit ta 3eme solution. Cela me parait beaucoup
> > plus simple que d'essayer de mettre des proxy multi protocolaire.
> 
> +1 pour cette solution (pourquoi se compliquer?).
> 
> Accessoirement il y a aussi un point important... pourquoi tunneliser 
> 0.0.0.0/0 (et soyons fous ::/0), alors qu'on peux juste annonce une DMZ (un 
> /24? un /64) et les DNS qui vont bien pour tunneliser ça proprement ?
> Parce que TOUT tunneliser pose un autre problème, surtout l'ordinateur est un 
> ordinateur n'appartenant pas au sous-traitant/employé... Quid du RGPD? De la 
> collecte des trucs que font l'ordinateur du client VPN alors qu'il pourrais 
> juste rebondir sur un client RDP ou bastion SSH (avec tunnels pour faire du 
> remote desktop en plus)?
> 
> Le concept du VPN qui fait tout m'as toujours rendu assez septique alors 
> qu'un bastion SSH avec tunnel SSH suffit largement pour beaucoup de cas (on 
> peux AUSSI ajouter un tunnel avec une techno X ou Y si ça fait plaisir, mais 
> restons dans le KISS).
> 
> Xavier
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> -- 
> [ https://www.email-impact.com/group/redirect/company-logo/8cTWQxwXLK/313 ] 
> 
> Hosman BEYROUTI 
> Administrateur Systèmes et Réseaux 
> Mob 
> Fixe 
> [ tel:06 90 88 00 80 | 06 90 88 00 80 ] 
> [ tel:06 90 88 00 80 | 05 90 77 40 80 ] 
> 
> Chez CDS Immo Impasse Vanterpool Maison Decaunes Concordia 
> 97150 Saint-Martin 
> [ 
> http://www.dauphintelecom.com/#?utm_source=email_impact_medium=signature_campaign=nom_de_domaine
>  | www.dauphintelecom.com ] 
> 
> [ https://www.facebook.com/dauphin.telecom/ ] 
> [ https://www.youtube.com/channel/UCaa1IU36j9twokUC3NAjZfQ ] 
> [ https://www.instagram.com/dauphin_telecom/ ] 
> 
> 
> 
> 
> .

---
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 ?

2023-03-29 Par sujet Paul Rolland (ポール・ロラン) 
Bonjour,

On Wed, 29 Mar 2023 16:43:06 +0200
DUVERGIER Claude  wrote:

> 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.

C'est bien ce que j'avais compris... et si on regarde ton expression du
probleme, c'est au niveau IP, pas au niveau applicatif.
A - aucun souci
B et C - il faut que tu te presentes avec les IPs declarees.

Bref, KISS... probleme IP, reponse IP, sinon c'est plus Kiss. 

Donc, fais en sorte que tes utilisateurs se voient annonces le routage de
ces IP dans leur connection VPN a tes sites, et mets le routage qui va bien.

Apres, pour la solution de VPN, je ne dirai rien, c'est comme evoquer vim
vs emacs, c'est uniquement pour un vendredi, tout le monde a son chouchou :D

Paul


---
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 ?

2023-03-29 Par sujet Hosman Beyrouti via frnog 
Re Hello,

bastion SSH avec tunnel SSH suffit. De mon point de vue NOP NOP NOP!

Alors en ce moment penser que ceci est plus sécurisé qu'un VPN vous faite une 
grosse erreur stratégique.
Dans nos métier la sécurité est importante.

Le tunnel SSH est plus du dépannage de mon point de vue qu'un remote access 
securisé.
Il va falloir des certificats et leur gestion est problématique et peu sécurisé 
surtout si vous finissait par vous les envoyer par email ou les stocké sur des 
PC Windows peu sécurisés...
Bref hacker SSH surtout sur de l’itinérant est loin d’être difficile...
Si vous passé par des WIFI publique vous risquez de changer d'avis rapidement 
sur les tunnels SSH.

CDLT Hosman.



- Mail original -
De: "frnog" 
À: "frnog" 
Envoyé: Mercredi 29 Mars 2023 11:42:51
Objet: Re: [FRnOG] [TECH] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, …) 
pour le staff en télétravail ?

Hello

> J'ai peut être mal compris la problématique mais une solution simple
> serait de fournir un vpn hébergé dans vos infras avec une IP fixe que
> vous avez déjà fourni à vos clients.
> 
> Chacun de tes collaborateur en remote se connecte donc via le vpn fourni
> et default tout dedans. Soit ta 3eme solution. Cela me parait beaucoup
> plus simple que d'essayer de mettre des proxy multi protocolaire.

+1 pour cette solution (pourquoi se compliquer?).

Accessoirement il y a aussi un point important... pourquoi tunneliser 0.0.0.0/0 
(et soyons fous ::/0), alors qu'on peux juste annonce une DMZ (un /24? un /64) 
et les DNS qui vont bien pour tunneliser ça proprement ?
Parce que TOUT tunneliser pose un autre problème, surtout l'ordinateur est un 
ordinateur n'appartenant pas au sous-traitant/employé... Quid du RGPD? De la 
collecte des trucs que font l'ordinateur du client VPN alors qu'il pourrais 
juste rebondir sur un client RDP ou bastion SSH (avec tunnels pour faire du 
remote desktop en plus)?

Le concept du VPN qui fait tout m'as toujours rendu assez septique alors qu'un 
bastion SSH avec tunnel SSH suffit largement pour beaucoup de cas (on peux 
AUSSI ajouter un tunnel avec une techno X ou Y si ça fait plaisir, mais restons 
dans le KISS).

Xavier


---
Liste de diffusion du FRnOG
http://www.frnog.org/
-- 
[ https://www.email-impact.com/group/redirect/company-logo/8cTWQxwXLK/313 ] 

Hosman BEYROUTI 
Administrateur Systèmes et Réseaux 
Mob 
Fixe
[ tel:06 90 88 00 80 | 06 90 88 00 80  ] 
[ tel:06 90 88 00 80 | 05 90 77 40 80 ] 

Chez CDS Immo Impasse Vanterpool Maison Decaunes Concordia 
97150 Saint-Martin 
[ 
http://www.dauphintelecom.com/#?utm_source=email_impact_medium=signature_campaign=nom_de_domaine
 | www.dauphintelecom.com ] 

[ https://www.facebook.com/dauphin.telecom/ ] 
[ https://www.youtube.com/channel/UCaa1IU36j9twokUC3NAjZfQ ] 
[ https://www.instagram.com/dauphin_telecom/ ] 




.


---
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 ?

2023-03-29 Par sujet Xavier Beaudouin via frnog 
Hello

> J'ai peut être mal compris la problématique mais une solution simple
> serait de fournir un vpn hébergé dans vos infras avec une IP fixe que
> vous avez déjà fourni à vos clients.
> 
> Chacun de tes collaborateur en remote se connecte donc via le vpn fourni
> et default tout dedans. Soit ta 3eme solution. Cela me parait beaucoup
> plus simple que d'essayer de mettre des proxy multi protocolaire.

+1 pour cette solution (pourquoi se compliquer?).

Accessoirement il y a aussi un point important... pourquoi tunneliser 0.0.0.0/0 
(et soyons fous ::/0), alors qu'on peux juste annonce une DMZ (un /24? un /64) 
et les DNS qui vont bien pour tunneliser ça proprement ?
Parce que TOUT tunneliser pose un autre problème, surtout l'ordinateur est un 
ordinateur n'appartenant pas au sous-traitant/employé... Quid du RGPD? De la 
collecte des trucs que font l'ordinateur du client VPN alors qu'il pourrais 
juste rebondir sur un client RDP ou bastion SSH (avec tunnels pour faire du 
remote desktop en plus)?

Le concept du VPN qui fait tout m'as toujours rendu assez septique alors qu'un 
bastion SSH avec tunnel SSH suffit largement pour beaucoup de cas (on peux 
AUSSI ajouter un tunnel avec une techno X ou Y si ça fait plaisir, mais restons 
dans le KISS).

Xavier


---
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 ?

2023-03-29 Par sujet Daniel via frnog 



Le 29/03/2023 à 17:20, Raphael Mazelier a écrit :
J'ai peut être mal compris la problématique mais une solution simple 
serait de fournir un vpn hébergé dans vos infras avec une IP fixe que 
vous avez déjà fourni à vos clients.

+1


Chacun de tes collaborateur en remote se connecte donc via le vpn 
fourni et default tout dedans. Soit ta 3eme solution. Cela me parait 
beaucoup plus simple que d'essayer de mettre des proxy multi 
protocolaire.


Cdt,


On 29/03/2023 16:43, DUVERGIER Claude wrote:
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 ?



---
Liste de diffusion du FRnOG
http://www.frnog.org/


--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


---
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 ?

2023-03-29 Par sujet Raphael Mazelier 
J'ai peut être mal compris la problématique mais une solution simple 
serait de fournir un vpn hébergé dans vos infras avec une IP fixe que 
vous avez déjà fourni à vos clients.


Chacun de tes collaborateur en remote se connecte donc via le vpn fourni 
et default tout dedans. Soit ta 3eme solution. Cela me parait beaucoup 
plus simple que d'essayer de mettre des proxy multi protocolaire.


Cdt,


On 29/03/2023 16:43, DUVERGIER Claude wrote:
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 ?



---
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 ?

2023-03-29 Par sujet Hosman Beyrouti via frnog 
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.
>> 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

Re: [FRnOG] [TECH] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, …) pour le staff en télétravail ?

2023-03-29 Par sujet sofiane JALID 
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 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

Re: [FRnOG] [TECH] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, …) pour le staff en télétravail ?

2023-03-29 Par sujet sofiane JALID 
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 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
>

Re: [FRnOG] [TECH] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, …) pour le staff en télétravail ?

2023-03-29 Par sujet Rostan Nawer KEZAL via frnog 
Hello,

On a les mêmes problématiques chez nous parfois, et on a un HAProxy qui est
servis au travers d'un VPN.
Si jamais ca peut donner des idées :)



++

Le mer. 29 mars 2023 à 16:40,  a écrit :

> Salut,
>
> Comme suggéré par d'autres, tu peux faire du split tunnel et ajuster les
> routes du trafic des clients VPN. Ca se fait aussi bien dans les VPN
> classiques (Ikev2, Wireguard et autre OpenVPN) qu'avec ceux des
> fabricants de FW.
>
> Avec des appliances VPN avec une interface web de type IPDiva (si il
> existe encore) ou Pulse Secure (mais un peu cher) ca se fait bien aussi.
>
> Une autre solution peut aussi être de proposer aux salariés ayant besoin
> de cet accès un serveur de rebond (faire du RDP dans une session RDP
> marche pas trop mal). Tout dépend des besoins et du contexte réseau.
>
> Cordialement
>
> 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/
>


-- 
--

Rostan KEZAL

Network Engineer

| rostan.ke...@adevinta.com  
| FSM Paris, 85 rue du Faubourg Saint-Martin, 75010 Paris
| Découvrez leboncoin Groupe  !

---
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 ?

2023-03-29 Par sujet DUVERGIER Claude 
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

Re: [FRnOG] [TECH] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, …) pour le staff en télétravail ?

2023-03-29 Par sujet ml-frnog 

Salut,

Comme suggéré par d'autres, tu peux faire du split tunnel et ajuster les 
routes du trafic des clients VPN. Ca se fait aussi bien dans les VPN 
classiques (Ikev2, Wireguard et autre OpenVPN) qu'avec ceux des 
fabricants de FW.


Avec des appliances VPN avec une interface web de type IPDiva (si il 
existe encore) ou Pulse Secure (mais un peu cher) ca se fait bien aussi.


Une autre solution peut aussi être de proposer aux salariés ayant besoin 
de cet accès un serveur de rebond (faire du RDP dans une session RDP 
marche pas trop mal). Tout dépend des besoins et du contexte réseau.


Cordialement

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/

Re: [FRnOG] [TECH] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, …) pour le staff en télétravail ?

2023-03-29 Par sujet David Ponzone 
Ok maintenant je vois ce que j’avais lu trop vite dans le message de départ.

C’est un VPN unique pour accéder aux ressources chez les clients.
Ce que je pige mal, c’est que ces ressources chez les client semblent plutôt 
être du domaine interne donc pas exposées, mais supposons pour le moment 
qu’elles sont exposées à vos IP seulement.
Donc je dis alors comme Paul (Paul a toujours raison de toute façon): chacun 
des clients VPN (WG, Forti ou autre) doit avoir les routes vers les IP 
publiques des clients également routées dans le tunnel.

Encore plus secure mais complexe et coûteux.
-mettre un Fortigate chez chaque client, et un chez vous
-monter un tunnel IPsec entre le Forti du client et un VDOM de votre Fortinet
-le salarié se connecte dans un VPN spécifique à chaque client (dans le bon 
VDOM) et peut accéder aux IP privées chez le client. S’il doit bosser sur un 
autre client il se déco/reco sur l’autre VDOM (ip publique ou port différent, à 
valider)

Le problème de ce modèle, c’est que si vous avez plus de 9 clients, faut un 
Fortigate qui supporte plus de 10 VDOM, et ça commence à taper. Vaut mieux 
mettre plusieurs petits Forti.


> Le 29 mars 2023 à 15:14, Paul Rolland (ポール・ロラン)  a écrit 
> :
> 
> Hello,
> 
> On Wed, 29 Mar 2023 14:41:11 +0200
> DUVERGIER Claude  wrote:
> 
>> 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à.
> 
> Fais la meme chose : tu leur demandes leurs IP, tu les annonces dans ton
> VPN pour tes users, et tu mets a jour les regles de ton FW pour accepter le
> traffic vers ces IP en plus de tes IP internes, et le laisser ressortir sur
> Internet. 
> 
> Paul
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
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 ?

2023-03-29 Par sujet Paul Rolland (ポール・ロラン) 
Hello,

On Wed, 29 Mar 2023 14:41:11 +0200
DUVERGIER Claude  wrote:

> 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à.

Fais la meme chose : tu leur demandes leurs IP, tu les annonces dans ton
VPN pour tes users, et tu mets a jour les regles de ton FW pour accepter le
traffic vers ces IP en plus de tes IP internes, et le laisser ressortir sur
Internet. 

Paul


---
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 ?

2023-03-29 Par sujet stephane Miguel 
Pourquoi ne pas partir sur un bastion avec rupture protocolaire en passant
par un vpn en split tunellîg ?



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] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, …) pour le staff en télétravail ?

2023-03-29 Par sujet David Ponzone 
J’avoue que je cerne mal le problème.

Un VPN en split-horizon c’est:
-trafic vers un des préfixes privés connu -> VPN
-reste du trafic -> Internet perso du salarié

Tu t’occupes pas du type trafic, et pas besoin de proxy.

Wireguard fait ça très bien.
Le seul problème que j’ai avec Wireguard, c’est que pour le moment, il ne sait 
pas faire de push des routes vers le client, donc c’est le client qui décide en 
dur dans sa conf des règles du split. Donc un petit malin peut décider de tout 
passer par le VPN, par exemple pour faire du torrent sans se faire griller.
Après, si au niveau du siège, on ne lui permet pas d’accéder à Internet en 
venant d’une IP VPN, ça règle le problème.

Si on veut plus de contrôle sur la config du client, il vaut mieux aller vers 
du tunnel propriétaire type Forticlient/SSL (et donc Fortigate au bout).

Mais j’ai peut-être mal compris pourquoi la solution VPN que vous aviez 
actuellement ne convenait pas…

> Le 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/

[FRnOG] [TECH] Serveur "proxy multi-protocoles" (HTTP, FTP, RDP, …) pour le staff en télétravail ?

2023-03-29 Par sujet DUVERGIER Claude 

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/