OpenVZ and sit-tunnels (Hurricane Electric) +openvpn

OpenVZ and sit-tunnels (Hurricane Electric) +openvpn

Comments 0 kommentarer

It has come absolutely clear to me that sit-tunneling on OpenVZ is practically impossible. A technician from Hurricane Electric has rounded it up by following comment:

Ok, I’ve been handling a bunch of tickets opened by folks now trying to get OpenVZ or Virtuozzo set up. The common mistake being done is people trying to bring up the tunnel inside the virtualized server. You MUST set up the tunnel on the OS that runs the physical machine. Then you can assign IPv6 addresses to the virtualized servers from your routed allocations.

Link

And he’s definetly not joking. Setting up tunnels, based on sit is not working, regardless of the method you use. However, gre-tunneling actually seem to work with a bit of work. First of all, you have to make sure the interfaces are really available when running them on the host.

The following commands are activating both gre and sit, but with no permissions to use sit on the virtual host. To make tunneling with sit work, make sure the tunnel is added on the host, not the VPS itself. I have currently found no way of making sit work. Either I get no permission to the interface, or I get ”No buffer space available”.

Another tip that people have linked to (oh, of course, the links are dead) – is tb-tun (https://code.google.com/archive/p/tb-tun/) which is an application that allows sit to be created in a userspace (not tested).

modprobe ip_gre
modprobe ip_tunnel
modprobe sit

The next step is to activate some features for the box. This step made me activate the gre-interface and I thought I also got the sit to work. But no, that failed. Do not forget to shut down your VPS here, as the following steps requires this.

vzctl set ctid --features ipgre:on,sit:on,ipip:on,bridge:on --save
vzctl set ctid --devnodes net/tun:rw --save
vzctl set ctid --netfilter full

The last step was to set the VPS capabilities. As vzctl has the capability setting deprecated, it’s better using prlctl for this action. This was actually made in bash as there was too many row to set manually…

capabilities="net_admin net_raw sys_admin ve_admin sys_resource"
for cap in $capabilities
do
        prlctl set $ctid --capability ${cap}:on
done

If the interfaces do not show up when starting up the VPS again, you might also need to ass the devices manually.

vzctl set ctid --netdev_add gre0 --save
vzctl set ctid --netdev_add sit0 --save

In some cases you also need to use mknod to create the /dev/net/tun, that is used by the tunnel interfaces (I did this both on the host and the virtual server).

mkdir -p /dev/net
mknod /dev/net/tun c 10 200

At this moment you should be able to create both gre-tunnels and actually also use openvpn. However – still – trying to use sit, is a no go.

Får man städa sitt eget internet?

Får man städa sitt eget internet?

Comments 0 kommentarer

För några år sedan, under en tid då kedjebrev och självtester var extra populära, satt jag [som vanligt] och scrollade igenom flödet, märkbart frustrerad över mängden producerat brus. Jag började bygga ett tillägg till Chrome, som hjälpte mig att städa där ingen annan ville städa. I takt med att Facebook gjorde förändringar i sin plattform där det hände slutade saker och ting fungera. Å andra sidan gjorde det inte så mycket, eftersom plattformen samtidigt gjorde det möjligt att sålla bort mer. Bruset minskade, så att det gick att leva med det.

En dag förändrades allt. Facebook började utnyttjas politiskt. I synnerhet högerextrem propaganda blossade upp som självantänt torrt gräs. Mycket propaganda handlade förvisso om naivitet och lite samtal med personerna kunde rädda ganska mycket av situationen. På andra ställen sinade aldrig strömmen – och en del gick därtill inte att rädda heller.

Ganska nyligen vaknade därför idén med innehållsblockering till liv igen, men den moraliska klockan började samtidigt klinga högljutt. För vad händer om man har ett hjälpmedel som till synes suddar bort det man själv inte vill se? Jo, resten av världen kommer fortfarande kunna se bruset – det raderas ju nämligen inte. Du bara skyddas från att se det. Ur en moralisk aspekt är detta naturligtvis helt förkastligt, eftersom den här typen av frågor kommer stå obesvarade (även bland vänner). Färre människor kommer kunna göra motstånd och i stället tillåter vi att allvarliga problem göds och gror sig större, helt utan hejd.

Jag kan bli ganska trött i huvudet när jag ser sånt som jag inte själv kan påverka. Det innebär att jag riskerar att behöva ta längre pauser för att kunna återhämta mig igen (därmed blir alla projekt också lidande). Efter att ha sökt feedback hos diverse människor har jag insett att det för min egen del inte spelar någon som helst roll om innehållsblockering existerar. För om jag ändå tar pauser från mänskligheten ibland, skulle det betyda samma sak som om jag hade blundat och blockerat. Skillnaden är att jag i stället för att ta pauser, fortfarande kan ”hänga” med vänner. Det är alltså ganska stor sannolikhet att jag inte kommer behöva lägga ned det här, med moralisk uppgivenhet, utan snarare kommer kunna fortsätta vara självbevarande. Dessutom är jag nog inte ensam om att behöva göra så…

The ability to show progress bar of chmod/chown with pipe viewer (pv)

The ability to show progress bar of chmod/chown with pipe viewer (pv)

There’s a lots of information of how to use pv together with ”dialog” as a progress indicator for a lots of different projects. For example, even pv shows an example on how to show a progress bar for taring and gzipping a file archive. But there are almost no documents that describes a similar thing for a simple chown/chmod process. Probably, in normal cases, this is not being done since such process is fast enough to not needing it. But for larger directory structures it sometimes is nices with a progress bar, rather than the verbose output of the process.

So here’s how to do it!

   #!/bin/sh
   directory="/home/myLargeHome"
   permissions="myuser:mygroup"
   # Run chown in verbose mode, but redirect the verbosity somewhere else, while pv counts the progress.
   # pv runs in line-mode instead of byte mode.
   chown -Rv $permissions $dir | \
   pv -f -c -n -l -s $(find |wc -l) 2>&1 >/dev/null | \
   dialog --gauge 'Taking ownership of $directory' 7 70 0

Adding for example ”-i 0.1” to pv will make dialog update the view more often, but it might affect the performance of the process.

Netflix and the blocking of tunneled ipv6-routes

Netflix and the blocking of tunneled ipv6-routes

Comments 8 kommentarer

Today I discovered that Netflix started blocking tunneled ipv6-routes. This means, in SiXXS case (which I primarily use to reach ipv6 routes), that I’m for now blocked from using Netflix this way. This also means that I have a few options, to make Netflix work again, even if I run with ipv6 simultaneously:

  • Edit the hosts-file. Make a look up on netflix.com, to pick up all addresses based on ipv4. Problem: Any changes that Netflix makes, will never reach me. Besides, the streaming servers are probably named differently than only ”www.netflix.com”.
  • Disable ipv6 while watching netflix. Problem: All connectivity with ipv6 is lost while watching Transformers.

So, the real problem here is that Netflix resolves both on ipv4 and ipv6, so I need to find a DNS server that only gives me ipv4-responses, so I don’t have to guard DNS updates myself. What I did to solve this problem was, since I host my own DNS-services, therefore to set up a secondary DNS server that explicitly returns ipv4-addresses when making lookups on a ipv4-network – without the list of ipv6-addresses, like this:

v4

In the primary master server, I’ll put up a forward zone like this:

zone "netflix.com" IN {
        type forward;
        forwarders {
                10.1.1.129;
        };
};

And suddenly Netflix becomes available again, on a ipv4-only network…