search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.81k stars 494 forks source link

dietpi.com not reachable from certain locations #3260

Closed YukiRainee closed 4 years ago

YukiRainee commented 4 years ago

Hey just wanted to ask if you guys knew the website was down, trying to download the dietpi image right now.. but for some reason I can't access the site at all just wanted to see if its just me..

MichaIng commented 4 years ago

@Rainee4563 Many thanks for your report.

Jep, see: https://github.com/MichaIng/DietPi/issues/3257#issuecomment-563472501

I'm not sure about the issue, since the server runs perfectly fine and it only affects certain accesses:

Joulinar commented 4 years ago

I found it @MichaIng .

It's related to IPv4. Usually my entire Network is running IPv4 only and there it is not working. Now I put my RPi directly behind my broadband router and activated IPv6. Surprise, its working again and I can run dietpi-survey 1. Disabling IPv6 will reintroduce the issue and dietpi-survey 1 is failing again.

MichaIng commented 4 years ago

@Joulinar Very strange, I definitely access via IPv4, especially from mobile phone since my provider mobile network is IPv4 only. It is certain IPv4 ranges obviously, that fits to some firewall, but it's not on our control.

Joulinar commented 4 years ago

@MichaIng Not sure if I understood you sever setup correctly. But I assume you are using Cloudflare somehow in front of your WebServer. Because that would explain why I'm receiving the Cloudflare Always Online™ Site, reporting dietpi.com is offline (even I'm not using Cloudflare at all right now).

Checking nslookup dietpi.com is giving me 104.27.179.199 and 104.27.178.199 as IPv4 address.

Sorry for all the questions, but I'm trying to understand how this is going :)

MichaIng commented 4 years ago

Testing:

[php7:error] [pid 8441] [client VV.XX.YY.ZZ:29424] script '/var/www/phpbb/test.php' not found or unable to stat

IPv4 client, matching my local network IP, not Cloudflare IP, hence the IP translation to prevent Cloudflare IPs being blocked works as expected.

Double checked that no Cloudflare IP is blocked, although access fails from certain remote IP with all IPs unblocked as well...

Raised backlog limit, lets see if this is related.

Joulinar commented 4 years ago

for me nothing changed, still getting the error as soon as I have IPv6 disabled. Not sure if you have it already but this is Cloudflare Troubleshooting site for the reported error.

https://support.cloudflare.com/hc/en-us/articles/115003011431#522error

MichaIng commented 4 years ago

@Joulinar

104.27.179.199

That is the Cloudflare IP the is forwarded to our server. dietpi.com resolves here the same and connects successfully.

Since Cloudflare does not relay anything but HTTP(S) port 80+443 connections, we use ssh.dietpi.com for SSH/SFTP (dietpi-survey), which resolves to the server directly. Note that if your access it via HTTP on port 80, the internal HTTPS redirection redirects to dietpi.com, hence through Cloudflare again. So to check if there is really an issue outside of Cloudflare, https://ssh.dietpi.com must be used, which at least produces a warning due to non-matching SSL certificate host.

I recognised some other issus:

I'll do a server restart tonight as last resort, else open a ticket to have MVS checking what happens to those connections probably before they even reach our VPS.

Arghh commented 4 years ago

I thought maybe this infos will help you investigate: I get a 522 error from cloudfaire from dietpi.com with pihole turned on. If i disable pihole I have no errors. I can't make out the domain what is causing the problem because I have a pretty aggressive blocklist but it could be olmprodpowerlift-cdn.azureedge.net Do you guys use azure?

MichaIng commented 4 years ago

@Arghh Many thanks for your info. Actually very strange, since Pi-hole blocks DNS resolving in the first place. dietpi.com is resolved to Cloudflares IP, but if it is blocked by Pi-hole, you would see raw 403 or Pi-hole blocking page, but not Cloudflare. If you see Cloudflare, it means the hostname was resolved by Pi-hole already.

notDavid commented 4 years ago

@MichaIng dietpi.com is not working for me either, i first noticed because i got a connection error while installing software via dietpi-software.

