Proxy inversé avec contrôle d'accès

[oracle7]

@CyberFr

Bonjour,

Et quand le message arrive, si tu cliques sur "CONTINUE", qu'est-ce que cela fait ?

Cordialement

oracle7😉

[CyberFr]

il y a 5 minutes, oracle7 a dit :

Et quand le message arrive, si tu cliques sur "CONTINUE", qu'est-ce que cela fait ?

La connexion s'établit.

[.Shad.]

@CyberFr : Pour moi c'est l'IP de ta box qu'on voit ici, c'est un problème, car tu devrais voir :

• soit l'IP d'un périphérique local quand tu te connectes en local
• soit une IP distante quand tu te connectes à distance sans VPN
• soit une IP dans le sous-réseau VPN quand tu te connectes en VPN

Je pense savoir ce que c'est, est-ce que tu mets un nom de domaine dans ton fichier ovpn ou une IPv4 ?
Si ndd, est-ce qu'un nslookup sur ce ndd renvoie également une IPv6 ? ou seulement une IPv4 ?

[Jeff777]

Sur android je fais "continue" et ça fonctionne

Ah grillé 😉

Modifié le 9 octobre 2021 par Jeff777

[CyberFr]

En local ça donne ceci

Citation

LaX1:~ lionel$ nslookup ndd.fr
Server:        192.168.1.8
Address:    192.168.1.8#53

Name:    ndd.fr
Address: 192.168.1.8

Mais ce n'est peut être pas significatif. Je vais donc remplacer le nom de domaine qui figure en face de la rubrique "remote" dans le fichier de config d'OpenVPN par l'adresse IP publique de la box.

Il vaudrait mieux sans doute que je fasse un essai à l'extérieur de chez moi en 4G.

[Jeff777]

Mais le contrôle d'accès ne devrait pas bloquer 192.168.1.254 s'il a le même pour le VPN et les adresses locales !

[CyberFr]

il y a 7 minutes, Jeff777 a dit :

Mais le contrôle d'accès ne devrait pas bloquer 192.168.1.254 s'il a le même pour le VPN et les adresses locales !

Je me suis en effet connecté alors que le contrôle d'accès était activé.

[Jeff777]

Ah mais le test tu ne l'as pas fait avec la connexion wifi de ton copain ?

Modifié le 9 octobre 2021 par Jeff777

[CyberFr]

Ben non. Je l'ai fait de chez moi.

[.Shad.]

L'idée c'est de te connecter via VPN, mais pas depuis ton réseau local. Donc ça peut être en 4G par exemple.

Désactiver temporairement ton contrôle d'accès pour identifier quelle IP est vue par DSM lorsque tu te connectes.

Dans aucun cas tu ne dois voir 192.168.1.254.

