m-labs-intl.com mirror #134

Open
opened 2024-05-23 14:14:45 +08:00 by sb10q · 6 comments
Owner

Some countries and companies are increasingly blocking Hong Kong internet. Let's host a mirror in the US:

  • use low-cost US hosting provider, I used Dreamhost a long time ago and it was fine, but maybe there are better offerings now, e.g. Hetzner has a US location now which sounds worth looking into. Amazon AWS is a scam and not worth spending any time on it.
  • auto-upload HTML from Hydra
  • the "request quote" function should work and also be hosted in the US
  • email sent to @m-labs-intl.com should be automatically forwarded to the same address @m-labs.hk. Again the MX should be in the US since those get blocked as well, sometimes even with email being silently dropped.

That should be enough to keep the basic things running. People could use VPNs or personal internet connections to access the other services for now (and we should probably explain that in a FAQ).

Some countries and companies are increasingly blocking Hong Kong internet. Let's host a mirror in the US: * use low-cost US hosting provider, I used Dreamhost a long time ago and it was fine, but maybe there are better offerings now, e.g. Hetzner has a US location now which sounds worth looking into. Amazon AWS is a scam and not worth spending any time on it. * auto-upload HTML from Hydra * the "request quote" function should work and also be hosted in the US * email sent to @m-labs-intl.com should be automatically forwarded to the same address @m-labs.hk. Again the MX should be in the US since those get blocked as well, sometimes even with email being silently dropped. That should be enough to keep the basic things running. People could use VPNs or personal internet connections to access the other services for now (and we should probably explain that in a FAQ).
esavkin was assigned by sb10q 2024-05-23 14:14:45 +08:00
Author
Owner

For the MX it would be better to just proxy the TCP connection, instead of forwarding email, so that the hosting provider does not get access to the cleartext emails when the sender uses SMTPS/STARTTLS (which is pretty much the norm now). Latency will be higher but it doesn't matter, unlike for the website.

For the MX it would be better to just proxy the TCP connection, instead of forwarding email, so that the hosting provider does not get access to the cleartext emails when the sender uses SMTPS/STARTTLS (which is pretty much the norm now). Latency will be higher but it doesn't matter, unlike for the website.
Member

What is the real evidence of these blockages?

What is the real evidence of these blockages?
Author
Owner

Plenty e.g. interaction with customers on Gmail or Signal. Try loading https://www.acquisition.gov/ for something you can easily reproduce. Or https://ngi.eu

Plenty e.g. interaction with customers on Gmail or Signal. Try loading https://www.acquisition.gov/ for something you can easily reproduce. Or https://ngi.eu
Member

I think either will do the work:

  1. Host the static website on any platform, even free tier render.com is fine. For RFQ, there can be a separate nginx instance that will act as a reverse proxy to our own RFQ. NGINX also can forward stream traffic to our mail SMTP/IMAP servers. For this, Digital Ocean will be far enough with their USD 4 minimal VPS ("Droplet"). This way RFQ would add up to 200-300ms of latency, which is really not critical, since it is already takes a second. Website itself would be opened through render.com's CDN, which would be fast enough in most locations worldwide, especially in North America.
  2. Host both the static website and reverse proxy services on one host. This way minimal droplet may be not enough in some future, since it has traffic limitations. So it may need USD 15 Dreamhost's VPS for this, and the latency will be good in North America.

In both cases, we'll need to filter out either Chinese/USA traffic, so that we do not publish VPN instructions in restrictive regions, which can result in respective lawful bans.

I think either will do the work: 1. Host the static website on any platform, even free tier render.com is fine. For RFQ, there can be a separate nginx instance that will act as a reverse proxy to our own RFQ. NGINX also can forward stream traffic to our mail SMTP/IMAP servers. For this, Digital Ocean will be far enough with their USD 4 minimal VPS ("Droplet"). This way RFQ would add up to 200-300ms of latency, which is really not critical, since it is already takes a second. Website itself would be opened through render.com's CDN, which would be fast enough in most locations worldwide, especially in North America. 2. Host both the static website and reverse proxy services on one host. This way minimal droplet may be not enough in some future, since it has traffic limitations. So it may need USD 15 Dreamhost's VPS for this, and the latency will be good in North America. In both cases, we'll need to filter out either Chinese/USA traffic, so that we do not publish VPN instructions in restrictive regions, which can result in respective lawful bans.
Author
Owner

I don't understand your obsession with reverse proxy. Just host a copy of the website as I suggested, and host a copy of the RFQ hook locally which uses whatever local email infrastructure is there. Why is it so hard?
This is a mirror website and has nothing to do with VPN and I don't see why you're suggesting doing any sort of regional blocking.

I don't understand your obsession with reverse proxy. Just host a copy of the website as I suggested, and host a copy of the RFQ hook locally which uses whatever local email infrastructure is there. Why is it so hard? This is a mirror website and has nothing to do with VPN and I don't see why you're suggesting doing any sort of regional blocking.
Author
Owner

The RFQ hook could just as well connect to the same mail.m-labs.hk since it would not be filtered from the VPS. So nothing even has to change.

The RFQ hook could just as well connect to the same mail.m-labs.hk since it would not be filtered from the VPS. So nothing even has to change.
Sign in to join this conversation.
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/web2019#134
No description provided.