HISPACTA Hell

Monday, June 29, 2009

Double port forwarding

I had a problem today that involved a couple levels of SSH port forwarding...

I was evaluating an email vendor who had asked what machine they should expect my test emails to be sent from. I replied with our dev02 server, thinking that I'd just create a little web page on our reportapp that you could "click button to send mime email" or something.

In the end, I wound up writing the email test as a JUnit test case, which I could execute on demand via NetBeans on my localhost.

So the problem was the vendor was expecting traffic from dev02, but I was only generating traffic from localhost. Complicating the matter was that I couldn't get directly to dev02 from localhost...I had to go through another server named "gateway".

  1. Tunnel my localhost's port 5555 to gateway's port 5555:
    ssh -AL 5555:localhost:5555 my.name@gateway.mycompany.com

    Technically, I think the "-A" flag isn't necessary (it just forwards my authentication token, which I have set up so I don't need to log in)

  2. The first command got me out to gateway with the 5555 tunnel open. Now tunnel gateway's 5555 port to dev02 and have dev02 forward that port to the email vendor's machine and port (in bold):
    ssh -L 5555:1.2.3.4:9936 my.name@dev02.mycompany.com

  3. Then in my unit test, I can send mail to a JavaMailSenderImpl setup with host "localhost" and post "5555" and it ends up being sent to 1.2.3.4 on port 9936, and the vendor sees the traffic as dev02's IP and lets it through the firewall.

Note that I'm pretty sure you can combine both steps 1 and 2 into a single step by using the fact that the ssh port forwarding syntax command can take a command to run on the remote box (the remote command to run is itself an ssh port forwarding command). Something like this. . . though use at your own risk:

ssh -AnfL 5555:localhost:5555 my.name@gateway.mycompany.com \
"ssh -L 5555:1.2.3.4:9936 my.name@dev02.mycompany.com"


Maybe try adding a "sleep 30" at the end of that command (inside the double quote) if the -nf flags try to close it immediately

Friday, June 26, 2009

Reminding myself about Base64

I've learned and forgotten Base64 a couple times now, and after I re-looked up how it worked, I thought I'd take advantage of the old adage about "you remember 80% of what you write" by blogging my own explanation of Base64.

Here goes...

Let's say you wanted to send the string "{|}" in an email as some sort of crude emoticon. Those are 3 characters that are in the ASCII character set, but they aren't in the Base64 encoding table. They could just as easily be 3 non-printable characters or maybe multi-byte UTF-16 character points, but let's just stick with {|} for this example.

The 3 bytes for those ASCII characters are:
{ = 7B = 123 = 01111011
| = 7C = 124 = 01111100
} = 7D = 135 = 01111101

String those 3 bytes together into a single 24 bit stream is:
011110110111110001111101

The number 24 is both (3 * 8) and (4 * 6), so splitting it into 4 x 6-bit chunks yeilds:
011110 = 30
110111 = 55
110001 = 49
111101 = 61

Now looking those up in the Base64 conversion chart yields:
011110 = 30 = e
110111 = 55 = 3
110001 = 49 = x
111101 = 61 = 9

So "{|}" is "e3x9" in Base64 encoding.

I found this nifty base64 encoder/decoder site to validate my gorilla math.