On Nov 5, 2009, at 4:18 PM, Andy Spitzer wrote: > Woof! > > At the moment, sipXecs has several different methods to secure non SIP > TCP/IP communications amongst its processes. > > Some of them use https directly and have TLS keys and certs, and > authenticate either as a user with PIN, a special user with PIN, or > via a > "shared secret". The best examples of this are sipXconfig and > sipXrest. > Some of them use ssh-tunnels and port forwarding, such as POSTGRES > access > for CDRs. > > Some of them do not use TLS, but only accept connections from > localhost, > such as sipXivr, or FreeSWITCH (which has a trivial authentication > scheme). And some of the FreeSWITCH ports are wide open to the > world (the > XML-RPC one, I believe). > > As we move to a more distributed model, and use FreeSWITCH more and > more, > we need to enable access to the FS ports across machines (for example > conference recording and the IM bot both need remote access to > FreeSWITCH). In addition, we keep having to add TLS to each and every > process that needs it, adding complexity (which is why it isn't in > sipXivr > yet, as I got fed up mucking about with keystores and certs!) > > Instead of having each process implement it's own TLS, I was > wondering if > it would make more sense to have some kind of standard VPN setup > between > all hosts in a cluster. This way, host to host communications is > secured > and authenticated, and so we don't have to do it again for each > process. > This would also enable secure access to the third party processes like > FreeSWITCH and POSTGRES which don't do TLS by themselves. Non-public > facing applications would bind only to the "VPN" address or > "localhost", > and thus would not accept connections from outside the VPN. > > I must admit, I don't know enough about setting this up to make a > stab at > a proposal as to how to implement this. I'm thinking along like > lines of > OpenVPN. I know some of you are already VPN experts from previous > lives, > and hopefully you can help make sense of it all. I'm envisioning a > configuration that would create and maintain tunnels at boot time from > each host to every other host in a cluster, and set up the routing so > everyone can just talk as if they were on a LAN. > > Host names could be standardized (possibly based on roles?) and > entered > into /etc/hosts or DNS (by sipXconfig, natch), so if a process needs > to > access a process on a remote machine via the tunnel, it would > connect to > say "proxy2" or "conferencebridge3" which would map to the tunnel'ed > IP > address of the machine fulfilling that role. Perhaps hostnames > wouldn't > be needed at all, as sipXconfig would already know all the VPN IP > addresses and put them in all the correct places in the individual > config > files. > > Is this type of scheme possible? > > Does it make any sense, or am I rambling incoherently in an H1N1 > induced > haze? > > --Woof!
ssh tunneling would serve this purpose very well. It is also very easy to set up and administer. -Mardy _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
