guix.gnu.org is inaccessible from Russia

  • Done
  • quality assurance status badge
Details
6 participants
  • Evgeny Pisemsky
  • Ludovic Courtès
  • Christopher Baines
  • Maxime Devos
  • Tobias Geerinckx-Rice
  • poiNt_3D
Owner
unassigned
Submitted by
poiNt_3D
Severity
normal
Merged with
P
P
poiNt_3D wrote on 13 Mar 2022 07:14
network problem or intentional blocking?
(address . bug-guix@gnu.org)
CAOT6rO-TzDWnOtCXc9d+fZFzvSUNKNXnyzhjNEwxPD7mVVOCeA@mail.gmail.com
Hello. I would like to request a clarification on the issue of
inaccessibility of guix.gnu org from the Russian Federation.
Is the blocking intentional or is there some kind of networking problem?

Here's my traceroute output:

Toggle quote (32 lines)
> 6 ge-4-0-0-10g.m320-2-vlgd.nwtelecom.ru (212.48.195.41) 15.660 ms
> 13.065 ms 15.545 ms
> 7 109.172.24.67 (109.172.24.67) 32.341 ms 87.226.183.61 (87.226.183.61)
> 31.027 ms 28.507 ms
> 8 ae53.edge4.stockholm2.level3.net (213.249.107.129) 37.298 ms 29.497
> ms 35.571 ms
> 9 ae1.5.bar1.hamburg1.level3.net (4.69.142.209) 73.587 ms
> s-bb1-link.ip.twelve99.net (62.115.139.180) 27.296 ms
> ae1.5.bar1.hamburg1.level3.net (4.69.142.209) 74.064 ms
> 10 195.122.181.62 (195.122.181.62) 64.682 ms 66.071 ms 68.254 ms
> 11 ffm-b5-link.ip.twelve99.net (62.115.114.89) 51.213 ms
> cr-tub2-be13.x-win.dfn.de (188.1.144.58) 67.156 ms 61.032 ms
> 12 kr-mdcbln1.x-win.dfn.de (188.1.238.78) 65.546 ms
> dfn-ic357399-ffm-b5.ip.twelve99-cust.net (213.248.97.41) 50.044 ms
> 49.354 ms
> 13 cr-erl2-be8.x-win.dfn.de (188.1.144.221) 50.629 ms * *
> 14 cr-tub2-be10.x-win.dfn.de (188.1.146.210) 64.584 ms 56.154 ms *
> 15 kr-mdcbln1.x-win.dfn.de (188.1.238.78) 59.972 ms * 64.541 ms16 * *
> *
> 16 * * *
> 17 * * *
> 18 * * *
> 19 * * *
> 20 * * *
> 21 * * *
> 22 * * *
> 23 * * *
> 24 * * *
> 25 * * *
>


Thanks.
Attachment: file
E
T
T
Tobias Geerinckx-Rice wrote on 13 Mar 2022 12:43
Re: bug#54370: network problem or intentional blocking?
E500DC4E-B265-4469-A66F-946DF5D6535E@tobias.gr
Hi Point4d,

Specifically, from the thread linked by Evgeny:

"At the MDC level there’s an unrelated recent ban of some Russian IP ranges in place due to massively increased port scans and intrusion attempts since about one week. I hope you can use the Chinese mirror for the time being."

That mirror is at https://mirrors.sjtug.sjtu.edu.cn/guix. Let us know if it works.

Kind regards,

T G-R

Sent on the go. Excuse or enjoy my brevity.
T
T
Tobias Geerinckx-Rice wrote on 13 Mar 2022 13:15
(address . 54370@debbugs.gnu.org)
0D08CE96-0992-4AAC-973F-E97D34DB4156@tobias.gr
Hm,

I didn't address guix.gnu.org beyond ci.guix.gnu.org.

Everyone: should we ask SJTUG to mirror the Web site as well?

I'm generally weary of that.

Kind regards,

T G-R

Sent on the go. Excuse or enjoy my brevity.

Kind regards,

T G-R

Sent on the go. Excuse or enjoy my brevity.
C
C
Christopher Baines wrote on 13 Mar 2022 13:36
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 54370@debbugs.gnu.org)
87tuc258o8.fsf@cbaines.net
Tobias Geerinckx-Rice via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

Toggle quote (6 lines)
> I didn't address guix.gnu.org beyond ci.guix.gnu.org.
>
> Everyone: should we ask SJTUG to mirror the Web site as well?
>
> I'm generally weary of that.

