Open uniartisan opened 2 years ago
uniartisan
commented
2 years ago modify notify_push/lib/SelfTest.php /
public function test(string $server, OutputInterface $output, bool $ignoreProxyError = false)to
public function test(string $server, OutputInterface $output, bool $ignoreProxyError = true)notify_push:setupand finally solve this problem.
can ignoreProxyError to be a command?, like occ notify_push:ignoreProxyError
icewind1991
commented
2 years ago modify notify_push/lib/SelfTest.php /
That is just hiding the error, the check is there for a reason
The following x-forwarded-for header was received by Nextcloud: 220.194.88.217
Looks like there is another reverse proxy in the chain between the push server and the nextcloud server that isn't forwarding/trusting the x-forwarded-for header.
uniartisan
commented
2 years ago modify notify_push/lib/SelfTest.php /
That is just hiding the error, the check is there for a reason
The following x-forwarded-for header was received by Nextcloud: 220.194.88.217
Looks like there is another reverse proxy in the chain between the push server and the nextcloud server that isn't forwarding/trusting the
x-forwarded-forheader.
I have tried to fix this problem (with nginx proxy manager docker and CDN), but it still shows:
113.132.176.100 is my real ip now I don't have a fix ip, so a dynamic ip is provided by china telecom. It now finally shows the real IP, but it still has problem. :(
✓ redis is configured
✓ push server is receiving redis messages
✓ push server can load mount info from database
✓ push server can connect to the Nextcloud server
🗴 push server is not a trusted proxy, please add '220.194.88.252' to the list of trusted proxies or configure any existing reverse proxy to forward the 'x-forwarded-for' send by the push server.
See https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#defining-trusted-proxies for how to set trusted proxies.
The following trusted proxies are currently configured: "119.188.19.0/24", "120.221.167.0/24", "120.221.168.0/24", "121.51.191.0/24", "121.51.90.0/24", "121.51.93.0/24", "122.97.142.0/24", "122.97.143.0/24", "123.151.144.0/24", "140.249.67.0/24", "182.254.58.0/24", "220.194.88.0/24", "223.166.151.0/24", "27.155.114.0/24", "27.155.115.0/24", "36.152.58.0/24", "36.248.2.0/24", "58.217.244.0/24", "58.217.245.0/24", "58.251.121.0/24", "59.36.117.0/24", "59.36.119.0/24", "59.36.120.0/24", "59.36.95.0/24", "61.151.164.0/24", "101.89.27.0/24", "101.89.32.0/24", "101.89.34.0/24", "101.91.24.0/24", "112.53.38.0/24", "116.128.128.0/24", "192.0.0.0/8", "172.17.0.0/24", "113.0.0.0/8"
The following x-forwarded-for header was received by Nextcloud: 113.132.176.100, 220.194.88.252
from the following remote: 220.194.88.252
If you're having issues getting the trusted proxy setup working, you can try bypassing any existing reverse proxy
in your setup by setting the `NEXTCLOUD_URL` environment variable to point directly to the internal Nextcloud webserver url
(You will still need the ip address of the push server added as trusted proxy)
accountForIssues
commented
2 years ago If you have a reverse proxy, you shouldn't need to add your real IP(s), right ?
You only need to add the IPs of the local containers that'll be connecting to the Nextcloud instance.
I use docker for everything and Caddy as my reverse proxy. My config.php looks like this,
'trusted_domains' =>
array (
1 => 'cloud.domain.tld', # public hostname of my nextcloud
2 => 'nextcloud-web', # nextcloud server container hostname
),
'trusted_proxies' =>
array (
0 => '172.20.0.230', # nextcloud server container, nginx
1 => '172.20.0.240', # notify-push container
2 => '172.20.0.100', # caddy container
),
The environment variables to the notify-push container
environment:
- DATABASE_URL=mariadb://$MYSQL_USER:$MYSQL_PASSWORD@$MYSQL_HOST/$MYSQL_DATABASE
- DATABASE_PREFIX=oc_
- REDIS_URL=redis://:$REDIS_HOST_PASSWORD@$REDIS_HOST
- NEXTCLOUD_URL=http://$NEXTCLOUD_HOST # nextcloud-web
- METRICS_PORT=8899I verified that it's working by connecting to the metrics endpoint.
Zempashi
commented
2 years ago Not a specialist of PHP, but looks like the test function always return error (https://github.com/nextcloud/notify_push/blob/2522b4ebbab07dbb1486a3295eac5cf0941535a9/lib/SelfTest.php#L177), and for quite some time not really testing that remote ip belong to trusted_proxy (seems that a function existed but was removed to test if trusted proxy looks like IP ou CIDR): https://github.com/nextcloud/notify_push/commit/bcea72d3e4403142c487cdbaad5308b2c8c82624
icewind1991
commented
2 years ago The test to check if the push server is a trusted proxy does not rely on checking the list of trusted_proxes, the check is done by having the push server send a request to nc with a "forwarded for" header set and seeing if nc accepts the "forwarded for".
All the logic in SelfTest.php regarding trusted_proxies only exists as an attempt to provide better diagnostics for when the check has failed.
I use docker for everything and Caddy as my reverse proxy. My config.php looks like this,
If nextcloud-web connects to Caddy and not the nextcloud container directly then you might need to configure Caddy's trusted proxy settings (if it has any, never used Caddy). Alternatively set the NEXTCLOUD_URL to the nextcloud container directly, bypassing Caddy
waja
commented
2 years ago Could it be, that it is not possible to specify a port via NEXTCLOUD_URL? I remember to get stuck, when using https://github.com/Wonderfall/docker-nextcloud cause the webserver is running on port 8888.
Retidurc
commented
1 year ago I have a somewhat similar problem, but with ipv6, and I have not a clue on how to solve it
✓ redis is configured
✓ push server is receiving redis messages
✓ push server can load mount info from database
✓ push server can connect to the Nextcloud server
🗴 push server is not a trusted proxy, please add '2a01:e0a:a60:2430::18f' to the list of trusted proxies or configure any existing reverse proxy to forward the 'x-forwarded-for' send by the push server.
See https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#defining-trusted-proxies for how to set trusted proxies.
The following trusted proxies are currently configured: "2a01:e0a:a60:2430::18f"
The following x-forwarded-for header was received by Nextcloud: 1.2.3.4
from the following remote: 2a01:e0a:a60:2430::18f
Aterfax
commented
1 year ago I am fairly sure that some of the issues are being caused for at least some people by them adding real_ip_header CF-Connecting-IP; or real_ip_header X-Forwarded-For; to their configs for Cloudflare proxying in Nginx / Nginx Proxy Manager, without adding the corresponding IP for the notify_push host server to the list of set_real_ip_from IPs.
i.e. In addition to the large list of cloudflare IP addresses here: https://danielmiessler.com/blog/getting-real-ip-addresses-using-cloudflare-nginx-and-varnish/
You must also add an entry for your notify_push service host machine, example:
set_real_ip_from 192.168.1.10/32;
Where 192.168.1.10 is the machine/IP you are hosting the notify_push service from. This may or may not be the same machine as your machine hosting Nextcloud (I expect in most cases it will be, but enterprise or large scale Nextcloud deployments may use separate machines.)
This works for me with my notify_push service host IP added an addition set_real_ip_from entry in concert with real_ip_header X-Forwarded-For;
This should be fine according to Cloudflare: https://developers.cloudflare.com/fundamentals/get-started/reference/http-request-headers/#x-forwarded-for
People could (if they desired to for some reason) attempt to use CF-Connecting-IP but without telling Nextcloud to use this alternative header in the Nextcloud config.php, things will also be broken.
Edit: It might be sensible that a traffic flow diagram is added to bring some clarity to exactly what "endpoints" Nextcloud clients / notify_push needs to talk to, and how Nextcloud clients / notify_push need to talk to each "endpoint" with and without the context of a reverse proxy plus any gotchas with things like Cloudflare.
Forza-tng
commented
1 year ago I have the sane issue
I'm using a plain server with Caddy and php-fpm
✓ redis is configured
✓ push server is receiving redis messages
✓ push server can load mount info from database
✓ push server can connect to the Nextcloud server
🗴 push server is not a trusted proxy, please add '192.168.0.1' to the list of trusted proxies or configure any existing reverse proxy to forward the 'x-forwarded-for' send by the push server.
See https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#defining-trusted-proxies for how to set trusted proxies.
The following trusted proxies are currently configured: "192.168.0.1", "127.0.0.1"
The following x-forwarded-for header was received by Nextcloud: 192.168.0.1
from the following remote: 192.168.0.1
If you're having issues getting the trusted proxy setup working, you can try bypassing any existing reverse proxy
in your setup by setting the `NEXTCLOUD_URL` environment variable to point directly to the internal Nextcloud webserver url
(You will still need the ip address of the push server added as trusted proxy)How is this test done? Is it through an external Web service or just locally? I can say for sure that I don't have multiple reverse proxies and that the Caddy instance has a reachable public IP.
How can I verify that that push notifications work? Do they work with the Android app?
I had to amend the Caddy config with trusted_proxies as such:
php_fastcgi unix//run/php-fpm/php-nextcloud.socket {
trusted_proxies private_ranges
}Thanks to @inos-github who mentioned it in https://github.com/nextcloud/notify_push/issues/177
alexanderharm
commented
10 months ago Just to add the config change needed for Traefik as reverse proxy. Add your push servers IP to the trusted IPs of the forwardedHeaders section in the entrypoint configuration (if 1.2.3.4 is your push server IP):
entryPoints:
web:
address: ":80"
acme:
address: ":81"
websecure:
address: ":443"
forwardedHeaders:
trustedIPs:
- "1.2.3.4/32"
mdeweerd
commented
8 months ago I found that I had to add the IP of the nextcloud server itself. My nextcloud server is behind a haproxy running on opnsense.
Inside the self-test messages I had: The following x-forwarded-for header was received by Nextcloud: 1.2.3.4, 192.168.0.112
And 192.168.0.112 which is my nextcloud IP was not in the trusted proxies list. Ones I added this IP to the list, the setup was considered ok.
The reason likely is that my nextcloud instance accesses itself by exiting on 192.168.0.112 to the ha-proxy server and the tests adds 1.2.3.4 as the source IP. So the nextcloud instance acts as a proxy in the test.
v1r0x
commented
8 months ago I just upgraded from NC 27 to NC 28 and now I get an error that
🗴 push server is not a trusted proxy, please add '<SOME_IP>' to the list of trusted proxies or configure any existing reverse proxy to forward the 'x-forwarded-for' send by the push server.
The following trusted proxies are currently configured: "<ANOTHER_IP>", "<SOME_IP>"This setup worked fine in NC 27, but doesn't work anymore...weird thing is, that the error says I should add <SOME_IP> as trusted proxy, which it already is...
XueSheng-GIT
commented
8 months ago After upgrading from NC 27.1.3 to 27.1.5 I also get this "push server is not a trusted proxy..." error. I'm on notify_push 0.6.6.
First I thought it could be related to the latest notify_push version, but self-test does not fail when using 0.6.6 with NC 27.1.3. Thus, it seems that something changed within nextcloud server!?
My proxy setup was not modified lately and the failing self-test makes no sense, because the list of trusted proxies is fine and the 'x-forwarded-for' header seems to be working as expected.
XueSheng-GIT
commented
8 months ago Still didn't find out where the issue is coming from. I tested the following:
curl -H 'x-forwarded-for: 1.2.3.4' https://<nextcloud>/index.php/apps/notify_push/test/remoteOutput for NC 27.1.3:
1.2.3.4Output for NC 27.1.5:
<IP of PC I'm running curl>This is just before/after the upgrade of the same nextcloud instance. No changes done to nextcloud or proxy config. Thus, there must be a difference how nextcloud now handles the trusted proxy check.
@icewind1991: Any further idea where to look at to solve this issue?
XueSheng-GIT
commented
7 months ago After digging a bit deeper, I found out that the following commit (by @nickvergessen) is the reason for the changed behaviour starting with NC 27.1.4. https://github.com/nextcloud/server/commit/335369f3f47c0c2186e3d258b26954c4339fa9e1
For example: $forwardedForHeaders is "1.2.3.4 192.168.10.10"
Self-test of notify_push checks for $remote to be "1.2.3.4", but with the above mentioned commit the last IP of $forwardedForHeaders is returned, thus check fails. NC 27.1.3 and earlier returned the first item of $forwardedForHeaders but starting with NC 27.1.4 and above, the last item is returned (not completely true, because ips of trusted proxies are skipped...).
Thus, I would argue that self-test of notfiy_push must be adapted to consider the changes done in the above mentioned commit.
At least the comments since https://github.com/nextcloud/notify_push/issues/155#issuecomment-1836295479 seem to be related to this issue.
@icewind1991 and @nickvergessen can you have a second look at this issue? Thanks a lot!
nickvergessen
commented
7 months ago To comment on the initial report, a "trusted proxies" list like:
'trusted_proxies' =>
array (
0 => '119.188.19.0/24',
1 => '120.221.167.0/24',
2 => '120.221.168.0/24',
3 => '121.51.191.0/24',
4 => '121.51.90.0/24',
5 => '121.51.93.0/24',
6 => '122.97.142.0/24',
7 => '122.97.143.0/24',
8 => '123.151.144.0/24',
9 => '140.249.67.0/24',
10 => '182.254.58.0/24',
11 => '220.194.88.0/24',
12 => '223.166.151.0/24',
13 => '27.155.114.0/24',
14 => '27.155.115.0/24',
15 => '36.152.58.0/24',
16 => '36.248.2.0/24',
17 => '58.217.244.0/24',
18 => '58.217.245.0/24',
19 => '58.251.121.0/24',
20 => '59.36.117.0/24',
21 => '59.36.119.0/24',
22 => '59.36.120.0/24',
23 => '59.36.95.0/24',
24 => '61.151.164.0/24',
),Definetly does not sound correct. I doubt that you set up 24 reverse proxies that communicate/connect/tunnel connections to your Nextcloud.
nickvergessen
commented
7 months ago @XueSheng-GIT
Can you add:
\OC::$server->getLogger()->error('x-forwarded-for' . $this->request->getHeader('x-forwarded-for'));
\OC::$server->getLogger()->error('REMOTE_ADDR' . $this->request->server['REMOTE_ADDR']);
\OC::$server->getLogger()->error('getRemoteAddress' . $this->request->getRemoteAddress());Then run the self-test command and post the error log entries it created in your nextcloud.log file?
XueSheng-GIT
commented
7 months ago @nickvergessen: log as requested.
{"reqId":"6WDT3yG7YIV6ytXNOMXA","level":3,"time":"2024-01-09T18:31:32+01:00","remoteAddr":"192.168.5.110","user":"--","app":"no app in context","method":"GET","url":"/index.php/apps/notify_push/test/remote","message":"x-forwarded-for1.2.3.4, 192.168.5.110","userAgent":"--","version":"27.1.5.1","data":[]}
{"reqId":"6WDT3yG7YIV6ytXNOMXA","level":3,"time":"2024-01-09T18:31:32+01:00","remoteAddr":"192.168.5.110","user":"--","app":"no app in context","method":"GET","url":"/index.php/apps/notify_push/test/remote","message":"REMOTE_ADDR192.168.5.125","userAgent":"--","version":"27.1.5.1","data":[]}
{"reqId":"6WDT3yG7YIV6ytXNOMXA","level":3,"time":"2024-01-09T18:31:32+01:00","remoteAddr":"192.168.5.110","user":"--","app":"no app in context","method":"GET","url":"/index.php/apps/notify_push/test/remote","message":"getRemoteAddress192.168.5.110","userAgent":"--","version":"27.1.5.1","data":[]}config.php (extract):
'trusted_proxies' =>
array (
0 => '192.168.5.125',
1 => '127.0.0.1',
2 => '::1',
),192.168.5.125 is the reverse proxy. 192.168.5.110 is nextcloud itself (command was directly invoked on the console of the server).
icewind1991
commented
7 months ago https://github.com/nextcloud/notify_push/pull/377 improves the diagnostics for this error a bit, please try applying it and see if the updated message makes more sense
XueSheng-GIT
commented
7 months ago 377 improves the diagnostics for this error a bit, please try applying it and see if the updated message makes more sense
I wasn't able to find some quick instruction how to build this app from source, thus I skipped the diff for composer.json. I applied the diff to SelfTest.php and it doesn't seem to complain about missing dependencies.
Output of occ notify_push:self-test:
✓ redis is configured
✓ push server is receiving redis messages
✓ push server can load mount info from database
✓ push server can connect to the Nextcloud server
🗴 push server is not a trusted proxy by Nextcloud or another proxy in the chain.
Nextcloud resolved the following client address for the test request: "192.168.5.110" instead of the expected "1.2.3.4"
The following trusted proxies are currently configured: "192.168.5.125", "127.0.0.1", "::1"
The following x-forwarded-for header was received by Nextcloud: "1.2.3.4, 192.168.5.110"
from the following remote: 192.168.5.125
192.168.5.110 is not a trusted as a reverse proxy by Nextcloud
See https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#defining-trusted-proxies for how to add trusted proxies.
If you're having issues getting the trusted proxy setup working, you can try bypassing any existing reverse proxy
in your setup by setting the `NEXTCLOUD_URL` environment variable to point directly to the internal Nextcloud webserver url
(You will still need the ip address of the push server added as trusted proxy)@icewind1991 Did you expect this output?
icewind1991
commented
7 months ago Yes that output looks as expected, looks like "192.168.5.110" needs to be added as trusted proxy"
major-mayer
commented
5 months ago I could also need some help with this topic. My case might be a bit different, because i am using Unix sockets in my reverse proxy (Caddy) and not IP addresses, but the error is very similiar:
Nextcloud resolved the following client address for the test request: "{public ip}" instead of the expected "1.2.3.4"
The following trusted proxies are currently configured: "172.16.0.0/12", "127.0.0.1"
The following x-forwarded-for header was received by Nextcloud: "{public ip}, 127.0.0.1"
from the following remote: {public ip}I configured Caddy like this:
handle_path /push/* {
reverse_proxy unix//run/notify_push/notify_push.sock
}
php_fastcgi unix//run/nextcloud/nextcloud.sock {
trusted_proxies private_ranges
header_up X-Forwarded-For "{remote}, 127.0.0.1"
}As you can see, I added 127.0.0.1 as my fake trusted proxy, because I don't really have a proxy with a dedicated IP address that I could use instead (because of the Unix sockets used). And apparently (based on the self-test message) the "127.0.0.1" proxy gets added successfully to the X-Forwarded-For header.
My trusted proxies in the config.php look like this:
array (
0 => '172.16.0.0/12',
1 => '127.0.0.1'
),Can anybody explain to me what is going wrong here? I thought the localhost-proxy might be a nice workaround for people using Unix sockets
What confuses me even more is that the browser client apparently successfully establishes a Websockets connection, and i get a notify_file message when i change something using the desktop client. The metrics also look fine:
./occ notify_push:metrics
Active connection count: 4
Active user count: 3
Total connection count: 8
Total database query count: 2
Events received: 5
Messages sent: 0Is this just a false-alarm?
icewind1991
commented
5 months ago header_up X-Forwarded-For "{remote}, 127.0.0.1"is adding those IPs as being the forwarded ips, not setting them as trusted proxies
major-mayer
commented
4 months ago header_up X-Forwarded-For "{remote}, 127.0.0.1"is adding those IPs as being the forwarded ips, not setting them as trusted proxies
Okay, but I set 127.0.0.1 in the trusted proxies section of my config.php file, isn't that enough? What would be the correct way to add them?
I have followed guide[https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/reverse_proxy_configuration.html#defining-trusted-proxies] to set config.php, and here it is( in CIDR way):
My Nextcloud is 23.0.0(php8,redis) notify_push version is 0.3.0. However push_notify notice me that the proxy ip is not in those keys, what should I do ? Is there something wrong I didn't realize? Looking forward to your reply.