Je souhaite accéder à une base Oracle 10g en passant pas un VPN.
J'ai deux clients VPN différents, ma tentative de connexion étant exactement
la meme dans les deux cas:
Avec l'accès VPN 1, tout fonctionne bien.
Avec l'accès VPN 2, j'ai un ORA-12170: TNS:Connect timeout occurred
systématique.
J'ai testé un telnet sur l'IP et sur le port, et cela fonctionne, donc
/apparemment/ mon accès VPN semble bien configuré.
Je ne connais absolument pas la configuration de cette base, ni l'origine de
cette erreur: j'ai vu qu'il y avait un SQLNET.INBOUND_CONNECT_TIMEOUT mais
je ne comprends pas très bien pourquoi cela fonctionnerait avec un accès VPN
et pas l'autre.
D'après vous, cela peut-il venir de la config d'oracle ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jerome Vitalis
Lionel wrote:
Bonjour,
Je souhaite accéder à une base Oracle 10g en passant pas un VPN. J'ai deux clients VPN différents, ma tentative de connexion étant exactement la meme dans les deux cas: Avec l'accès VPN 1, tout fonctionne bien. Avec l'accès VPN 2, j'ai un ORA-12170: TNS:Connect timeout occurred systématique.
Qu'est-ce qui différencie les 2 accès ?
J'ai testé un telnet sur l'IP et sur le port, et cela fonctionne, donc /apparemment/ mon accès VPN semble bien configuré.
Quel port ? Le listener ?
Je ne connais absolument pas la configuration de cette base, ni l'origine de cette erreur: j'ai vu qu'il y avait un SQLNET.INBOUND_CONNECT_TIMEOUT mais je ne comprends pas très bien pourquoi cela fonctionnerait avec un accès VPN et pas l'autre.
D'après vous, cela peut-il venir de la config d'oracle ?
Y a-t-il des traces de la tentatives de connexion dans la log du listener ? Tu peux essayer d'augmenter son niveau de trace sinon.
Lionel wrote:
Bonjour,
Je souhaite accéder à une base Oracle 10g en passant pas un VPN.
J'ai deux clients VPN différents, ma tentative de connexion étant exactement
la meme dans les deux cas:
Avec l'accès VPN 1, tout fonctionne bien.
Avec l'accès VPN 2, j'ai un ORA-12170: TNS:Connect timeout occurred
systématique.
Qu'est-ce qui différencie les 2 accès ?
J'ai testé un telnet sur l'IP et sur le port, et cela fonctionne, donc
/apparemment/ mon accès VPN semble bien configuré.
Quel port ? Le listener ?
Je ne connais absolument pas la configuration de cette base, ni l'origine de
cette erreur: j'ai vu qu'il y avait un SQLNET.INBOUND_CONNECT_TIMEOUT mais
je ne comprends pas très bien pourquoi cela fonctionnerait avec un accès VPN
et pas l'autre.
D'après vous, cela peut-il venir de la config d'oracle ?
Y a-t-il des traces de la tentatives de connexion dans la log du
listener ? Tu peux essayer d'augmenter son niveau de trace sinon.
Je souhaite accéder à une base Oracle 10g en passant pas un VPN. J'ai deux clients VPN différents, ma tentative de connexion étant exactement la meme dans les deux cas: Avec l'accès VPN 1, tout fonctionne bien. Avec l'accès VPN 2, j'ai un ORA-12170: TNS:Connect timeout occurred systématique.
Qu'est-ce qui différencie les 2 accès ?
J'ai testé un telnet sur l'IP et sur le port, et cela fonctionne, donc /apparemment/ mon accès VPN semble bien configuré.
Quel port ? Le listener ?
Je ne connais absolument pas la configuration de cette base, ni l'origine de cette erreur: j'ai vu qu'il y avait un SQLNET.INBOUND_CONNECT_TIMEOUT mais je ne comprends pas très bien pourquoi cela fonctionnerait avec un accès VPN et pas l'autre.
D'après vous, cela peut-il venir de la config d'oracle ?
Y a-t-il des traces de la tentatives de connexion dans la log du listener ? Tu peux essayer d'augmenter son niveau de trace sinon.
Lionel
Jerome Vitalis wrote:
Avec l'accès VPN 1, tout fonctionne bien. Avec l'accès VPN 2, j'ai un ORA-12170: TNS:Connect timeout occurred systématique.
Qu'est-ce qui différencie les 2 accès ?
Je n'en ai ùalheureusement aucune idée... Un cisco et un nortel
J'ai testé un telnet sur l'IP et sur le port, et cela fonctionne, donc /apparemment/ mon accès VPN semble bien configuré.
Quel port ? Le listener ?
sur le port du listener (1521) afin d'etre certain que ce n'est pas le VPN qui m'interdit l'accès à ce port sur cette IP. J'ai testé avec un autre port sur la meme IP, j'ai bien un message d'erreur réseau. sauf erreur, l'accès ce port me suffit.
Y a-t-il des traces de la tentatives de connexion dans la log du listener ? Tu peux essayer d'augmenter son niveau de trace sinon.
Le problème c'est que ce n'est pas ma base et que je ne connais pas le niveau de compétence des gens qui s'occupent de cette base. Je voudrais leur donner la solution pour qu'il résolvent mon problème sans investiguer pendant 2 mois, mais j'ai bien peur de ne pouvoir la trouver.
Jerome Vitalis wrote:
Avec l'accès VPN 1, tout fonctionne bien.
Avec l'accès VPN 2, j'ai un ORA-12170: TNS:Connect timeout occurred
systématique.
Qu'est-ce qui différencie les 2 accès ?
Je n'en ai ùalheureusement aucune idée...
Un cisco et un nortel
J'ai testé un telnet sur l'IP et sur le port, et cela fonctionne,
donc /apparemment/ mon accès VPN semble bien configuré.
Quel port ? Le listener ?
sur le port du listener (1521) afin d'etre certain que ce n'est pas le VPN
qui m'interdit l'accès à ce port sur cette IP.
J'ai testé avec un autre port sur la meme IP, j'ai bien un message d'erreur
réseau.
sauf erreur, l'accès ce port me suffit.
Y a-t-il des traces de la tentatives de connexion dans la log du
listener ? Tu peux essayer d'augmenter son niveau de trace sinon.
Le problème c'est que ce n'est pas ma base et que je ne connais pas le
niveau de compétence des gens qui s'occupent de cette base.
Je voudrais leur donner la solution pour qu'il résolvent mon problème sans
investiguer pendant 2 mois, mais j'ai bien peur de ne pouvoir la trouver.
Avec l'accès VPN 1, tout fonctionne bien. Avec l'accès VPN 2, j'ai un ORA-12170: TNS:Connect timeout occurred systématique.
Qu'est-ce qui différencie les 2 accès ?
Je n'en ai ùalheureusement aucune idée... Un cisco et un nortel
J'ai testé un telnet sur l'IP et sur le port, et cela fonctionne, donc /apparemment/ mon accès VPN semble bien configuré.
Quel port ? Le listener ?
sur le port du listener (1521) afin d'etre certain que ce n'est pas le VPN qui m'interdit l'accès à ce port sur cette IP. J'ai testé avec un autre port sur la meme IP, j'ai bien un message d'erreur réseau. sauf erreur, l'accès ce port me suffit.
Y a-t-il des traces de la tentatives de connexion dans la log du listener ? Tu peux essayer d'augmenter son niveau de trace sinon.
Le problème c'est que ce n'est pas ma base et que je ne connais pas le niveau de compétence des gens qui s'occupent de cette base. Je voudrais leur donner la solution pour qu'il résolvent mon problème sans investiguer pendant 2 mois, mais j'ai bien peur de ne pouvoir la trouver.
see
Lionel wrote:
sur le port du listener (1521) afin d'etre certain que ce n'est pas le VPN qui m'interdit l'accès à ce port sur cette IP.
Attention, le port 1521 est utilisé pour l'initialisation de la connexion mais la session se déroule ensuite sur un autre port.
Le fonctionnement (dans le cas d'une connexion dédié) est le suivant : - Le client envoit une requête d'ouverture de connexion au listener (port 1521 dans ton cas) - le listener lance un process (dédié à cette nouvelle session) et renvoit au demandeur le numéro du port surlequel va se dérouler la session (c'est le port utilisé par le process dédié). - Le client utilise alors ce nouveau port pour dialoguer avec le process serveur.
Dans le cas de firewall, le problème est que le numéro port renvoyé au client est dans les données applicatives de la trame. Sauf si le firewall est capable d'interpréter le protocole Oracle Net, il n'aura pas moyen de deviner sur quel port va se dérouler la connexion. Donc, l'ouverture du seul port 1521 est insuffisante pour assurer le dialogue entre le client et la base Oracle.
-- Bruno http://errance.lirano.net (photographies)
Lionel wrote:
sur le port du listener (1521) afin d'etre certain que ce n'est pas le VPN
qui m'interdit l'accès à ce port sur cette IP.
Attention, le port 1521 est utilisé pour l'initialisation de la
connexion mais la session se déroule ensuite sur un autre port.
Le fonctionnement (dans le cas d'une connexion dédié) est le suivant :
- Le client envoit une requête d'ouverture de connexion au listener
(port 1521 dans ton cas)
- le listener lance un process (dédié à cette nouvelle session) et
renvoit au demandeur le numéro du port surlequel va se dérouler la
session (c'est le port utilisé par le process dédié).
- Le client utilise alors ce nouveau port pour dialoguer avec le process
serveur.
Dans le cas de firewall, le problème est que le numéro port renvoyé au
client est dans les données applicatives de la trame. Sauf si le
firewall est capable d'interpréter le protocole Oracle Net, il n'aura
pas moyen de deviner sur quel port va se dérouler la connexion.
Donc, l'ouverture du seul port 1521 est insuffisante pour assurer le
dialogue entre le client et la base Oracle.
--
Bruno
http://errance.lirano.net (photographies)
sur le port du listener (1521) afin d'etre certain que ce n'est pas le VPN qui m'interdit l'accès à ce port sur cette IP.
Attention, le port 1521 est utilisé pour l'initialisation de la connexion mais la session se déroule ensuite sur un autre port.
Le fonctionnement (dans le cas d'une connexion dédié) est le suivant : - Le client envoit une requête d'ouverture de connexion au listener (port 1521 dans ton cas) - le listener lance un process (dédié à cette nouvelle session) et renvoit au demandeur le numéro du port surlequel va se dérouler la session (c'est le port utilisé par le process dédié). - Le client utilise alors ce nouveau port pour dialoguer avec le process serveur.
Dans le cas de firewall, le problème est que le numéro port renvoyé au client est dans les données applicatives de la trame. Sauf si le firewall est capable d'interpréter le protocole Oracle Net, il n'aura pas moyen de deviner sur quel port va se dérouler la connexion. Donc, l'ouverture du seul port 1521 est insuffisante pour assurer le dialogue entre le client et la base Oracle.
-- Bruno http://errance.lirano.net (photographies)
Lionel
Bruno Jargot wrote:
Attention, le port 1521 est utilisé pour l'initialisation de la connexion mais la session se déroule ensuite sur un autre port.
Le fonctionnement (dans le cas d'une connexion dédié) est le suivant : - Le client envoit une requête d'ouverture de connexion au listener (port 1521 dans ton cas) - le listener lance un process (dédié à cette nouvelle session) et renvoit au demandeur le numéro du port surlequel va se dérouler la session (c'est le port utilisé par le process dédié). - Le client utilise alors ce nouveau port pour dialoguer avec le process serveur.
Dans le cas de firewall, le problème est que le numéro port renvoyé au client est dans les données applicatives de la trame. Sauf si le firewall est capable d'interpréter le protocole Oracle Net, il n'aura pas moyen de deviner sur quel port va se dérouler la connexion. Donc, l'ouverture du seul port 1521 est insuffisante pour assurer le dialogue entre le client et la base Oracle.
OK, merci pour ces précisions, je comprends mieux. L'accès VPN qui fonctionne est un accès VPN full (aucune restriction) il est donc normal qu'il ne pose aucun souci. Sur l'autre accès qui pose problème, tout est verrouillé sauf les IP/ports que j'ai fait ouvrir.
Par contre, un détail m'étonne: sur l'accès VPN qui ne passe pas avec la base Oracle 1, j'ai tenté une connexion sur deux autres bases Oracle 10g, et là ça fonctionne. Pareil, je n'ai demandé que IP et port 1521. Donc j'en déduis que les 2 bases qui marchent ne sont pas derrière le meme firewall et que ce dernier est capable de laisser passer le dialogue. C'est la seule explication. La base qui pose problème est probablement en install par défaut sans paramétrage particulier niveau sécurité.
Y a-t-il un moyen de connaitre le port utilisé par oracle pour le dialogue ? (si possible à l'aide d'une requete SQL comme ca je peux le trouver seul)
Bruno Jargot wrote:
Attention, le port 1521 est utilisé pour l'initialisation de la
connexion mais la session se déroule ensuite sur un autre port.
Le fonctionnement (dans le cas d'une connexion dédié) est le suivant :
- Le client envoit une requête d'ouverture de connexion au listener
(port 1521 dans ton cas)
- le listener lance un process (dédié à cette nouvelle session) et
renvoit au demandeur le numéro du port surlequel va se dérouler la
session (c'est le port utilisé par le process dédié).
- Le client utilise alors ce nouveau port pour dialoguer avec le
process serveur.
Dans le cas de firewall, le problème est que le numéro port renvoyé au
client est dans les données applicatives de la trame. Sauf si le
firewall est capable d'interpréter le protocole Oracle Net, il n'aura
pas moyen de deviner sur quel port va se dérouler la connexion.
Donc, l'ouverture du seul port 1521 est insuffisante pour assurer le
dialogue entre le client et la base Oracle.
OK, merci pour ces précisions, je comprends mieux.
L'accès VPN qui fonctionne est un accès VPN full (aucune restriction) il est
donc normal qu'il ne pose aucun souci.
Sur l'autre accès qui pose problème, tout est verrouillé sauf les IP/ports
que j'ai fait ouvrir.
Par contre, un détail m'étonne: sur l'accès VPN qui ne passe pas avec la
base Oracle 1, j'ai tenté une connexion sur deux autres bases Oracle 10g, et
là ça fonctionne. Pareil, je n'ai demandé que IP et port 1521.
Donc j'en déduis que les 2 bases qui marchent ne sont pas derrière le meme
firewall et que ce dernier est capable de laisser passer le dialogue. C'est
la seule explication. La base qui pose problème est probablement en install
par défaut sans paramétrage particulier niveau sécurité.
Y a-t-il un moyen de connaitre le port utilisé par oracle pour le dialogue
?
(si possible à l'aide d'une requete SQL comme ca je peux le trouver seul)
Attention, le port 1521 est utilisé pour l'initialisation de la connexion mais la session se déroule ensuite sur un autre port.
Le fonctionnement (dans le cas d'une connexion dédié) est le suivant : - Le client envoit une requête d'ouverture de connexion au listener (port 1521 dans ton cas) - le listener lance un process (dédié à cette nouvelle session) et renvoit au demandeur le numéro du port surlequel va se dérouler la session (c'est le port utilisé par le process dédié). - Le client utilise alors ce nouveau port pour dialoguer avec le process serveur.
Dans le cas de firewall, le problème est que le numéro port renvoyé au client est dans les données applicatives de la trame. Sauf si le firewall est capable d'interpréter le protocole Oracle Net, il n'aura pas moyen de deviner sur quel port va se dérouler la connexion. Donc, l'ouverture du seul port 1521 est insuffisante pour assurer le dialogue entre le client et la base Oracle.
OK, merci pour ces précisions, je comprends mieux. L'accès VPN qui fonctionne est un accès VPN full (aucune restriction) il est donc normal qu'il ne pose aucun souci. Sur l'autre accès qui pose problème, tout est verrouillé sauf les IP/ports que j'ai fait ouvrir.
Par contre, un détail m'étonne: sur l'accès VPN qui ne passe pas avec la base Oracle 1, j'ai tenté une connexion sur deux autres bases Oracle 10g, et là ça fonctionne. Pareil, je n'ai demandé que IP et port 1521. Donc j'en déduis que les 2 bases qui marchent ne sont pas derrière le meme firewall et que ce dernier est capable de laisser passer le dialogue. C'est la seule explication. La base qui pose problème est probablement en install par défaut sans paramétrage particulier niveau sécurité.
Y a-t-il un moyen de connaitre le port utilisé par oracle pour le dialogue ? (si possible à l'aide d'une requete SQL comme ca je peux le trouver seul)
Lionel
Lionel wrote:
- le listener lance un process (dédié à cette nouvelle session) et renvoit au demandeur le numéro du port surlequel va se dérouler la session (c'est le port utilisé par le process dédié). - Le client utilise alors ce nouveau port pour dialoguer avec le process serveur.
Après avoir lu ceci http://www.dbforums.com/archive/index.php/t-1077026.html J'ai bien peur que la base Oracle posant problème soit sous windows. C'est pas gagné...
Lionel wrote:
- le listener lance un process (dédié à cette nouvelle session) et
renvoit au demandeur le numéro du port surlequel va se dérouler la
session (c'est le port utilisé par le process dédié).
- Le client utilise alors ce nouveau port pour dialoguer avec le
process serveur.
Après avoir lu ceci
http://www.dbforums.com/archive/index.php/t-1077026.html
J'ai bien peur que la base Oracle posant problème soit sous windows.
C'est pas gagné...
- le listener lance un process (dédié à cette nouvelle session) et renvoit au demandeur le numéro du port surlequel va se dérouler la session (c'est le port utilisé par le process dédié). - Le client utilise alors ce nouveau port pour dialoguer avec le process serveur.
Après avoir lu ceci http://www.dbforums.com/archive/index.php/t-1077026.html J'ai bien peur que la base Oracle posant problème soit sous windows. C'est pas gagné...
Lionel
Lionel wrote:
Après avoir lu ceci http://www.dbforums.com/archive/index.php/t-1077026.html J'ai bien peur que la base Oracle posant problème soit sous windows. C'est pas gagné...
J'ai la solution simple (je préfère éviter de passer par les DBA tant que possible...): trouver la plage de ports utilisée par Oracle et faire ouvrir toute cette plage sur mon accès VPN. Qqun aurait une idée de la plage potentiellement utilisée par Oracle ?
Lionel wrote:
Après avoir lu ceci
http://www.dbforums.com/archive/index.php/t-1077026.html
J'ai bien peur que la base Oracle posant problème soit sous windows.
C'est pas gagné...
J'ai la solution simple (je préfère éviter de passer par les DBA tant que
possible...): trouver la plage de ports utilisée par Oracle et faire ouvrir
toute cette plage sur mon accès VPN.
Qqun aurait une idée de la plage potentiellement utilisée par Oracle ?
Après avoir lu ceci http://www.dbforums.com/archive/index.php/t-1077026.html J'ai bien peur que la base Oracle posant problème soit sous windows. C'est pas gagné...
J'ai la solution simple (je préfère éviter de passer par les DBA tant que possible...): trouver la plage de ports utilisée par Oracle et faire ouvrir toute cette plage sur mon accès VPN. Qqun aurait une idée de la plage potentiellement utilisée par Oracle ?
vitalisman
On Dec 20, 8:23 pm, "Lionel" <SPAMcoollATfreePOINTfr> wrote:
Lionel wrote: > Après avoir lu ceci >http://www.dbforums.com/archive/index.php/t-1077026.html > J'ai bien peur que la base Oracle posant problème soit sous windows. > C'est pas gagné...
J'ai la solution simple (je préfère éviter de passer par les DBA tan t que possible...): trouver la plage de ports utilisée par Oracle et faire ouv rir toute cette plage sur mon accès VPN. Qqun aurait une idée de la plage potentiellement utilisée par Oracle ?
Sous Windows, on peut apparemment forcer l'utilisation de la socket partagée (sur le 1521 par exemple) comme sur Unix grâce au paramètre USE_SHARED_SOCKET (jamais testé de mon côté.)
Jérôme
On Dec 20, 8:23 pm, "Lionel" <SPAMcoollATfreePOINTfr> wrote:
Lionel wrote:
> Après avoir lu ceci
>http://www.dbforums.com/archive/index.php/t-1077026.html
> J'ai bien peur que la base Oracle posant problème soit sous windows.
> C'est pas gagné...
J'ai la solution simple (je préfère éviter de passer par les DBA tan t que
possible...): trouver la plage de ports utilisée par Oracle et faire ouv rir
toute cette plage sur mon accès VPN.
Qqun aurait une idée de la plage potentiellement utilisée par Oracle ?
Sous Windows, on peut apparemment forcer l'utilisation de la socket
partagée (sur le 1521 par exemple) comme sur Unix grâce au paramètre
USE_SHARED_SOCKET (jamais testé de mon côté.)
On Dec 20, 8:23 pm, "Lionel" <SPAMcoollATfreePOINTfr> wrote:
Lionel wrote: > Après avoir lu ceci >http://www.dbforums.com/archive/index.php/t-1077026.html > J'ai bien peur que la base Oracle posant problème soit sous windows. > C'est pas gagné...
J'ai la solution simple (je préfère éviter de passer par les DBA tan t que possible...): trouver la plage de ports utilisée par Oracle et faire ouv rir toute cette plage sur mon accès VPN. Qqun aurait une idée de la plage potentiellement utilisée par Oracle ?
Sous Windows, on peut apparemment forcer l'utilisation de la socket partagée (sur le 1521 par exemple) comme sur Unix grâce au paramètre USE_SHARED_SOCKET (jamais testé de mon côté.)
Jérôme
Lionel
wrote:
Sous Windows, on peut apparemment forcer l'utilisation de la socket partagée (sur le 1521 par exemple) comme sur Unix grâce au paramètre USE_SHARED_SOCKET (jamais testé de mon côté.)
Je sais, mais si je demande ça aux admin Orale, j'en ai pour 3 semaines (mois?) avant que ce soit fait et ça va etre la panique. Modifier mon accès VPN sera moins douloureux...
vitalisman@gmail.com wrote:
Sous Windows, on peut apparemment forcer l'utilisation de la socket
partagée (sur le 1521 par exemple) comme sur Unix grâce au paramètre
USE_SHARED_SOCKET (jamais testé de mon côté.)
Je sais, mais si je demande ça aux admin Orale, j'en ai pour 3 semaines
(mois?) avant que ce soit fait et ça va etre la panique.
Modifier mon accès VPN sera moins douloureux...
Sous Windows, on peut apparemment forcer l'utilisation de la socket partagée (sur le 1521 par exemple) comme sur Unix grâce au paramètre USE_SHARED_SOCKET (jamais testé de mon côté.)
Je sais, mais si je demande ça aux admin Orale, j'en ai pour 3 semaines (mois?) avant que ce soit fait et ça va etre la panique. Modifier mon accès VPN sera moins douloureux...
see
Lionel <SPAMcoollATfreePOINTfr> wrote:
wrote: > Sous Windows, on peut apparemment forcer l'utilisation de la socket > partagée (sur le 1521 par exemple) comme sur Unix grâce au paramètre > USE_SHARED_SOCKET (jamais testé de mon côté.)
Je sais, mais si je demande ça aux admin Orale, j'en ai pour 3 semaines (mois?) avant que ce soit fait et ça va etre la panique. Modifier mon accès VPN sera moins douloureux...
C'est pas bien de dire du mal des confrères -;)
Je pense que la seule possibilité, sans faire intervenir les dba, est d'avoir un firewall "Oracle aware" (c'est à dire capable d'interpréter les trames Oracle Net et d'ouvrir en conséquences les ports nécessaires). À ma connaissance, il n'est pas possible de définir une plage de port à ouvrir (à moins d'ouvrir tous les ports mais dans ce cas, à quoi bon avoir un firewall ...). -- Bruno http://errance.lirano.net (photographies)
Lionel <SPAMcoollATfreePOINTfr> wrote:
vitalisman@gmail.com wrote:
> Sous Windows, on peut apparemment forcer l'utilisation de la socket
> partagée (sur le 1521 par exemple) comme sur Unix grâce au paramètre
> USE_SHARED_SOCKET (jamais testé de mon côté.)
Je sais, mais si je demande ça aux admin Orale, j'en ai pour 3 semaines
(mois?) avant que ce soit fait et ça va etre la panique.
Modifier mon accès VPN sera moins douloureux...
C'est pas bien de dire du mal des confrères -;)
Je pense que la seule possibilité, sans faire intervenir les dba, est
d'avoir un firewall "Oracle aware" (c'est à dire capable d'interpréter
les trames Oracle Net et d'ouvrir en conséquences les ports
nécessaires).
À ma connaissance, il n'est pas possible de définir une plage de port à
ouvrir (à moins d'ouvrir tous les ports mais dans ce cas, à quoi bon
avoir un firewall ...).
--
Bruno
http://errance.lirano.net (photographies)
wrote: > Sous Windows, on peut apparemment forcer l'utilisation de la socket > partagée (sur le 1521 par exemple) comme sur Unix grâce au paramètre > USE_SHARED_SOCKET (jamais testé de mon côté.)
Je sais, mais si je demande ça aux admin Orale, j'en ai pour 3 semaines (mois?) avant que ce soit fait et ça va etre la panique. Modifier mon accès VPN sera moins douloureux...
C'est pas bien de dire du mal des confrères -;)
Je pense que la seule possibilité, sans faire intervenir les dba, est d'avoir un firewall "Oracle aware" (c'est à dire capable d'interpréter les trames Oracle Net et d'ouvrir en conséquences les ports nécessaires). À ma connaissance, il n'est pas possible de définir une plage de port à ouvrir (à moins d'ouvrir tous les ports mais dans ce cas, à quoi bon avoir un firewall ...). -- Bruno http://errance.lirano.net (photographies)
