| Solving Firewall Problems on Windows [ID 68652.1] |
|
| |
修改时间 13-APR-2011 类型 BULLETIN 状态 PUBLISHED |
|
Applies to:
Oracle Net Services - Version: 2.3.4.0.0 to 11.2.0.2 - Release: to 11.2
Generic Windows
ORA-12535
TNS-12535
USE_SHARED_SOCKET
Purpose
This article describes how to get around firewall problems with SQL*Net or Net*8 on Windows servers.
Scope and Application
SCOPE & APPLICATION
A
firewall is a secure gateway that controls the traffic into and out of a
company's internal network. Firewalls can cause problems when a SQL*Net
client outside the firewall tries to connect to an Oracle database on
Windows NT inside the firewall, or vice versa. The default Oracle
Listener listens on port 1521. It may not be sufficient to configure the
firewall to allow access through port 1521 so the SQL*Net clients will
be able to connect. To understand why the TNS connect will fail, it is
necessary to understand how a SQL*Net connection on Windows NT works.
When
a client initiates a TNS connect, a TCP connection is established with
port 1521. A TNS CONNECT packet is then sent to the listener. On UNIX
systems the listener process will fork a new Oracle process to deal with
the new incoming connection. With UNIX, forked processes will inherit
the resources owned by the parent process such as the file handle that
represents the TCP socket. In Windows NT, the Listener tells the Oracle
Service to spawn a thread.
Earlier releases of SQL*Net for
Windows NT used the WINSOCK V1.1 API. With this version of WINSOCK there
is no capability of passing a TCP socket between two processes, such as
from the Listener to the Oracle Service, and so there was no way to
inherit the TCP socket. This restriction forced the client to have to
create a new TCP connection to the new thread. To do this, the thread
randomly selects a new TCP port to use for the connection request, for
example port 10087, and informs the listener to redirect the Client to
it.
The listener now informs the client that they need to
REDIRECT the connection attempt to this newly selected networking
endpoint. The listener does this by sending a TNS REDIRECT packet to the
client with details of the new port to reconnect to. The client drops
the existing TCP connection and issues a TCP Connect sequence to the new
TCP port, followed by a TNS Connect packet. The server thread accepts
the TCP connect and responds with a TNS ACCEPT packet. The Client
exchanges various TNS packets and then logs into the Database.
So,
if you create an Access Control List (ACL) on the firewall to allow
connects through port 1521, after the REDIRECT packet has been sent to
the client and the TCP connection to port 1521 is closed, the firewall
will not allow the TCP connection to port 10087 so the TNS connection
will fail. As the REDIRECT port that gets generated is entirely at
random, it would not be secure to allow connections to this random port
range in the firewall as it begins to defeat the purpose of the
firewall.
Solving Firewall Problems on Windows
note:62528.1note:62528.1 /To resolve this problem there are several options:
- This step should only be performed by the firewall administrator and
only if they feel this is a viable workaround for their company.
Otherwise, skip to step 2. This would be to configure ACL on the
firewall to limit IP addresses rather than port numbers. This is not a
very secure option.
- Use Oracle Connection Manager. Oracle Connection Manager will
"absorb" the REDIRECT as it all occurs on the server side of the
firewall. For further information on Connection Manager and how to
configure it, refer to Note 62528.1.
- If you are on Oracle version 8 or higher on the Database, you can
use the WINSOCK V2 API feature of Shared Sockets. This allows a socket
to be shared (or passed) between processes. To use this functionality in
a single Oracle Home, under the Registry key
HKEY_LOCAL_MACHINESOFTWAREORACLE create USE_SHARED_SOCKET as a
STRING_VALUE and set it to TRUE. If you are running multiple Oracle
Homes, view the %ORACLE_HOMEbinoracle.key file to find which registry
key to add the parameter USE_SHARED_SOCKET.
Please see Note 124140.1 for greater detail on this Windows feature.
WARNING: When using this method you must restart all Oracle processes for them to pick up the registry change.
Note: This parameter only works
in dedicated server mode in a TCP/IP environment and will not work for
the Multi-Threaded Server (MTS) configuration. To spawn a dedicated
server for an instance of Oracle Database not associated with the same
Oracle home as the listener and have shared socket enabled, you must
also set the parameter USE_SHARED_SOCKET for both Oracle homes.
Note: If this parameter is set, you cannot use a version 8.0 or later listener to spawn Oracle7 release 7.x databases.
Note: USE_SHARED_SOCKET was
introduced in Oracle version 8.0. It was set off by default in 8.0 to
10.0. The default is set to true in 10.1 and later. This parameter is
planned to be deprecated in a future release.
References
NOTE:62528.1 - Using Connection Manager (CMAN) as a MultiProtocol Interchange (MPI)
NOTE:124140.1 - How to configure USE_SHARED_SOCKET on Windows NT/2000
|
相关的
|
[@more@]
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/161195/viewspace-1053133/
,如需转载,请注明出处,否则将追究法律责任。