Donc je résume, tu te mets en 4G (ou wifi externe c'est pareil) puis tu te connectes au VPN. Tu désactives au préalable le contrôle d'accès, et tu te log à DSM. Tu vérifies dans les journaux l'IP trouvée pour cette connexion.

D'autre part un nslookup local comme tu le dis n'a pas de sens, tu peux rajouter une IP publique à la suite de ta commande nslookup pour utiliser cette IP pour résoudre le domaine (8.8.8.8 exemple).

[Jeff777]

En 4G il arrive à se connecter avec VPN et contrôle d'accès. Il ne doit donc pas recevoir la même IP que depuis le WIFI extérieur non ?

[CyberFr]

J'ai utilisé le proxy inversé hors de chez moi en 4G après avoir créé une connexion avec OpenVPN. J'ai pu me connecter alors que le contrôle d'accès était activé. Lorsque je le désactive, le journal des connexions indique la même chose.

J'ai mis dans le fichier de configuration d'OpenVPN

#IP publique de la box
remote 87.88.XXX.XXX 1194

#DNS Server sur le NAS
dhcp-option DNS 192.168.1.X

@DNS secondaires, ceux de FDN
@dhcp-option DNS 80.67.169.40

Le journal des connexions du NAS indique (254 est la passerelle par défaut de la box)
User [lionel] from [192.168.1.254] logged in successfully via [DSM].

Le journal de VPN Server indique
Connected from [80.215.108.XXX] as [10.8.0.6].
Je suppose que 80.215.108.XXX est l'IP publique du smartphone.

[Jeff777]

il y a 20 minutes, CyberFr a dit :

Je suppose que 80.215.108.XXX est l'IP publique du smartphone.

Tu ne serais pas chez Bouygues Télécom ?

il y a 20 minutes, CyberFr a dit :

J'ai utilisé le proxy inversé hors de chez moi en 4G après avoir créé une connexion avec OpenVPN

Si tu te connectes en 4G, WiFI déconnecté. Peu importe que tu sois chez toi ou non ta connexion passera par le réseau téléphonique de Bouygues Télécom. 

De plus j'ai cru comprendre qu'en 4G tu n'avais aucun soucis que ce soit avec le VPN ou le contrôle d'accès. 

Ton seul et unique soucis c'est lorsque tu te connectes au wifi de ton copain en VPN ou tu n'atteins pas ton NAS malgré le contrôle d'accès qui autorise le VPN.

C'est bien cela ?

Si c'est bien ton cas; alors il faudrait faire le test depuis le Wifi de ton copain sans le VPN pour voir l'adresse de connexion qui apparait sur ton NAS.

Modifié le 10 octobre 2021 par Jeff777

[CyberFr]

Bonjour @Jeff777

En effet je suis chez Bouygues Télécom.

il y a 35 minutes, Jeff777 a dit :

C'est bien cela ?

Oui c'est exactement ça.

il y a 35 minutes, Jeff777 a dit :

Si c'est bien ton cas; alors il faudrait faire le test depuis le Wifi de ton copain sans le VPN pour voir l'adresse de connexion qui apparait sur ton NAS.

Il faudra donc que j'ouvre le port d'administration de DSM en HTTPS (il est actuellement fermé à tout trafic non local) puis que je me connecte sur le NAS comme je le fais de chez moi (https://ndd.fr:portHTTPS) ?

Mais je vais voir l'adresse IP de la box de mon copain, quel en est l'intérêt ? Quelque chose m'échappe.

Modifié le 10 octobre 2021 par CyberFr
Il faudrait plutôt atteindre le reverse proxy, contrôles d'accès désactivés et sans passer par le VPN. Je vais faire l'essai.

[Jeff777]

Normalement si tu te connectes en VPN depuis son wifi tu devrais voir une adresse en 10.x.x.x :

Il y a 17 heures, .Shad. a dit :

Pour moi c'est l'IP de ta box qu'on voit ici, c'est un problème, car tu devrais voir :

• soit l'IP d'un périphérique local quand tu te connectes en local
• soit une IP distante quand tu te connectes à distance sans VPN
• soit une IP dans le sous-réseau VPN quand tu te connectes en VPN

Si ce n'est pas le cas ( et il y a des chances que ce ne le soit pas, sinon tu pourrais aussi te connecter en remettant le contrôle d'accès) nous aurons peut-être une piste pour l'origine du problème.

[CyberFr]

Je vais donc désactiver le contrôle d'accès, depuis chez mon copain activer le VPN et me connecter au reverse proxy. Puis je reviendrai ici pour préciser ce qu'indiquent les journaux de connexion.

[Jeff777]

oui

[oracle7]

@CyberFr

Bonjour,

Je viens de lire sur un site qui présente une méthode de configuration OpenVPN sur Synology (comme beaucoup d'ailleurs) que dans le cas d'un client sur iPhone et sous iOS 7 et supérieur, qu'il fallait ajouter spécifiquement (pour le monde Apple) juste après la ligne " redirect-gateway def1 " une ligne du type " redirect-gateway ipv6 ".

N'ayant pas d'iPhone, je ne saurais dire sa réelle efficacité et son impact. Je te laisse tester si le cœur t'en dit.

Sinon, pour le problème de message "Missing external certificate" déjà vu à la connexion, ce même site dit d'ajouter la commande " client-cert-not-required ". Il semble là que ce soit efficace. Du coup, la ligne " remote-cert-tls server " ne soit alors plus nécessaire.

Cordialement

oracle7😉

[CyberFr]

Bonjour @oracle7,

Je vais remplacer remote-cert-tls server par client-cert-not-required. Par contre pour redirect-gateway ipv6, je suis dubitatif, à vrai dire parce que je ne comprends pas.

[Jeff777]

@CyberFr   pour être bien sûr : chez ton copain tu te connectes en VPN depuis ton téléphone en WIFI uniquement sans que le profil d'accès ne soit activer sur ton proxy inverse qui mène a-t-on DSM.

@oracle7On va déjà voir l'IP qui se connecte dans ce cas avant de faire d'autres manip. Pour l'instant il y a pas mal de choses qui fonctionnent.

Modifié le 10 octobre 2021 par Jeff777

[CyberFr]

il y a 1 minute, Jeff777 a dit :

On va déjà voir l'IP qui se connecte dans ce cas avant de faire d'autre manip. Pour l'instant il y a pas mal de choses qui fonctionnent.

C'est noté, pour l'instant je ne touche à rien. Quitte à peaufiner par la suite.

[Jeff777]

L'idée c'est d'abord de vérifier que cet IP fait bien partie de celles autorisées dans le contrôle d'accès. Si c'est le cas comme le contrôle d'accès ne fonctionne pas il faudra envisager autre chose. Si ce n'est pas le cas alors peut-être rajouter des ip autorisées (chez moi j'ai des IPV6 locales).

[.Shad.]

Il y a 2 heures, CyberFr a dit :

J'ai utilisé le proxy inversé hors de chez moi en 4G après avoir créé une connexion avec OpenVPN. J'ai pu me connecter alors que le contrôle d'accès était activé. Lorsque je le désactive, le journal des connexions indique la même chose.

Il y a 2 heures, CyberFr a dit :

Le journal des connexions du NAS indique (254 est la passerelle par défaut de la box)
User [lionel] from [192.168.1.254] logged in successfully via [DSM].

C'est bien ça le souci, il voit l'IP de la box quand tu te connectes en 4G avec un smartphone, donc ce n'est pas bon.
Parce que si quelque soit la connexion externe, via VPN ou en direct, il voit une IP privée, les ACL autoriseront l'accès.
Essaie de désactiver temporairement l'IPv6 sur ta box, et également dans les paramètres réseau de ton NAS.
Puis, réessaie de te connecter en 4G par le VPN à DSM, et regarde quelle IP est vue dans le journal des connexions.

[CyberFr]

J'ai donc désactivé le con trôle d'accès. Lorsque je me connecte sur le WI-FI de mon copain, c'est l'adresse IP publique de sa box qui apparaît :
User [lionel] from [176.146.XX.XXX] logged in successfully via [DSM].

Et dans le journal de VPN Server :
Connected from [176.146.XX.XXX] as [10.8.0.6].

Même chose si j'utilise le protocole L2TP/IPSec à part que [10.8.0.6] est remplacé par [10.2.0.1].
Ça sert à quoi d'activer le VPN ?

Modifié le 10 octobre 2021 par CyberFr
L'IPv6 est désactivé, aussi bien sur la box que sur le NAS.

[.Shad.]

Dans ton cas le port HTTPS est accessible à la France, donc VPN ou pas on peut accéder à tes entrées de proxy inversé. Le VPN est utile quand tu utilises les profils de contrôle d'accès, car en ce cas tu peux déterminer quel services sont accessibles pour quelles IP.

Comme tu as pu le constater chez moi le contrôle d'accès est effectif.
Via ton smartphone non, et je n'arrive pas à déterminer pourquoi.

Depuis le Wifi de ton ami, il te suffit de tester avec les profils de contrôle d'accès comprenant dans un cas son IP VPN et dans un autre cas non (en utilisant un CIDR /32, tu peux définir une IP unique).