Anyways, i turned on a Vpn, and selected a vpn server in another country: Switzerland, and suddenly i can access dietpi.com again... so yea it seems like some routing/dns issue.

MichaIng commented 4 years ago

Okay server restart approaching, will add PHP update, hence will take few minutes.

Done, no change. I also recognised, while doing dietpi-update additionally, that github.com is as well not accessible from the server. As if MVS has an aggressive DNS-based adblock active 😄. I'll open a ticket as things are now very clear.

philfleck commented 4 years ago

just my observation - reachable via vpn over france, but not from austria (showing cloudflare error over budapest)

DutchFlash commented 4 years ago

26 hours later, Still the error page 522(cloudflare)

MichaIng commented 4 years ago

Ticket is opened, lets see what MVS comes up with.

Joulinar commented 4 years ago

@MichaIng It seems I'm able to access the website dietpi.com again. However I still have issues connection to ssh.dietpi.com. it was working for a moment but now failing again.

Arghh commented 4 years ago

@MichaIng It seems I'm able to access the website dietpi.com again. However I still have issues connection to ssh.dietpi.com. it was working for a moment but now failing again.

Can confirm. Dietpi.com is accessible from Germany.

MichaIng commented 4 years ago

@Rainee4563 @Joulinar @Fourdee @Arghh @philfleck Could you guys verify its working now again from all locations? After tinkering a bid and refreshing the SSL certificate to include the testing domain (that bypasses Cloudflare) suddenly the previously failing access worked again, the VPS can access deb.debian.org and github.com domains again, ping/ICMP to VPS works etc. Since everything but the first is not related to the webserver or HTTPS certificate, it must have been coincidence 😄.

I made our SSL protocol + cipher requirements harder to fit new common intermediate standards, hence TLS1.0+1.1 are not supported anymore. Let me know if this breaks any of your clients. However all browsers since 2-3 years ago should support this without issues.

Joulinar commented 4 years ago

@MichaIng I can confirm website dietpi.com as well as ssh.dietpi.com are working fine from Germany

root@DietPi:~# dietpi-survey 1
[  OK  ] DietPi-Survey | Connection test: ssh.dietpi.com
[  OK  ] DietPi-Survey | Successfully sent survey data
root@DietPi:~#
YukiRainee commented 4 years ago

Yep I can access it from Cali as well!

philfleck commented 4 years ago

works again from austria

Fourdee commented 4 years ago

@MichaIng

All working here, with VPN and without, great work Micha :+1:

Pisgah commented 4 years ago

It works here from Taiwan, many thanks

MichaIng commented 4 years ago

@Fourdee Had nothing to do with my work, AFAIK, but great it's solved. Was bad timing during beta phase.

Okay I mark this issue as closed then.

johnnyasantoss commented 3 months ago

I'm having this issue now. Not sure if something was updated but https://dnschecker.org/#A/dietpi.com returns the same ip for all regions (I'm in Brazil);

curl -vvv -4 dietpi.com times out after 75s. Is the region or my ip blocked?

Joulinar commented 3 months ago

We don't do any regional or IP blocking on our web site. Probably this is some lovely with your ISP. At least from central Europe web site is working without issues.

MichaIng commented 3 months ago

@johnnyasantoss Note that this issue was about ssh.dietpi.com, which points to our server directly, while you have issues to connect to dietpi.com, which connects through Cloudflare.

At which stage does it hang, DNS or actual connection? Does this work and print the IP addresses you see on DNS checker?

getent hosts dietpi.com

There are currently two rare issues about connections to dietpi.com:

While I am currently affected by the first, next week I'll probably instead be affected by the 2nd, since I am switching to DTAG ISP 😄.

Since Cloudflare has a firewall as well, I just checked the logs, and found just one blocked access from Brazil, done however with a Go HTTP library in an unusual request.

johnnyasantoss commented 3 months ago

@MichaIng Running getent hosts dietpi.com returned

2606:4700:20::681a:4f3 dietpi.com
2606:4700:20::681a:5f3 dietpi.com
2606:4700:20::ac43:4565 dietpi.com

I was trying to upgrade my dietpi and I don't think it uses Go, right? Managed to update it using a vpn

The issue was that it is taking too long to reply, leading to timeout.

