diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 6cced24..7a6dbe7 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -2,15 +2,12 @@ stages: - build - deploy -image: debian:latest +image: registry.gitlab.com/fnux/ungleich-images/staticcms-ci:latest variables: BUILDDIR: "build/" build: stage: build - before_script: - - apt-get update - - apt-get install -y make lektor imagemagick script: - make build artifacts: @@ -26,9 +23,6 @@ deploy: name: production url: https://ungleich.ch/ before_script: - # Install dependencies - - apt-get update - - apt-get install -y make openssh-client rsync # Configure the SSH Agent - eval $(ssh-agent -s) - echo "$CD_SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - > /dev/null diff --git a/Dockerfile b/Dockerfile new file mode 100644 index 0000000..ad99858 --- /dev/null +++ b/Dockerfile @@ -0,0 +1,7 @@ +# This image used for CI. + +FROM debian:latest +MAINTAINER Timothée Floure + +RUN apt-get update +RUN apt-get install -y make lektor imagemagick openssh-client rsync diff --git a/content/u/blog/DRAFT-how-to-route-ipv4-via-ipv6/contents.lr b/content/u/blog/DRAFT-how-to-route-ipv4-via-ipv6/contents.lr deleted file mode 100644 index e0a5611..0000000 --- a/content/u/blog/DRAFT-how-to-route-ipv4-via-ipv6/contents.lr +++ /dev/null @@ -1,87 +0,0 @@ -title: How to route IPv4 via IPv6 ---- -pub_date: 2019-12-10 ---- -author: ungleich network ---- -twitter_handle: ungleich ---- -_hidden: yes ---- -_discoverable: no ---- -abstract: -Bringing IPv4 into the IPv6 world ---- -body: - -Imagine the following: you are running an IPv6 only network. And now -someone asks you to pass IPv4 traffic through it, without tunneling -it. Was sounds crazy at first, is actually quite feasible. - -## A short routing recap - -Routers have routing tables. The routing tables basically say -"if you receive a packet for this host, send it to that router". - -![IP routing](/u/image/ip-routing.png) - -The important thing about this process is that the information on -where to send it to, is **not in the packet**. - -## How to send IPv4 packets via IPv6 - -Because the next hop is not written into the IPv4 packet, the router -is free to forward the packet via any method it thinks is the -best. And if that happens to be IPv6 - well, it will forward the IPv4 -packet via an IPv6 neighbour. - -## A practical example! - -``` -[root@diamond ~]# ip -6 r -::1 dev lo proto kernel metric 256 pref medium -2a0a:e5c1:137::/48 dev wgungleich proto kernel metric 256 pref medium -fe80::/64 dev wlp0s20f3 proto kernel metric 256 pref medium -[root@diamond ~]# ip r -default via 192.168.84.1 dev wlp0s20f3 proto dhcp src 192.168.84.7 metric 302 -192.168.84.0/22 dev wlp0s20f3 proto dhcp scope link src 192.168.84.7 metric 302 -[root@diamond ~]# ip route add 10.0.0.0/8 via inet6 2a0a:e5c1:137::22 -[root@diamond ~]# ip -6 route -::1 dev lo proto kernel metric 256 pref medium -2a0a:e5c1:137::/48 dev wgungleich proto kernel metric 256 pref medium -fe80::/64 dev wlp0s20f3 proto kernel metric 256 pref medium -[root@diamond ~]# ip r -default via 192.168.84.1 dev wlp0s20f3 proto dhcp src 192.168.84.7 metric 302 -10.0.0.0/8 via inet6 2a0a:e5c1:137::22 dev wgungleich -192.168.84.0/22 dev wlp0s20f3 proto dhcp scope link src 192.168.84.7 metric 302 -[root@diamond ~]# -``` - -## More in the cloud - -Actually, what happens behind the scenes is that the VM is running VNC -(we are also experimenting with XRDP), so I have actually full access -to a remote Linux desktop via browser and can even run applications -like libreoffice, blender or gimp remotely. - -Because I think it's a cool thing to have, our team at ungleich added -it as an offer to our [Black IPv6 Friday -Crowdfunding](https://swiss-crowdfunder.com/campaigns/black-ipv6-friday?locale=en). - -Below you can actually see how it looks like: - - -root@beebox ~ # route add 192.168.0.0/16 2a0a:e5c1:100::1 -add net 192.168.0.0/16: gateway 2a0a:e5c1:100::1 -root@beebox ~ # route -n get 192.168.1.2 - route to: 192.168.1.2 -destination: 192.168.0.0 - mask: 255.255.0.0 - gateway: 2a0a:e5c1:100::1 - interface: tun3 - if address: 2a0a:e5c1:11e::1 - priority: 8 (static) - flags: - use mtu expire - 2 0 0 diff --git a/content/u/blog/how-to-route-ipv4-via-ipv6/contents.lr b/content/u/blog/how-to-route-ipv4-via-ipv6/contents.lr new file mode 100644 index 0000000..98b5e76 --- /dev/null +++ b/content/u/blog/how-to-route-ipv4-via-ipv6/contents.lr @@ -0,0 +1,97 @@ +title: How to route IPv4 via IPv6 +--- +pub_date: 2020-02-10 +--- +author: ungleich network +--- +twitter_handle: ungleich +--- +_hidden: no +--- +_discoverable: yes +--- +abstract: +Bringing IPv4 into the IPv6 world +--- +body: + +Imagine the following: you are running an IPv6 only network. And now +someone asks you to pass IPv4 traffic through it, without tunneling +it. Was sounds crazy at first, is actually quite feasible. + +## A short routing recap + +Routers have routing tables. The routing tables basically say +"if you receive a packet for this host, send it to that router". + +![IP routing](/u/image/ip-routing.png) + +The important thing about this process is that the information on +where to send it to, is **not in the packet**. + +## How to send IPv4 packets via IPv6 + +Because the next hop is not written into the IPv4 packet, the router +is free to forward the packet via any method it thinks is the +best. And if that happens to be IPv6 - well, it will forward the IPv4 +packet via an IPv6 neighbour. + +## A practical example! + +In the IPv6 only coworking network in the [Digital +Chalet](/u/projects/digital-chalet/), I can add an IPv4 default route +via the IPv6 router: + +``` +[root@diamond ~]# ip route add 0/0 nexthop via inet6 fe80::21b:21ff:febb:6934 dev wlp0s20f3 +[root@diamond ~]# ip r +default via inet6 fe80::21b:21ff:febb:6934 dev wlp0s20f3 +[root@diamond ~]# +``` + +Now to be able to actually transmit IPv4 packets, I do need a source +IPv4 address. In the current network I can use an address in the +unused 10.0.8.0/22 network, however I'll add it with a /32 mask to +make it clear that there is no interface local route applied: + +``` +[root@diamond ~]# ip addr add 10.0.8.42/32 dev wlp0s20f3 +[root@diamond ~]# ip r +default via inet6 fe80::21b:21ff:febb:6934 dev wlp0s20f3 +[root@diamond ~]# ip a sh dev wlp0s20f3 +2: wlp0s20f3: mtu 1500 qdisc noqueue state UP group default qlen 1000 + link/ether 24:ee:9a:54:c3:bf brd ff:ff:ff:ff:ff:ff + inet 10.0.8.42/32 scope global wlp0s20f3 + valid_lft forever preferred_lft forever + inet6 2a0a:e5c0:0:4:c6ea:b1a8:ec14:6f35/64 scope global dynamic mngtmpaddr noprefixroute + valid_lft 86400sec preferred_lft 14400sec + inet6 fe80::3b98:cb58:ed02:c25/64 scope link + valid_lft forever preferred_lft forever +[root@diamond ~]# + +``` + +And I can indeed ping another IPv4 address, routed via IPv6! + +``` +[root@diamond ~]# ping -4 10.0.8.3 +PING 10.0.8.3 (10.0.8.3) 56(84) bytes of data. +64 bytes from 10.0.8.3: icmp_seq=1 ttl=64 time=2.37 ms +^C +--- 10.0.8.3 ping statistics --- +1 packets transmitted, 1 received, 0% packet loss, time 0ms +rtt min/avg/max/mdev = 2.365/2.365/2.365/0.000 ms +[root@diamond ~]# +``` + +## Why? + +Why would anyone want to do this? It's quite easy: with this you can +route an IPv4 address to an IPv6 only host. This enables IPv6 only +resources to create and send IPv4 packets, even if they don't have +IPv4 routes. + +## Do it yourself + +If you don't believe us that it is possible, you can test it yourself +on IPv6 only VMs on [IPv6OnlyHosting.com](https://ipv6onlyhosting.com). diff --git a/content/u/products/hosted-matrix-chat/contents.lr b/content/u/products/hosted-matrix-chat/contents.lr index cd9ce65..f0d392d 100644 --- a/content/u/products/hosted-matrix-chat/contents.lr +++ b/content/u/products/hosted-matrix-chat/contents.lr @@ -32,13 +32,13 @@ advanced user-focused features such as end-to-end encryption, bridging or audio
-
- +
+
-
+