META: I don't know why this post gets malformatted every time, the forum inserts a "code"-tagat the very beginning, every time I edit the post and remove it it get's re-inserted.
---
Ahoj,
I cannot access the Artix packages' sources/ [tt]PKGBUILD[/tt]s:
https://gitea.artixlinux.org/ does not connect[1],
on https://packages.artixlinux.org/details/mkinitcpio, clicking on "[url=View Package Sources]View Package Sources[/url]" just shows the same page again.
[1] [tt]wget -O /dev/null https://gitea.artixlinux.org/[/tt]:
[ code]
--2022-12-04 22:07:21-- https://gitea.artixlinux.org/
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving gitea.artixlinux.org (gitea.artixlinux.org)... 84.46.83.154
Connecting to gitea.artixlinux.org (gitea.artixlinux.org)|84.46.83.154|:443... connected.
GnuTLS: The TLS connection was non-properly terminated.
Unable to establish SSL connection.
In the Web Browser (Firefox):
I would use another browser.
Chromium works, curl works after multiple low timeout retries and wget works over Tor ( although consider the fact the internet isn't the best here hence why curl and wget were done like that )
Have you upgraded your system fully or done a partial upgrade?
Sorry, guys, if I use an up to date Firefox (version 108.0b9), then it is not the browser to blame.
Sorry, guys, when it works only after multiple timeouts and only from specific IP adresses or so, than I consider it as "not working", since it is meant to be generally accessible.
I am going to Internet via nordvpn in Zürich.
Full upgrade.
would you enlighten me
what happens when you go to this url trough you browser
https://gitea.artixlinux.org/packagesM/mkinitcpio/src/branch/master/trunk/PKGBUILD (https://gitea.artixlinux.org/packagesM/mkinitcpio/src/branch/master/trunk/PKGBUILD)
and what will be the output of this
curl -LO https://gitea.artixlinux.org/packagesM/mkinitcpio/raw/branch/master/trunk/PKGBUILD
or the
wget equivalent
if this doesn't work
# first try reinstalling "certificate" packages (it may not fix anything).
pacman -S ca-certificates ca-certificates-mozilla ca-certificates-utils
# if it doesn't work debug your network properly.
* ping the website
* resolve the domain
* trace the package route
more about it here (https://wiki.archlinux.org/title/Network_Debugging)
Attached screenshot from Firefox Developer Edition, version 108.0b9:
(https://i.imgur.com/rrisV3N.png)
Same in a private window.
Attached screenshot from Ungoogled Chromium, version 107.0.5304.121:
(https://i.imgur.com/iSR0VxU.png)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:12 --:--:-- 0
curl: (35) error:0A000126:SSL routines::unexpected eof while reading
My IP adress according to https://iplocation.io/:
IPv4: 45.8.148.205
IPv6: Not Detected
I tested via another internet connection, IP adress according to https://iplocation.io/:
IPv4: 46.114.201.249
IPv6: Not Detected
.. there it works, as well as from IPv4: 95.90.150.190.
So the problem is somewhere on the route, but strange since other sites work. Can it be that my IP adress is somehow in some filtering list associated with gitea.artixlinux.org and packages.artixlinux.org?
Skipped, since via another internet access it works.
ping -c2 gitea.artixlinux.org:
PING taurus.artixlinux.org (84.46.83.154) 56(84) bytes of data.
64 bytes from 84.46.83.154 (84.46.83.154): icmp_seq=1 ttl=53 time=59.6 ms
64 bytes from 84.46.83.154 (84.46.83.154): icmp_seq=2 ttl=53 time=61.4 ms
--- taurus.artixlinux.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 59.584/60.511/61.438/0.927 ms
dig gitea.artixlinux.org:
; <<>> DiG 9.18.9 <<>> gitea.artixlinux.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38496
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;gitea.artixlinux.org. IN A
;; ANSWER SECTION:
gitea.artixlinux.org. 237 IN CNAME taurus.artixlinux.org.
taurus.artixlinux.org. 237 IN A 84.46.83.154
;; Query time: 0 msec
;; SERVER: 192.168.100.253#53(192.168.100.253) (UDP)
;; WHEN: Tue Dec 06 12:27:05 CET 2022
;; MSG SIZE rcvd: 100
tracepath -n gitea.artixlinux.org:
1?: [LOCALHOST] pmtu 1500
1: 192.168.100.253 8.235ms
1: 192.168.100.253 3.931ms
2: 10.8.2.1 45.924ms
3: no reply
4: no reply
5: 193.27.15.34 57.695ms
6: 37.120.220.110 62.813ms asymm 14
7: no reply
8: no reply
9: 82.102.29.233 61.189ms
10: 176.10.83.119 59.981ms asymm 11
11: 80.249.211.221 59.661ms asymm 9
12: 84.46.113.252 70.953ms
13: 84.46.113.33 70.027ms asymm 11
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
25: no reply
26: no reply
27: no reply
28: no reply
29: no reply
30: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
tracepath gitea.artixlinux.org:
1?: [LOCALHOST] pmtu 1500
1: opiplus 2.374ms
1: opiplus 1.967ms
2: 10.8.2.1 43.982ms
3: no reply
4: no reply
5: 193.27.15.36 63.373ms
6: xe-2-2-3-0.core1.fra2.de.m247.com 57.241ms asymm 14
7: no reply
8: vlan2913.bb1.ams1.nl.m247.com 74.383ms asymm 12
9: ae2-1000.core1.ams2.nl.m247.com 55.871ms
10: 176.10.83.119 58.130ms asymm 11
11: ams-ix.b6777.Kermit.ipv4.wtnet.de 60.723ms asymm 9
12: b31040.Bibo.ipv4.wtnet.de 73.500ms
13: b99.pop104-asr.ipv4.wtnet.de 64.719ms asymm 11
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
25: no reply
26: no reply
27: no reply
28: no reply
29: no reply
30: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
Do this information somehow help to track the problem down?
---
And now I had it once when trying to access the forum, that I got a Error 502 "Bad Gateway" with a cloudflare website:
(https://i.imgur.com/1dMvYAv.png)
(Reloading and it worked again.)
---
Regarding the forum: When I want to write in this thread, I see a message at the top saying
But I nevertheless can reply. What is wrong here?
If you try searching the error (which is quicker than trying to rewrite it all here) something like "PR_END_OF_FILE_ERROR secure connection failed firefox" then it returned various helpful suggestions and explanations, e.g. :
https://support.mozilla.org/en-US/questions/1267074 (https://support.mozilla.org/en-US/questions/1267074)
https://superuser.com/questions/1492755/what-does-the-pr-end-of-file-error-error-mean-in-firefox (https://superuser.com/questions/1492755/what-does-the-pr-end-of-file-error-error-mean-in-firefox)
It suggests the cipher used by the website is not supported by your VPN server which makes the connection on your behalf, so it might also be helpful to report it to your VPN provider. Perhaps they intentionally don't support it for security reasons or perhaps it is newer than their update status, or something else, who knows. I don't know if it has any relevance but https involves a third party web address which validates the certificate, so possibly that could be involved too, although I didn't see anything mentioning it from briefly looking at some of those search results.
that would mean that the VPN server is not a VPN server but a proxy which acts as a man in the middle in the HTTPS connection.
I have a proper network device for the VPN, and my webbrowser connects directly to the target site. So if your statement is true it must mean that the "VPN" server would
intercept the connection as a man in the middle.
That should be detectable by looking at the certificates I get, because a man in the middle cannot forge a certificate (if the original server's private key has not leaked).
Hm, maybe some third party validation request not working here?
Is there a way I can exclude that Artix' servers refuse to serve said IP adress (range) correctly?
Your browser it's the cause perhaps a nightly built. In those nightly builds they try fixing some ff open bugs and it looks like the bug or other related problem wasn't fixed.
If it was the browser why is curl also failing?
It's the VPN.
Yeah VPN is the cause.
I've tested with this website (https://www.ssllabs.com/ssltest/analyze.html?d=gitea.artixlinux.org)
Looks like gitea rejects everything bellow tls1.3 and tls1.2 an sends "fatal alert: handshake_failure"
Perhaps VPN advertise some lower than tls 1.3/1.2 protocol so because gitea does not agree it gives handshake error. Most likely the VPN uses lower standards for higher efficiency. My conclusion is the VPN must be configured to accept higher protocol standards to fix the problem.
I have a big confusion now: Why does the VPN interfere in any way? It can only do if it would hijack the SSL connection. But that I would recognise on other sites due to false certificates. The only thing I can see is that the VPN can block the connection totally, but not interfere with the TLS handshake or connection. Can you enlighten me?
This: Reddit thread "Suddenly unable to access any Google services with an active VPN." (https://www.reddit.com/r/nordvpn/comments/e6khxe/suddenly_unable_to_access_any_google_services/) suggests that something might also be blocking NordVPN IP adresses on the server side -- there it is google blocking known NordVPN IPs.
I have tested what was suggested there to try another NordVPN server, and there I can access https://gitea.artixlinux.org/ via a brazilian NordVPN server (IP adress: 189.1.170.176).
So, the question remains: How can I rule out that something on the server side of the Artix' servers or datacenter or their content delivery network is just blocking the IP range in question? And if it is: They should change this.
Another VPN, different server that has higher protocol standards that meet gitea requirements that's why it works. When you use VPN your connection is not negotiated client side (ff) but involves VPN configuration so even your ff is ok VPN standards has to be properly configured.
When you use VPN your connection (handshake) to any website is done between VPN server that encapsulates (hides) all that in its payload and gitea or whatever website you are trying to reach. You just receive data already negotiated by you current VPN server.
It has nothing to do with ip blocking or other restrictions.
You can check your client which in case you use VPN your client is your VPN server in use. TEST HERE (https://www.ssllabs.com/ssltest/viewMyClient.html)
My understanding. It doesn't hijack the SSL connection. It
makes the SSL connection. Then what is received back it sends to you through the VPN tunnel. You are not getting a VPN tunnel from your computer / router to the website. The VPN tunnel is just between you and the VPN server.
Disclaimer: I'm no expert and that's probably an oversimplification.
Edit: On the way to the shop and back I'm thinking that can't be right either ? IDK. I've a big confusion as well. I'll give it some thought.
Yep
@gripped said it right, a VPN encrypts traffic between your pc and the remote VPN server. Then the VPN server connects to the needed website fetches the data and encrypts it inside it's payload (with the header and payload) then it sends it back to you with a new packet header specific to that VPN server used. So all handshakes are negotiated at the remote VPN server and if that is improper configured some connections may fail.
Result: TLS 1.0 up to TLS 1.3 is available. See attached screenshot for full details.
(https://i.imgur.com/sIvMZTe.png)
If the VPN server makes the VPN connection, then it is like hijacking: I want to make a SSL connection from my browser to the target server. End-to-end encryption between my browser and the target server. If some intermediate (like the VPN server) makes the SSL connection, then it is not anymore end-to-end encryption between my browser and the target server.
You confuse a VPN with a proxy:
The VPN encapsulates the traffic between my computer and the VPN providers data center. My computer makes the direct connection to gitea.artixlinux.com, but on the way it is routed through a special tunnel where it _additionally_ is encapsulated at the one side and decapsulated at the other side. That does not interfer with the connection that my browser makes to the target website. (A web proxy would do that.) This is like any other path my data might take through the internet, different routers, the internet service provider, etc. The VPN simply make me come "into the internet" at a different point (from a different IP adress) than if I would go directly through the internet service provider. That's the purpose of a tunnel: To just encapsulate what flows through it, not doing stuff on behalf of any site.
Nope you didn't get it right. Visit this link (https://www.ipvoid.com/ip-blacklist-check/) while you have your VPN on, write down the ip then visit again that page with the VPN turned off and you'll see a different ip. If things would be like you say it would mean in both cases you should get the same ip which isn't the case not on a VPN nor on a proxy.
You have to test your client with the VPN server that gave that error not with the other that works. Also i can't see any print screen you speak of.
Any website you visit thru a VPN it will see public ip of the VPN server not yours. It's like you send a box and your VPN provider put your box inside a bigger box with its ip on it, the WEBSITE negotiate based on that bigger box (not based on your smaller box from your ff) cos it doesn't know inside there's another box (with your real ip) puts that requested info inside that bigger box goes back to VPN server that sends it back to you and your firewall checks bigger box header then pass it on to your VPN client that's the only app that can figure out what's inside (except the VPN server)
If you don't understand the technology you need to take a closer look.
The difference between a proxy and a VPN is that the PROXY does not hide metadata between you and the proxy (on the wire) so only the website will don't know your real ip while VPN hides metadata inside its payload and nobody including those that can sniff data on the wire have no idea what website you're on. (except the guys that run the VPN server)
A VPN doesn't turn you into a 100% anonymous guy, it only keeps data private against 3rd parties.
Of course I get a different IP with a VPN. That is what I meant with "
The VPN simply make me come "into the internet" at a different point (from a different IP adress)".
Yes, I did exactly that!
To verify, I tried to visit https://gitea.artixlinux.org/ before and after the ssllabs-test (https://www.ssllabs.com/ssltest/viewMyClient.html) and confirmed that I get the connection error.
Here again:
https://i.imgur.com/sIvMZTe.png
.. it was embedded in the previous post as
[img width=120]https://i.imgur.com/sIvMZTe.png[/img]
that is exactly what it is supposed to do.
No. The website negotiates directly with my browser. That is the idea of the "boxes": they just encapsulate and de-capsulate the traffic. To the website, it looks that my browser comes from the IP of the VPN server, but it is my browser which makes the negotiation.
OpenVPN (which is the standard I use) operates at OSI layer 2 or 3 (https://community.openvpn.net/openvpn/wiki/OverviewOfOpenvpn). This is at most at the network level (where also IP is), and below the "Transport"-Level (TCP ...) and the "Session"-level (HTTPS ...). (-> Wikipedia "OSI model (https://en.wikipedia.org/wiki/OSI_model)".)
The layers are such that lower level layers are transparent with regard to higher level.
What do you mean with "real IP"? Locally I have 192.168.100.4. Then this gets to my router. On the output, it has some 10.x-IP to my internet service provider. The internet service provider exits to the internet at again a different IP.
You need to define what you mean with "real IP", because even without a VPN there are layers of routing and tunneling (in my case, via mobile network) involved.
For sure!
And not every VPN is for beeing anonymous. VPNs can be used to virtually connect networks, or to appear to the internet from a different IP, to provide a real network over some poor man's tunnel (like tunneling network via DNS), ...
Your real ip is your public ip that you get from the ISP.
If the handshake would be made in your browser the website would know your real public ip. So because the WEBSITE have no idea at least that's intended (VPN has to have no leaks which some do have) it starts negotiate handshake with the VPN ip (bigger box). The VPN has to be configured in such a way to let WEBSITE know what he needs of course based on what your browser can do but without exposing anything more than needed.
Also is wrong to say handshake happens in your browser cos it's rather a dialog. Your VPN advertise protocols your client supports (firefox), and the WEBSITE tells your VPN what it needs to start exchanging data. The handshake is successful when both parties receives the ok and starts normal operation.
When the WEBSITE sends the ok it sends it to the VPN server ip then the VPN forwards it to your public ip but its payload is encrypted. After that it reaches your router and then your VPN client on your pc
OK, let's take that as definition (I also can have several parallel connections to the internet at the same time, by the way).
You confuse the different network layers.
That would imply that the VPN would
not be a network transparent to higher OSI layers, but would need to intercept all of them. Especially, it would imply that only a defined set of application protocols can be supported.
Given your explanation, each router on the way would also need to make the handshake
Let me try with an analogy to ordinary mail:
Assume I want to write a letter to my city council to inquire some information.
The direct way would be to write the letter with my request on it, but it in an envelope, put the address of the city council on the envelope.
Then I go to the mail box and shortly before putting it into the mail box I write my address on the "sender" field of the envelope, so that the answer can be returned to me.
Then I put the envelope with the letter inside into the mail box.
The mail company will find the letter in it's mail box, and will deliver it to the address stated on the envelope.
The letter arrives at the city council, they open the envelope, and find my letter. They keep the envelope to remember the sender address, then they process my inquiry, and then they send back the answer to the address given as "sender" on the envelope.
So I will receive the answer.
Now, I also can do the following:
I can put above envelope, with the address of the city council on it, into another envelope which has the address of my employer on it. Shortly before putting this into the mail box I write my address as the "sender" address on the outer envelope.
Then the mail company will deliver the letter to my employer, not to the city council.
My employer will open the outer envelope, and they discover that there is an inner envelope inside. They will write their address in the "sender" field of the inner envelope and put the inner envelope into the mail box.
Then the inner envelope will be delivered to the city council.
They open the inner envelope and find my request.
Now, the answers also flow back via my employer to me (as the "sender" addresses on the envelopes stated). But the letter itself is still the same.
In this analogy, the mail companiees are the internet service provider(s), my employer is the VPN. The letter is the request that my web browser does, i.e. SSL/TLS handshakes. The addresses are IP addresses.
---
In this analogy, a proxy would be when I would not use an outer envelope but would mail the letter directly to my employer, which would read the letter, rewrite it on their own paper, and then send it to the city council.
FWIW - it works with firefox, but firefox is not in anyway a perfect thing. It sounds like network connectivity?
The best you can do is fire up wireshark and see what goes where and why.
Those routers have the purpose to forward packets not make handshakes. Routers don't have openssl unless they have VPN function and allocated a public ip, which they not have. Also handshakes doesn't happen between internal ip unless it's different kind of network and also because the packet recipient is your pc public ip an not the router's internal ip (unless someone tries a man in the middle attack)
> You confuse the different network layers.
No there's only 1, network layer (OSI has 7 layers)
You need your real ip to reach VPN server that creates the TUNNEL between you and VPN server. It's improper to use the term TUNNEL though as what in fact is it's a packet sent via public ip the only thing is that the payload is encrypted and contains everything VPN negotiated/fetched from the WEBSITE on your behalf
VPN server negotiate on your behalf (like it's you and you are like him) based on what you send of course, obfuscating your real ip and other metadata (like time etc) that would de-anonymize you .
I'm gonna try draw a detailed scheme so it will be much easy to visualize 100% what happens.
My PC has just the IP 192.168.100.4.
My router makes NAT to some 10.x.x.x (which is the network of my internet service provider), which then has a public IP (probably
shared with some other internet users, the ISPs NAT keeps track of what incoming has to go where).
Another PC at home has 192.168.100.2, and goes to the internet via the same router, via the same 10.x.x.x, and then at the ISP site via the same public IP.
The router also is a computer (I even have a text browser on it which can be used via ssh), and when the router accesses the internet it has the same public IP.
There is no clear notion of "my PC public IP", because all my devices including the router share the same public IP to the outside world, as given by the ISP.
VPN steps in at the 10.x.x.x-part and adds another IP to the router, which is like 10.y.y.y, in the network of the VPN server. The VPN server has a public IP, which is different from the one of my ISP. Physically, the packets via the VPN server travel via the ISP
---
Someone suggested that PMTUD might be broken, I have to research what this is.
Yes, please.
lol
https://en.wikipedia.org/wiki/Path_MTU_Discovery