I believe bayfront was being setup to serve the website (see [1]), but
I'm not sure on how that's progressing.

-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmIt5ddfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XfzuA/+M0sXCeuU4bOGAOXAGRVjXLGWXiB0aDgA
ubKWdwWoLB4DD8Lf9wQ/XqsHLxuBI+fdETtdft8lk7BhoJZFcLr9iuG2lHKWaUcS
ZUjCA0BDu/eKxJBK24DyrLx5g+IBOBiPO8iUoq8bQ+dTbyTyX1ANeq1Vdf5s1FBd
K5p5BrBMlM5sU50xJ0slv5RdgNvqi2AmvWBkhjOMWU1AqhwaCr++xTSzOQC9zPF/
N+rXAZ+c+2jRqwaD4OuJCID0ug+EzkNCPQms6b4FMRColqPSSVUdglYpSkTXR0ik
8K4MtcV7ASFbTxOuDzLj5/epl7MkT4z4Ve+DgJ758dMp3TzClTQVW9VUSC2MMXKY
sKyQH8NTve2qNjGKYZxBPKEoNLShkeQRpkbP6TwQ5rxGMie4P9saq5rzz18EF4YR
R8pJGQQSUTvqNdA5A55SqV9rMVHq7xCOy8ez+NkUy/KIv0JOEByiBhiSTZ0X+7L7
mE6lWXeWLH9NjNVgO6cvHyCpFdq5WojZ27FUQRu+JOUbxh6HowL081gRYwiBM8ue
leHDIHm80FoZZA4TrmEEVezmFAt5vb5In8dg43O9jweU/8OStspmGXsl9rlvHy3i
0GJk5kRp+XbCdL+I5vRNlJCAJRRBd0WPx1CDXhz9U4vS3boWnYtcYXDkNNQRKpAw
j6kRoC4Jers=
=k/dc
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 13 Mar 2022 15:30
(name . Christopher Baines)(address . mail@cbaines.net)
87ilshudq4.fsf@gnu.org
Hi,

Christopher Baines <mail@cbaines.net> skribis:

Toggle quote (5 lines)
> I believe bayfront was being setup to serve the website (see [1]), but
> I'm not sure on how that's progressing.
>
> 1: https://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=8250a46b2fa178d1cdd37986028d5a07e3db65ed

Indeed. The plan we discussed during the “sysadmin hackathon” a couple
of months ago was to, for instance, have the DNS entry point to these
two machines.

The problem we keep stumbling upon and that I don’t know how yet how to
solve is how to make it work for HTTPS: do we copy raw certificates to
bayfront, or is there a way to have separate certificates? How about
Let’s Encrypt challenges?

These are the last issues to solve and I’d welcome expertise here. Any
ideas?

Everything else is addressed: the web site gets built on bayfront just
like it is on berlin, static data such as videos and PDFs are
automatically mirrored to bayfront.


Thanks,
Ludo’.
T
T
Tobias Geerinckx-Rice wrote on 13 Mar 2022 16:30
(name . Ludovic Courtès)(address . ludo@gnu.org)
f3afbeb603be741597c15cc55dc6351d@tobias.gr
Hi!

On 2022-03-13 15:30, Ludovic Courtès wrote:
Toggle quote (4 lines)
> The plan we discussed during the “sysadmin hackathon” a couple
> of months ago was to, for instance, have the DNS entry point to these
> two machines.

Uhm, quick but:

Apparently some browsers (OK, one, and we all know which one) embraces &
extends the DNS in such a way that this provides the fall-back behaviour
you seem to expect. But this is not standard and it won't fly with most
software. I checked.

It doesn't in Firefox/IceCat. Even if it does in current Chrom{e,ium},
it might just be an unreliable side-effect.

Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.
T
T
Tobias Geerinckx-Rice wrote on 13 Mar 2022 20:50
(address . 54370@debbugs.gnu.org)
cf339c6f86a81c5ba71154ed37a31cb6@tobias.gr
[Resending to the proper address, sorry; I'm mu4e-less and hence
incompetent :-]

Hi!

On 2022-03-13 20:00, poiNt_3D wrote:

Toggle quote (3 lines)
> Is it possible to set the firewall to allow only public services to be
> accessed from these IP ranges?

I'm afraid we don't control the berlin firewall or have much sway in how
it's managed, so there's little point in discussing such actions.

