Lock the Door with Connection Manager
I spend a great deal otf my time working out of my home office either writing or editing books about Oracle. To facilitate my work, I run a small Oracle9i database on one of my PCs. Recently I decided to give a friend and fellow author access to this database via the Internet. To give that access, I had to overcome a number of hurdles:
- I needed to give my friend a stable address for my server, but my ISP would not give me a static IP address.
- I needed to open up a port in my firewall so that my friend could contact my Oracle Net Services listener.
- I needed to deal with the redirect "problem" that comes about when the listener hands off a new connection to a dedicated server process, changing the port number in the process.
- I wanted to restrict access to my network to as small a pool of people as possible; I didn't want everyone in the world to be able to contact my listener and try to guess my database passwords.
Oracle Connection Manager played a key role in resolving the last three of these issues. Read on to learn more.
Solving the IP address problem
To connect my home network to the Internet via my DSL connection, I use a UGate-3200 Cable/xDSL Internet Sharing Gateway, made by the now defunct Maxgate Inc. My first order of business was to configure the UGate-3200's dynamic DNS features as shown in Figure 1.
Figure 1. Configuring dynamic DNS
From here on out, the host name gennick.ugate.net would resolve to my network's external IP address. Whenever my ISP changed that address, the UGate-3200 would update DNS servers maintained by Tzolkin Corporation, my dynamic DNS service provider.
To learn more about how my home network is configured, read my series of three articles titled Installing a Home Network. Also read DSL Comes to Munising.
Opening up a port
My next step was to open up a port and allow access to the PC on which I was running Oracle. Using the UGate-3200's Virtual Server feature (see Figure 2), I opened up port 1630 and directed it to the PC addressed as 192.168.0.101 on my internal network.
Figure 2. Opening up a port
All inbound traffic to port 1630 is now directed to 192.168.0.101, which happens to be the IP address of my Oracle server. All other PCs on my network remain out of reach from the Internet at large.
Solving the "redirect" problem
Did you notice in Figure 2 that the port I opened up was 1630 (the default Connection Manager port) rather than 1521 (the default listener port)? I did that for a reason. I run my database in dedicated server mode, and, as you may know, when the listener hands a new connection off to a dedicated server process, it does so using a random port number. Randomness in this case is not good, because my gateway blocks all but a specified list of ports, and I really want that list to contain only one port. This is where Connection Manager comes into play.
Connection Manager acts as an intermediary between a client PC and my database. Internet clients contact Connection Manager via a port number that never changes, and Connection Manager relays communications to and from the listener and dedicated server processes running on my side of the firewall (my gateway acts as a firewall). Figure 3 illustrates this solution.
Figure 3. Connection Manager as an intermediary
With Connection Manager in place, my friend could finally connect to my database using a net service name defined as follows:
DONNA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = gennick.ugate.net)(PORT = 1630))
(ADDRESS = (PROTOCOL = TCP)(HOST = donna.gennick.org)(PORT = 1521))
(SOURCE_ROUTE = yes)
(FAILOVER = false)
)
(CONNECT_DATA =
(SERVICE_NAME = donna.gennick.org)
)
)
Notice that this net service name specifies two addresses. The first address is used by the client (which must be running Net8 or Oracle Net Services) to connect to the instance of Connection Manager running on my PC. The client passes the second address to Connection Manager, and Connection Manager uses that second address to connect to my database.
To learn more about Connection Manager, read my recent book—Oracle Net8 Configuration & Troubleshooting.
Keeping out the unwashed masses
Now we come to my last hurdle. My friend could connect to my database over the Internet, but so could anyone else in the world with an Internet connection at their disposal. Now I don't know how many people out there know enough to sniff out my net service name definition and start guessing my Oracle passwords, but I know I don't want to find out. The question was, how do I allow only my friend in, while denying any access to Internet users at large? Once again, it was Connection Manager to the rescue.
One of Connection Manager's features is the ability to act as sort of a firewall. You can configure Connection Manager to accept connections only from specific IP addresses, or groups of IP addresses. You do this by configuring access rules, and the one shown next is the one I wrote to let my friend in:
CMAN_RULES =
(RULE_LIST =
(RULE =
(SRC = 64.26.x.x)
(DST = donna.gennick.org)
(SRV = donna.gennick.org)
(act = accept)
)
)
The IP address block specified in the rule matches the range of IP addresses that my friend is assigned when he connects to the Internet from his office. I'm actually not limiting access just to one person, but rather to anyone from my friend's company. That's not bad. I think I can reasonably trust those people. The risk of someone breaking into my database isn't zero, but it's certainly a whole lot better than if the door were wide open to Internet users at large.
Conclusion
Connection Manager's features are key parts to the solution I put together to give my friend access to my Oracle9i database. Could I have done this without Connection Manager? Yes, but I couldn't have done it as well. I could have configured my database to run in multithreaded server mode, and configured a dispatcher with a static IP address. That would have solved the redirect "problem". However, only Connection Manager gave me the ability to restrict connections to a small range of IP addresses.