curben
/
blog
mirror of https://gitlab.com/curben/blog
1
0
Fork 0
Code Issues Releases Wiki Activity

fix: update curben.netlify.com to curben.netlify.app

This commit is contained in:
MDLeom 2020-04-21 06:36:09 +01:00
parent a1373a8a8b
commit 980d1eb0d3
No known key found for this signature in database
GPG Key ID: 5D9DB57A25D34EE3
5 changed files with 24 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@ -46,7 +46,7 @@ The content of this blog is licensed under the [CC-BY-SA license](https://creati
## Mirrors ## Mirrors
- https://curben.netlify.com/ - https://curben.netlify.app/
- http://xw226dvxac7jzcpsf4xb64r4epr6o5hgn46dxlqk7gnjptakik6xnzqd.onion/ - http://xw226dvxac7jzcpsf4xb64r4epr6o5hgn46dxlqk7gnjptakik6xnzqd.onion/
- http://mdleom.i2p/ - http://mdleom.i2p/
- http://ggucqf2jmtfxcw7us5sts3x7u2qljseocfzlhzebfpihkyvhcqfa.b32.i2p/ - http://ggucqf2jmtfxcw7us5sts3x7u2qljseocfzlhzebfpihkyvhcqfa.b32.i2p/

8
source/_posts/caddy-nixos-part-1.md
View File

@ -36,17 +36,17 @@ This website's JAMstack workflow goes like this:
2. Markdown files are Git-hosted on GitLab 2. Markdown files are Git-hosted on GitLab
3. Any commit to GitLab repository triggers a build on Netlify CI 3. Any commit to GitLab repository triggers a build on Netlify CI
4. Markdown files are processed into HTML pages using Nodejs-powered Hexo. 4. Markdown files are processed into HTML pages using Nodejs-powered Hexo.
5. Generated pages are hosted on curben.netlify.com 5. Generated pages are hosted on curben.netlify.app
Right off the bat I can already see the need of setting up a private server due to the second requirement (ability to remove HTTP header). I had an option to drop Netlify by building the pages on my workstation and deploy to the web server (using a Hexo deployer plugin). So far I do find Netlify service to be reliable and it offers features like adding headers and reverse proxy which are easy to setup. Speaking of Netlify's features, I then had an idea of setting up a web server which reverse proxy to Netlify. This approach meets all the four requirements; a side-benefit is that if I screw up the web server, at least my website is still up on curben.netlify.com and I can easily migrate this domain to Netlify. Right off the bat I can already see the need of setting up a private server due to the second requirement (ability to remove HTTP header). I had an option to drop Netlify by building the pages on my workstation and deploy to the web server (using a Hexo deployer plugin). So far I do find Netlify service to be reliable and it offers features like adding headers and reverse proxy which are easy to setup. Speaking of Netlify's features, I then had an idea of setting up a web server which reverse proxy to Netlify. This approach meets all the four requirements; a side-benefit is that if I screw up the web server, at least my website is still up on curben.netlify.app and I can easily migrate this domain to Netlify.
As for web server, I went with Caddy, which has the most secured defaults. It is installed in NixOS, which is attractive for its centralised configuration. I initially planned to use Ubuntu, and then I noticed [NixOS](https://nixos.org/); unlike most other Linux servers which has configs scattered around, NixOS is configured through a single "configuration.nix" file. It is [declarative](https://en.wikipedia.org/wiki/Declarative_programming), meaning you simply supply the desired configuration and NixOS would figure how to achieve that. For example, to open port 80, you just need `networking.firewall.allowedTCPPorts = [ 80 ]`, instead of mucking around with iptables. This significantly helps reproducibility, making server migration much easier; simply supply the "configuration.nix" used in the previous server and the new server would have the same state. Having Caddy in the repo is the tipping point that finally made me dive into NixOS. As for web server, I went with Caddy, which has the most secured defaults. It is installed in NixOS, which is attractive for its centralised configuration. I initially planned to use Ubuntu, and then I noticed [NixOS](https://nixos.org/); unlike most other Linux servers which has configs scattered around, NixOS is configured through a single "configuration.nix" file. It is [declarative](https://en.wikipedia.org/wiki/Declarative_programming), meaning you simply supply the desired configuration and NixOS would figure how to achieve that. For example, to open port 80, you just need `networking.firewall.allowedTCPPorts = [ 80 ]`, instead of mucking around with iptables. This significantly helps reproducibility, making server migration much easier; simply supply the "configuration.nix" used in the previous server and the new server would have the same state. Having Caddy in the repo is the tipping point that finally made me dive into NixOS.
![Architecture behind mdleom.com](20200223/caddy-nixos.png) ![Architecture behind mdleom.com](20200223/caddy-nixos.png)
Above diagram shows the architecture behind this website (mdleom.com). When a visitor browse mdleom.com, it will first go through Cloudflare CDN, the CDN then pass the request to my virtual private server (VPS). Before it reaches my VPS, there is a cloud firewall provided by the VPS host which I configure to allow inbound port 443. Once my VPS receive the request, the iptables port forward from 443 to 4430. The web server (Caddy) binds to (or listens on) port 4430 and it acts as a reverse proxy to the actual backend, curben.netlify.com. Above diagram shows the architecture behind this website (mdleom.com). When a visitor browse mdleom.com, it will first go through Cloudflare CDN, the CDN then pass the request to my virtual private server (VPS). Before it reaches my VPS, there is a cloud firewall provided by the VPS host which I configure to allow inbound port 443. Once my VPS receive the request, the iptables port forward from 443 to 4430. The web server (Caddy) binds to (or listens on) port 4430 and it acts as a reverse proxy to the actual backend, curben.netlify.app.
The flow is slightly different when browsing via [.onion](http://xw226dvxac7jzcpsf4xb64r4epr6o5hgn46dxlqk7gnjptakik6xnzqd.onion). Tor hidden service is able to NAT-punching, only rely on outbound connection, so it can work behind a firewall that block inbound ports. The Tor daemon acts as a reverse proxy and forward the request to Caddy, which in turn is also a reverse proxy which finally forward the request to curben.netlify.com. The flow is slightly different when browsing via [.onion](http://xw226dvxac7jzcpsf4xb64r4epr6o5hgn46dxlqk7gnjptakik6xnzqd.onion). Tor hidden service is able to NAT-punching, only rely on outbound connection, so it can work behind a firewall that block inbound ports. The Tor daemon acts as a reverse proxy and forward the request to Caddy, which in turn is also a reverse proxy which finally forward the request to curben.netlify.app.
## Installation ## Installation

18
source/_posts/caddy-nixos-part-3.md
View File

@ -10,7 +10,7 @@ tags:
- nixos - nixos
--- ---
In this segment, I show you how I set up this website (mdleom.com) to reverse proxy to curben.netlify.com using Caddy on NixOS (see above diagram). If you're not using NixOS, simply skip to the [Caddyfile](#Caddyfile) section. In this segment, I show you how I set up this website (mdleom.com) to reverse proxy to curben.netlify.app using Caddy on NixOS (see above diagram). If you're not using NixOS, simply skip to the [Caddyfile](#Caddyfile) section.
This post is Part 2 of a series of articles that show you how I set up Caddy and Tor hidden service on NixOS: This post is Part 2 of a series of articles that show you how I set up Caddy and Tor hidden service on NixOS:
@ -215,7 +215,7 @@ If you prefer to redirect apex to www,
### Reverse proxy ### Reverse proxy
Aside from reverse proxy to curben.netlify.com, I also configured my Netlify website to use Statically CDN for on-the-fly image processing. My current [config](https://gitlab.com/curben/blog) is: Aside from reverse proxy to curben.netlify.app, I also configured my Netlify website to use Statically CDN for on-the-fly image processing. My current [config](https://gitlab.com/curben/blog) is:
``` plain source/_redirects https://gitlab.com/curben/blog/-/blob/master/source/_redirects _redirects ``` plain source/_redirects https://gitlab.com/curben/blog/-/blob/master/source/_redirects _redirects
/img/* https://cdn.statically.io/img/gitlab.com/curben/blog/raw/site/:splat 200 /img/* https://cdn.statically.io/img/gitlab.com/curben/blog/raw/site/:splat 200
@ -234,11 +234,11 @@ In Caddyfile, the config can be expressed as:
to /screenshot{1}?mobile=true to /screenshot{1}?mobile=true
} }
proxy /screenshot https://cdn.statically.io/screenshot/curben.netlify.com { proxy /screenshot https://cdn.statically.io/screenshot/curben.netlify.app {
without /screenshot without /screenshot
} }
proxy / https://curben.netlify.com proxy / https://curben.netlify.app
``` ```
`without` directive is necessary to remove `libs/` from the path, so that "mdleom.com/libs/foo/bar.js" is linked to "https://cdn.statically.io/libs/foo/bar.js", not "https://cdn.statically.io/libs/libs/foo/bar.js". `without` directive is necessary to remove `libs/` from the path, so that "mdleom.com/libs/foo/bar.js" is linked to "https://cdn.statically.io/libs/foo/bar.js", not "https://cdn.statically.io/libs/libs/foo/bar.js".
@ -260,12 +260,12 @@ To make sure Caddy sends the correct `Host:` header to the upstream/backend loca
to /screenshot{1}?mobile=true to /screenshot{1}?mobile=true
} }
proxy /screenshot https://cdn.statically.io/screenshot/curben.netlify.com { proxy /screenshot https://cdn.statically.io/screenshot/curben.netlify.app {
without /screenshot without /screenshot
header_upstream Host cdn.statically.io header_upstream Host cdn.statically.io
} }
proxy / https://curben.netlify.com { proxy / https://curben.netlify.app {
header_upstream Host cdn.statically.io header_upstream Host cdn.statically.io
} }
``` ```
@ -423,15 +423,15 @@ mdleom.com:4430 www.mdleom.com:4430 {
to /screenshot{1}?mobile=true to /screenshot{1}?mobile=true
} }
proxy /screenshot https://cdn.statically.io/screenshot/curben.netlify.com { proxy /screenshot https://cdn.statically.io/screenshot/curben.netlify.app {
without /screenshot without /screenshot
import removeHeaders import removeHeaders
import staticallyCfg import staticallyCfg
} }
proxy / https://curben.netlify.com { proxy / https://curben.netlify.app {
import removeHeaders import removeHeaders
header_upstream Host curben.netlify.com header_upstream Host curben.netlify.app
} }
} }
``` ```

10
source/_posts/i2p-eepsite-nixos.md
View File

@ -11,7 +11,7 @@ tags:
- censorship - censorship
--- ---
In this segment, I show you how I set up I2P Eepsite service that reverse proxy to curben.netlify.com. This website can be accessed using this [B32 address](http://ggucqf2jmtfxcw7us5sts3x7u2qljseocfzlhzebfpihkyvhcqfa.b32.i2p) or [mdleom.i2p](http://mdleom.i2p/) In this segment, I show you how I set up I2P Eepsite service that reverse proxy to curben.netlify.app. This website can be accessed using this [B32 address](http://ggucqf2jmtfxcw7us5sts3x7u2qljseocfzlhzebfpihkyvhcqfa.b32.i2p) or [mdleom.i2p](http://mdleom.i2p/)
This post is Part 5 of a series of articles that show you how I set up Caddy, Tor hidden service and I2P Eepsite on NixOS: This post is Part 5 of a series of articles that show you how I set up Caddy, Tor hidden service and I2P Eepsite on NixOS:
@ -25,7 +25,7 @@ The reason I set up an Eepsite is similar to why I have a Tor hidden service, is
A thing to note about I2P is that, while inside its network, you can only browse *.i2p websites, not normal websites or what is so-called the _clearnet_. This is unlike Tor where you can browse .onion and clearnet, which is routed through _exit relays_. You could browse the clearnet from I2P network by using a _outproxy_, which works similarly to exit relay of Tor. However, I2P user is discouraged from using a outproxy as that would compromise the user's anonymity. A thing to note about I2P is that, while inside its network, you can only browse *.i2p websites, not normal websites or what is so-called the _clearnet_. This is unlike Tor where you can browse .onion and clearnet, which is routed through _exit relays_. You could browse the clearnet from I2P network by using a _outproxy_, which works similarly to exit relay of Tor. However, I2P user is discouraged from using a outproxy as that would compromise the user's anonymity.
For this website, I2P network only applies to the traffic between visitor and my (Caddy) web server, as shown in the following diagram; a request still needs to get passed to the upstream curben.netlify.com, but Netlify only sees the request comes from my web server as if it's just a regular visitor and shouldn't know that its origin from the I2P network. For this website, I2P network only applies to the traffic between visitor and my (Caddy) web server, as shown in the following diagram; a request still needs to get passed to the upstream curben.netlify.app, but Netlify only sees the request comes from my web server as if it's just a regular visitor and shouldn't know that its origin from the I2P network.
![Architecture behind mdleom.com](20200223/caddy-nixos.png) ![Architecture behind mdleom.com](20200223/caddy-nixos.png)
@ -260,15 +260,15 @@ ggucqf2jmtfxcw7us5sts3x7u2qljseocfzlhzebfpihkyvhcqfa.b32.i2p:8081 mdleom.i2p:808
to /screenshot{1}?mobile=true to /screenshot{1}?mobile=true
} }
proxy /screenshot https://cdn.statically.io/screenshot/curben.netlify.com { proxy /screenshot https://cdn.statically.io/screenshot/curben.netlify.app {
without /screenshot without /screenshot
import removeHeaders import removeHeaders
import staticallyCfg import staticallyCfg
} }
proxy / https://curben.netlify.com { proxy / https://curben.netlify.app {
import removeHeaders import removeHeaders
header_upstream Host curben.netlify.com header_upstream Host curben.netlify.app
} }
} }
``` ```

10
source/_posts/tor-hidden-onion-nixos.md
View File

@ -11,7 +11,7 @@ tags:
- censorship - censorship
--- ---
In this segment, I show you how I set up Tor hidden (.onion) service that reverse proxy to curben.netlify.com. This website can be accessed through the following [.onion address](http://xw226dvxac7jzcpsf4xb64r4epr6o5hgn46dxlqk7gnjptakik6xnzqd.onion). In this segment, I show you how I set up Tor hidden (.onion) service that reverse proxy to curben.netlify.app. This website can be accessed through the following [.onion address](http://xw226dvxac7jzcpsf4xb64r4epr6o5hgn46dxlqk7gnjptakik6xnzqd.onion).
This post is Part 4 of a series of articles that show you how I set up Caddy, Tor hidden service and I2P Eepsite on NixOS: This post is Part 4 of a series of articles that show you how I set up Caddy, Tor hidden service and I2P Eepsite on NixOS:
@ -23,7 +23,7 @@ This post is Part 4 of a series of articles that show you how I set up Caddy, To
The main reason for me to have a Tor hidden service is so that visitor can visit my website (mdleom.com) anonymously. Visitor indeed can browse this website _somewhat_ anonymously via VPN, but it's not hidden from the VPN provider. Even with Tor, the traffic still needs to get out from the Tor network to the Internet via exit relays, and exit relays can [do whatever](https://doi.org/10.1007/978-3-319-08506-7_16) they want to the traffic. Tor hidden service ensures the traffic is end-to-end encrypted and stays inside the Tor network--without involving any exit relay. The main reason for me to have a Tor hidden service is so that visitor can visit my website (mdleom.com) anonymously. Visitor indeed can browse this website _somewhat_ anonymously via VPN, but it's not hidden from the VPN provider. Even with Tor, the traffic still needs to get out from the Tor network to the Internet via exit relays, and exit relays can [do whatever](https://doi.org/10.1007/978-3-319-08506-7_16) they want to the traffic. Tor hidden service ensures the traffic is end-to-end encrypted and stays inside the Tor network--without involving any exit relay.
Note that this only applies to the traffic between visitor and the (Caddy) web server, as shown in the following diagram; a request still needs to get passed to the upstream curben.netlify.com, but Netlify only sees the request comes from my web server as if it's just a regular visitor and shouldn't know that its origin from the Tor network. Note that this only applies to the traffic between visitor and the (Caddy) web server, as shown in the following diagram; a request still needs to get passed to the upstream curben.netlify.app, but Netlify only sees the request comes from my web server as if it's just a regular visitor and shouldn't know that its origin from the Tor network.
![Architecture behind mdleom.com](20200223/caddy-nixos.png) ![Architecture behind mdleom.com](20200223/caddy-nixos.png)
@ -235,15 +235,15 @@ xw226dvxac7jzcpsf4xb64r4epr6o5hgn46dxlqk7gnjptakik6xnzqd.onion:8080 {
to /screenshot{1}?mobile=true to /screenshot{1}?mobile=true
} }
proxy /screenshot https://cdn.statically.io/screenshot/curben.netlify.com { proxy /screenshot https://cdn.statically.io/screenshot/curben.netlify.app {
without /screenshot without /screenshot
import removeHeaders import removeHeaders
import staticallyCfg import staticallyCfg
} }
proxy / https://curben.netlify.com { proxy / https://curben.netlify.app {
import removeHeaders import removeHeaders
header_upstream Host curben.netlify.com header_upstream Host curben.netlify.app
} }
} }
``` ```