Re: Connecting using an existing socket (libpq).
От | Keith C. Perry |
---|---|
Тема | Re: Connecting using an existing socket (libpq). |
Дата | |
Msg-id | 1074538213.400c26e508b10@webmail.vcsn.com обсуждение исходный текст |
Ответ на | Connecting using an existing socket (libpq). (jbi130@yahoo.com) |
Список | pgsql-general |
Quoting jbi130@yahoo.com: > I have a 3 tier client/server application where the client connection > to the server which then uses PostgreSQL. I'd like to extend the > client to have direct access to PostgreSQL but do not want to open up > postgresql to the internet. > > So, I'd like to tunnel the libpq connection over the existing secure > socket. My preferred solution would be for the client to pass libpq > an already connected file descriptor (so I can prevent binding a port > to localhost). > > Is such a thing possible without hacking libpq? Are there other > options I should be looking at that don't involve PostgreSQL listening > on the evil internet? > > Thanks. I'm not sure if you could "tunnel" that connection in the way you're saying because that connection terminates at (I'm assumming) your application server and not the db server. At a minimum, I would think you would have to write logic on the application sure to proxy the management traffic over to the db. Seems messy but I think there are other options for you: 1) If you have compiled with SSL then you can enforce SSL connections for non local network connections. You'd have to open up the database tcp/ip port on your firewall which it sounds like you don't want to do. Keep in mind that the PG port is arbitrary so you could run it on something none standard. 2) If you have a decide NAT/firewall system (e.g. Iptables on Linux) you could do port forwarding. So even the db has a public nic, you could then set up and IP/port only used for db management which then would be translated to real db IP/port. Again, you would (should) only run this with clients like pgadmin. That is pretty specific to PG but if your clients are Linux, then you can use SSH port forward to tunnel anything you want. This is more complicated but in the end is more flexible since there are no server side changes necessary and non-ssl clients can be used. > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > -- Keith C. Perry, MS E.E. Director of Networks & Applications VCSN, Inc. http://vcsn.com ____________________________________ This email account is being host by: VCSN, Inc : http://vcsn.com
В списке pgsql-general по дате отправления: