There was originally not going to be a second part to protecting your redo transport, but a comment on the original article has prompted me to go back and show what differences occur at the network level when you start using an ssh tunnel. So first up this is what you see when you are using an unencrypted transport mechanism (click to able to read it):
linuxrac1sb is the primary in the above, while linuxrac1 is the standby. Two things to point out from the non-encrypted transport, the originating port on the primary is not being allocated constantly, it is changing, but the destination port on the standby is always 1521 which is where this listener is listening on.
Now we setup the ssh tunnel:
ssh -N -L 3333:linuxrac1:1521 oracle@linuxrac1
The tcpdump of the encrypted case looks like:
So the data is always sent to the ssh port on the standby and you’ll also see the originating port is always constant and this is the established ssh tunnel connection:
[jason@linuxrac1sb ~]$ ps -ef|grep 3333
oracle 7144 8499 0 12:58 pts/2 00:00:00 ssh -N –L 3333:linuxrac1:1521 oracle@linuxrac1
[jason@linuxrac1sb ~]$ sudo lsof -p 7144
ssh 7144 oracle 3u IPv4 326890656 TCP linuxrac1sb:45993 >linuxrac1.nominet.org.uk:ssh (ESTABLISHED)
ssh 7144 oracle 4u IPv4 326890667 TCP localhost.localdomain:3333 (LISTEN)
(NOTE: above lsof has been snipped for brevity).
So this shows that as expected we are listening locally on port 3333 but that we have been randomly allocated port 45993 to connect to the standby. The tcpdump shows all communication to the standby originates from this port and goes to the ssh port of the standby. All the redo traffic that is sent from the primary is using the tunnel and is therefore encrypted, unlike the non-encrypted case I do not see any data in the redo traffic – it is all garbled.