Re: Resolving host to IP address

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Resolving host to IP address
Дата
Msg-id 1611957.1662991871@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Resolving host to IP address  (Sebastien Flaesch <sebastien.flaesch@4js.com>)
Ответы Re: Resolving host to IP address  (Francisco Olarte <folarte@peoplecall.com>)
Список pgsql-general
Sebastien Flaesch <sebastien.flaesch@4js.com> writes:
> $ psql
'postgresql://toro.strasbourg.4js.com:5437/test1?user=pgsuser&sslmode=verify-ca&sslrootcert=./root.crt&sslcert=./client.crt&sslkey=./client.key'
> psql: error: connection to server at "toro.strasbourg.4js.com" (127.0.1.1), port 5437 failed: FATAL:  no pg_hba.conf
entryfor host "127.0.0.1", user "pgsuser", database "test1", SSL encryption 

> What looks strange to me in this error is that first it mentions 127.0.1.1 (ok) but then, 127.0.0.1

Linux doesn't seem to show its routing of the loopback domain in netstat
output, but it's probably much like what macOS shows explicitly:

$ netstat -r -n
Destination        Gateway            Flags           Netif Expire
...
127                127.0.0.1          UCS               lo0
127.0.0.1          127.0.0.1          UH                lo0
...

That is, the entire 127/8 range is "routed" through 127.0.0.1 and
will look like that to the server.  I see similar entries on NetBSD.

Confirming that guess, I see this behavior on RHEL8,
with no particular OpenSSL involvement:

$ psql -h 127.0.1.1
psql (16devel)
Type "help" for help.

postgres=# select client_addr from pg_stat_activity;
 client_addr
-------------
 ...
 127.0.0.1
 ...

Moral: don't try to use addresses in that range as real addresses.

            regards, tom lane



В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: lippq client library and openssl initialization: PQinitOpenSSL()
Следующее
От: Francisco Olarte
Дата:
Сообщение: Re: Resolving host to IP address