1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
|
Tunneling DCC over ssh using dircproxy
---------------------------------------
WARNING, THIS IS NOT EASY TO DO.
Don't read any further unless you are a fully qualified UNIX guru,
complete with the long hair and sandals.
Why do this?
============
DCC chats and sends will not work if your desktop is behind a
firewall if that firewall prevents you from freely accessing the
Internet, or prevents people from connecting to you.
There are normal three ways around this.
o Placing rules in the firewall that allow certain ports such as IRC
through, and using the `dcc_proxy_ports` config option to limit
dircproxy's port range to that which you've allowed.
You probably don't have that kind of access to the firewall though,
or wouldn't be allowed to if you did.
o Install dircproxy on the firewall itself, so it can freely proxy
between both networks without being affected by the rules on the
firewall.
Again, you probably don't have that kind of access. Its also not
good practice anyway.
o Piggy back your IRC traffic on something that the firewall does
let through.
Most firewalls let ssh traffic through, at least in the out-bound
direction, and that's perfect. This is what this file tells you
how to do.
What do I need?
===============
For this to work, the firewall must allow ssh traffic through
and must allow connections to be made from inside the firewall
to outside. It probably does, or you can probably persuade the
firewall admin to let ssh through, its secure after all.
You will also need two UNIX machines, one inside the firewall and
one outside.
The inside one must have dircproxy installed and ssh installed.
The best choice is probably your desktop if that runs UNIX.
(You *could* use a Windows machine if you can get dircproxy to
compile on it and use something like SecureCRT of F-Secure SSH to
do the tunnels).
The outside machine must also have dircproxy installed, and must
have the ssh daemon (sshd) installed and running.
Setting up the Tunnels
======================
You'll need three different tunnels across the firewall from
the machine inside to the machine outside. One to forward the
IRC connection itself, and a further two for DCC traffic, one
for incoming and one for outgoing. You can do this with one ssh
command, specifying all three tunnels at the same time. (Replace
'outside.firewall' with the hostname of the machine outside).
$ ssh -L 57010:localhost:57000 \
-L 57110:localhost:57100 \
-R 57110:localhost:57100 outside.firewall
This will actually start a shell on the remote machine. Exiting from
it will end the tunnels. For safety you may want to run this under
screen or something (if you've got that), as it doesn't run in the
background either. Its perfectly safe to close the tunnels while you
are detatched though - so you could put these in a shell script or
something instead and just run that when you want to attach.
Configuring dircproxy on the Outside machine
============================================
This will be the master dircproxy, connecting to the IRC server
itself and doing all the normal things such as logging etc.
Configure it as you normally would, except for the following two
options which need to be set as shown.
dcc_proxy_ports 57100
dcc_tunnel_outgoing 57110
This tells dircproxy to listen for DCC connections on port 57100,
which is pointed to by a tunnel, and that all outgoing DCCs from you
(which require a connection to you) should be sent through the tunnel
on port 57110.
This dircproxy is probably best run as a daemon (i.e. normally).
Configuring dircproxy on the Inside machine
===========================================
This dircproxy will be a simple slave, forwarding to the one outside
without doing anything clever. The configuration file should be left
untouched, only add a connection class, which should look like this.
connection {
password "encpass"
server "localhost:57010:pass"
disconnect_on_detach yes
dcc_proxy_ports 57100
dcc_tunnel_incoming 57110
}
Replace "encpass" with an encrypted password that should match
that you configure the IRC client with, and replace "pass" with
the unencrypted version of whatever you set the password to on the
dircproxy outside the firewall.
This tells dircproxy that incoming DCC requests to you (which require
you to connect to the remote server) should be sent through the tunnel
on port 57110.
You can run this dircproxy as a daemon or from inetd, whichever
suits you best.
Using dircproxy now
===================
Connect your IRC client to the dircproxy inside the firewall.
This will then connect through the tunnels to the dircproxy outside
the firewall which will connect to the IRC server for you.
When you detach your IRC client, the dircproxy inside the firewall
will disconnect from the one on the outside. This means you can
also exit the ssh session running the tunnels (thereby closing them).
When you want to reconnect, just start up the tunnels and dircproxy
again before you do (having left the one outside well alone). This
means that if you are using your desktop, you can still switch it off
over night etc without worrying about loosing your IRC link.
Small note: Because you can only use one listening port, you will only
be able to have one queued DCC request at a time. Others will be
rejected until the outstanding request either times out or is
accepted by you.
Another worthy note is that when using tunnels, you will see two sets
of messages from dircproxy informing you of its connections to remote
peers. The first set is the link between the two proxies being
established, the second set is the link being established to the
remote peer itself. This is normal and nothing to worry about.
Copyright (C) 2002 Scott James Remnant <scott@netsplit.com>.
All Rights Reserved.
|