time curl -vvv -4 dietpi.com
*   Trying 104.26.5.243:80...
* connect to 104.26.5.243 port 80 failed: Connection timed out
* Failed to connect to dietpi.com port 80: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to dietpi.com port 80: Connection timed out

real    2m12.044s
user    0m0.029s
sys     0m0.101s

Using ipv6 it returns network unreachable

dietpi@raspbolt:~$ curl -vvv -6 dietpi.com
*   Trying 2606:4700:20::681a:5f3:80...
* Immediate connect fail for 2606:4700:20::681a:5f3: Network is unreachable
*   Trying 2606:4700:20::ac43:4565:80...
* Immediate connect fail for 2606:4700:20::ac43:4565: Network is unreachable
*   Trying 2606:4700:20::681a:4f3:80...
* Immediate connect fail for 2606:4700:20::681a:4f3: Network is unreachable
* Closing connection 0
curl: (7) Couldn't connect to server
Joulinar commented 3 months ago

Using ipv6 it returns network unreachable

I guess your SBC don't have IPv6 configured

MichaIng commented 3 months ago

I was trying to upgrade my dietpi and I don't think it uses Go, right?

No, this really is a dedicated little program, written in Go, which seems to be often used for harmful website crawls, so that its user agent is on the Cloudflare WAF block list.

I guess your SBC don't have IPv6 configured

But IPv4 requests time out as well.

Does it work with wget?

wget --spider https://dietpi.com/

And can you visit our website from browser?

Joulinar commented 3 months ago

But IPv4 requests time out as well.

Yes, correct, IPv4 has a time out but on IPv6 network is unreachable, indicating an incorrect IPv6 connection. 😉 But this should be unrelated as our web site is/should be reachable on IPv4, regardless of whether IPv6 has been configured.

MichaIng commented 3 months ago

I guess both issues are related, and just have different results based on IP protocol version. At least an IPv6 route seems to exist, otherwise the error should be "no route to host". But of course can be easily tested:

curl -I6 google.com
johnnyasantoss commented 3 months ago

Yeah ipv6 is still poorly configured on this machine. I've disabled it now (was only on to test).

Running wget --spider

wget --spider --timeout 3 dietpi.com
Spider mode enabled. Check if remote file exists.
--2024-06-10 11:33:19--  http://dietpi.com/
Resolving dietpi.com (dietpi.com)... 104.26.4.243, 104.26.5.243, 172.67.69.101, ...
Connecting to dietpi.com (dietpi.com)|104.26.4.243|:80... failed: Connection timed out.
Connecting to dietpi.com (dietpi.com)|104.26.5.243|:80... failed: Connection timed out.
Connecting to dietpi.com (dietpi.com)|172.67.69.101|:80... failed: Connection timed out.
Connecting to dietpi.com (dietpi.com)|2606:4700:20::681a:4f3|:80... failed: Cannot assign requested address.
Connecting to dietpi.com (dietpi.com)|2606:4700:20::681a:5f3|:80... failed: Cannot assign requested address.
Connecting to dietpi.com (dietpi.com)|2606:4700:20::ac43:4565|:80... failed: Cannot assign requested address.
Retrying.
...
[same]

I thought it was something related to Tailscale (which I have configured on this sbc) but turning it off didn't show any difference.

And can you visit our website from browser?

On another computer on the same net, yes. On the SBC, no.

MichaIng commented 3 months ago

But connecting to our server directly works, right?

curl -I ssh.dietpi.com

And what about other sites behind Cloudflare?

curl -I symfony.com
johnnyasantoss commented 3 months ago

Both worked for me. I've received a 301 response on both. Not sure exactly what's the issue here, but it seems to only happen with the SBC with dietpi installed (all the other devices on the same network can access the site).

johnnyasantoss commented 3 months ago

Also, yesterday I tested with Tailscale off and it didn't change a thing

MichaIng commented 3 months ago

Can you check the route:

apt install mtr-tiny
mtr dietpi.com
mtr -4 dietpi.com

And compare this with what you get on other systems, e.g. on Windows with

tracert dietpi.com
tracert -4 dietpi.com