Toggle quote (2 lines)
> can be easily interpreted as a political decision

With Russia waging war, it seems likely that these Russian ISPs tolerate
abusive traffic for political reasons. There are probably political
consequences for those who refuse.

The Internet was and still is built on ISP accountability and gives
targets few other tools to effectively defend themselves, short of
blocking such IP ranges.

I wish there were a better answer than 'use Tor' for those stuck in the
cross-fire :-(

Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.
T
T
Tobias Geerinckx-Rice wrote on 13 Mar 2022 21:03
(name . Ludovic Courtès)(address . ludo@gnu.org)
634e11a2060e38814348571435f9fdc5@tobias.gr
Pending expertise, is it feasible to serve the copy as-is without trying
to impersonate berlin? E.g. mirror.guix.gnu.org?

Hm, maybe that's not worth the effort…

I've asked around and short of pointing guix.gnu.org to bayfront —
working around the issue & hoping that it will continue to be unaffected
— or using a CDN that has points of presence in Russia — which can
easily be taken down in a future wave of sanctions — the situation seems
to be quite disappointing.

For proper fail-over you (ironically) need one box sitting in front of
the boxes you want to fail over to.

Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.
M
M
Maxime Devos wrote on 13 Mar 2022 21:36
028317bebedcd18fc0063fbff3a20b9e509043a2.camel@telenet.be
Tobias Geerinckx-Rice via Bug reports for GNU Guix schreef op zo 13-03-
2022 om 20:50 [+0100]:
Toggle quote (3 lines)
> I wish there were a better answer than 'use Tor' for those stuck in the
> cross-fire :-(

For the website, publishing the website not only over HTTP/S but also
over IPFS might help? The website is static and Guix has an IPFS
service, so it should be feasible I think. The browser extension
packaged though, and a DNS link record
need to be set up.

Greetings,
Maxime.
-----BEGIN PGP SIGNATURE-----

iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYi5VwBccbWF4aW1lZGV2
b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7sH0AP9W8ILRi9gOvt3LQ8K5qDF3xG49
DeqOTGbOzNmODI3uwQEAi5/v/gr3sDcVBuGRQ/4myNcdbYUygP+GmtWHFHmMZwk=
=z/BE
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 15 Mar 2022 08:57
(name . Maxime Devos)(address . maximedevos@telenet.be)
87bky7przs.fsf@gnu.org
Hi Maxime,

Maxime Devos <maximedevos@telenet.be> skribis:

Toggle quote (8 lines)
> For the website, publishing the website not only over HTTP/S but also
> over IPFS might help? The website is static and Guix has an IPFS
> service, so it should be feasible I think. The browser extension
> (https://docs.ipfs.io/install/ipfs-companion/) would need to be
> packaged though, and a DNS link record
> (https://docs.ipfs.io/concepts/dnslink/#resolve-dnslink-name) would
> need to be set up.

That and/or publishing as an onion service would be great.

Ludo’.
L
L
Ludovic Courtès wrote on 15 Mar 2022 15:33
control message for bug #54370
(address . control@debbugs.gnu.org)
87k0cvjneb.fsf@gnu.org
retitle 54370 guix.gnu.org is inaccessible from Russia
quit
L
L
Ludovic Courtès wrote on 19 Mar 2022 12:04
Re: bug#54370: guix.gnu.org is inaccessible from Russia
87y216mcdu.fsf_-_@gnu.org
Hi,

I updated the onion address in the section of the cookbook that explains
how to get substitutes from ci.guix over Tor:


Copying the text inline below.

Next step is to publish an Onion service for the web site.

HTH,
Ludo’.

3.8 Getting substitutes from Tor
================================

Guix daemon can use a HTTP proxy to get substitutes, here we are
configuring it to get them via Tor.

Warning: _Not all_ Guix daemon’s traffic will go through Tor! Only
HTTP/HTTPS will get proxied; FTP, Git protocol, SSH, etc
connections will still go through the clearnet. Again, this
configuration isn’t foolproof some of your traffic won’t get routed
by Tor at all. Use it at your own risk.

Also note that the procedure described here applies only to package
substitution. When you update your guix distribution with ‘guix
pull’, you still need to use ‘torsocks’ if you want to route the
connection to guix’s git repository servers through Tor.

Guix’s substitute server is available as a Onion service, if you want
to use it to get your substitutes through Tor configure your system as
follow:

(use-modules (gnu))
(use-service-module base networking)

(operating-system
(services
(cons
(service tor-service-type
(tor-configuration
(config-file (plain-file "tor-config"
"HTTPTunnelPort 127.0.0.1:9250"))))
(modify-services %base-services
(guix-service-type
config => (guix-configuration
(inherit config)
;; ci.guix.gnu.org's Onion service
(substitute-urls
"https://4zwzi66wwdaalbhgnix55ea3ab4pvvw66ll2ow53kjub6se4q2bclcyd.onion")
(http-proxy "http://localhost:9250")))))))

This will keep a tor process running that provides a HTTP CONNECT
tunnel which will be used by ‘guix-daemon’. The daemon can use other
protocols than HTTP(S) to get remote resources, request using those
protocols won’t go through Tor since we are only setting a HTTP tunnel
here. Note that ‘substitutes-urls’ is using HTTPS and not HTTP or it
won’t work, that’s a limitation of Tor’s tunnel; you may want to use
‘privoxy’ instead to avoid such limitations.

If you don’t want to always get substitutes through Tor but using it
just some of the times, then skip the ‘guix-configuration’. When you
want to get a substitute from the Tor tunnel run:

sudo herd set-http-proxy guix-daemon http://localhost:9250
guix build \
T
T
Tobias Geerinckx-Rice wrote on 18 May 2022 17:12
(no subject)
(address . control@debbugs.gnu.org)
95dcea845394171ab8d060598d90f579@tobias.gr
merge 55500 54370
C
C
Christopher Baines wrote on 7 Feb 2023 16:33
Re: bug#54370: network problem or intentional blocking?
(name . poiNt_3D)(address . point4d@gmail.com)
87ilgd8p5y.fsf@cbaines.net
poiNt_3D <point4d@gmail.com> writes:

Toggle quote (4 lines)
> Hello. I would like to request a clarification on the issue of
> inaccessibility of guix.gnu org from the Russian Federation. Is the
> blocking intentional or is there some kind of networking problem?

Now that the website is hosted on bayfront, which wasn't changed
specifically to address this, but should do anyway, I'm going to close
this issue.

Things like ci.guix.gnu.org will still be inaccessible, so feel free to
open issues about those if you wish.

Thanks,

Chris
-----BEGIN PGP SIGNATURE-----

iQKlBAEBCgCPFiEEPonu50WOcg2XVOCyXiijOwuE9XcFAmPib5lfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDNF
ODlFRUU3NDU4RTcyMEQ5NzU0RTBCMjVFMjhBMzNCMEI4NEY1NzcRHG1haWxAY2Jh
aW5lcy5uZXQACgkQXiijOwuE9XeEaQ/9FDsAvfGwfH/oPTot5jd+6rrdcPjGFEpM
rEnlHoWlU22A4ZUc+83bAWdrObdWwWHvfMlwNZIo6AG1gQ4YOjloua0WZln/TTMr
d5O6f2tmg1yIkMQYkg+lfLZQaaslVrEqzrdmgGmsci9OWRWGTkyl1rjNEdtynnTc
R82ZDOJ/6HyuWpldczxO325iGE03NVyZ/BQC668j5HF3N3ofMh8ylXxgd14Jckvp
nydGwoLvN4aCvm4wOVzUA6BlAjZ56QjrQwoSzN5YDLw7wBfV1zoBvk1pZigXRul3
lS8g5RXgFDfpXeI7c268KvR+K0ytYRb5jw2kTJ45CLYv34MRYJsSgT50mlMn5UrD
Ve39nYT4NjjFew4jc33L5kf49GLQer+Vkf45BATmPEah6mNVNIuPQhUKT7ZtYeK1
bNDF82VVFf8VlKyTPx+JeWotfvHJwuyXvb1LsLzcwkrmN5PmjEhds/WJkFKS9kGV
0Dumb1Vn4MRQ7uTrVNeGzK4hDRGiEUpJTKInKML7rcVqpYyzaJz7SOWHWViLCXy+
oLiUFuKM2AYAVn9qvmZd2kuuZySZaujthpLYfWqZTgphVf0v2gPFXJAEQdJCwz4L
13UB9NrtEyA0dbnPBiWKwnT4eLitF3rk15NGVWyUeMwCPE9ftBcHLCaXm0MyJzkR
NFXB0wOLgxc=
=oG3u
-----END PGP SIGNATURE-----

?
Your comment

This issue is archived.

To comment on this conversation send an email to 54370@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 54370
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch