* The connection is encrypted and controlled by us until it gets on the ibbt server. After that it's public and goes over the network of ibbt/belnet.

+

* There is no anonymity implied, public ip will be linked to our vps, the reverse dns even works.

+

* Remember to switch off your P2P software because the traffic patterns won't disclose the fact that it's just linux iso's. Also if you want to connect it's your duty to verify your machine isn't r00ted.

+

* IBBT T&A: if they receive a complaint, they will shut the server down. I expect no problems here but please be conscious about it and think of your fellow members ;-)

* Direct line onto the local 0x20 network , troll ppl by playing bad music, cause seizures by manipulating the lights, play with local services.

+

+

== Setup ==

+

An OpenVPN server on members.0x20.be, connected to Belnet, hosted by IBBT. There is also a p2p tunnel to the space to provide connectivity to the 0x20 internal network. Authentication is done with SSL client certificates based on a [[CA|0x20 CA]]. All client certificates signed by the 0x20 CA and with an 'OU=members' are allowed to connect. Future access can be denied by revoking the client certificate and updating the CRL (Certificate Revocation List).

+

+

See below for the steps to connect to the VPN server. Further below is the documentation of the server configurations.

The connection is encrypted and controlled by us until it gets on the ibbt server. After that it's public and goes over the network of ibbt/belnet.

There is no anonymity implied, public ip will be linked to our vps, the reverse dns even works.

Remember to switch off your P2P software because the traffic patterns won't disclose the fact that it's just linux iso's. Also if you want to connect it's your duty to verify your machine isn't r00ted.

IBBT T&A: if they receive a complaint, they will shut the server down. I expect no problems here but please be conscious about it and think of your fellow members ;-)

An OpenVPN server on members.0x20.be, connected to Belnet, hosted by IBBT. There is also a p2p tunnel to the space to provide connectivity to the 0x20 internal network. Authentication is done with SSL client certificates based on a 0x20 CA. All client certificates signed by the 0x20 CA and with an 'OU=members' are allowed to connect. Future access can be denied by revoking the client certificate and updating the CRL (Certificate Revocation List).

See below for the steps to connect to the VPN server. Further below is the documentation of the server configurations.

#!/bin/sh
#
# openvpn-tap-up-down.sh
#
#
# A script to be used as an OpenVPN bridged (tap) up/down script on Mac OS X
# - uses ipconfig to acquire a DHCP lease via the OpenVPN tap interface, and scutil to
# incorporate the DHCP-supplied DNS configuration
#
# Use in your OpenVPN config file as follows:
#
# up openvpn-tap-up-down.sh
#
# - up: openvpn calls the 'up' script after the tun/tap interface is created, but before the link
# to the server is available for use (ditto 'up-delay' at least for UDP)
# - on testing w/ openvpn 2.0.5, and tcpdump on the tap interface as soon as it comes up,
# packets are queued up on the interface (and not actually sent over the openvpn tunnel)
# until *after* this script returns; this makes sense: this script could fail in which
# case the connection is invalid
# - this means the DHCP acquisition can't complete until after this script exits
# - that's not directly a problem as the OS X DHCP client should do everything we need
# to make the interface functional, all by itself - *except* for one small thing: as of
# OS X 10.4.7 the DHCP-acquired DNS information is not "merged" into the System
# Configuration (OS X bug?)
# - thus we have a chicken-and-egg situation: we need to manually fixup the DNS config,
# but can't until we get the DHCP lease; we won't get the lease until we this script exits
# - the solution is to spawn a little "helper" that waits until the lease is acquired,
# and then does the DNS fixup
#
# - down: the only sensible 'down' action is to release the DHCP lease (as a courtesy to the
# DHCP server), alas it's too late to do this *after* the connection has been shutdown (as
# of OpenVPN 2.0 there's no "pre-disconnect" script option; note that both 'down' and
# 'down-pre' are called only after the connection to the server is closed ('down-pre' before
# closing the tun/tap device, 'down' after)
# - OS X automatically cleans up the System Config keys created from ipconfig, but we need to
# manually remove the DNS fixup
#
# 2006-09-21 Ben Low original
#
if [ -z "$dev" ]; then echo "$0: \$dev not defined, exiting"; exit 1; fi
# relevant script_type values are 'up' or 'down'
case "$script_type" in
up)
# bring the interface up and set it to DHCP
# - System Configuration dynamic store will be automatically updated, with the
# State:/Network/Service/DHCP-tap0
# data store created.
# - the ipconfig man page notes that it should only be used for "test and debug" purposes,
# and that you're supposed to use the SystemConfiguration APIs to manipulate the network
# configuration
# - alas, there appears to be no CLI utility other than ipconfig
/usr/sbin/ipconfig set "$dev" DHCP
# spawn our little DNS-fixerupper
{
# whilst ipconfig will have created the neccessary Network Service keys, the DNS
# settings won't actually be used by OS X unless the SupplementalMatchDomains key
# is added
# ref. <http://lists.apple.com/archives/Macnetworkprog/2005/Jun/msg00011.html>
# - is there a way to extract the domains from the SC dictionary and re-insert
# as SupplementalMatchDomains? i.e. not requiring the ipconfig domain_name call?
# - wait until we get a lease before extracting the DNS domain name and merging into SC
# - despite it's name, ipconfig waitall doesn't (but maybe one day it will :-)
/usr/sbin/ipconfig waitall
# usually takes at least a few seconds to get a DHCP lease
sleep 3
n=0
while [ -z "$domain_name" -a $n -lt 5 ]
do
sleep $n
n=`expr $n + 1`
domain_name=`/usr/sbin/ipconfig getoption $dev domain_name 2>/dev/null`
done
if [ "$domain_name" ]; then
/usr/sbin/scutil <<EOF
d.init
get State:/Network/Service/DHCP-$dev/DNS
d.add SupplementalMatchDomains * $domain_name
set State:/Network/Service/DHCP-$dev/DNS
EOF
fi
} &
;;
down)
# for completeness...
if [ `/usr/bin/id -u` -eq 0 ]; then
/usr/sbin/ipconfig set "$dev" NONE
fi
;;
*) echo "$0: invalid script_type" && exit 1 ;;
esac
##### FIN

#!/usr/bin/perl
# verify-cn -- a sample OpenVPN tls-verify script
#
# Return 0 if cn matches the common name component of
# X509_NAME_oneline, 1 otherwise.
#
# For example in OpenVPN, you could use the directive:
#
# tls-verify "./verify-cn Test-Client"
#
# This would cause the connection to be dropped unless
# the client common name is "Test-Client"
die "usage: verify-cn cn certificate_depth X509_NAME_oneline" if (@ARGV != 3);
# Parse out arguments:
# ou -- The common name which the client is required to have,
# taken from the argument to the tls-verify directive
# in the OpenVPN config file.
# depth -- The current certificate chain depth. In a typical
# bi-level chain, the root certificate will be at level
# 1 and the client certificate will be at level 0.
# This script will be called separately for each level.
# x509 -- the X509 subject string as extracted by OpenVPN from
# the client's provided certificate.
($ou, $depth, $x509) = @ARGV;
if ($depth == 0) {
# If depth is zero, we know that this is the final
# certificate in the chain (i.e. the client certificate),
# and the one we are interested in examining.
# If so, parse out the common name substring in
# the X509 subject string.
if ($x509 =~ /\/OU=([^\/]+)/) {
# Accept the connection if the X509 common name
# string matches the passed cn argument.
if ($ou eq $1) {
exit 0;
}
}
# Authentication failed -- Either we could not parse
# the X509 subject string, or the common name in the
# subject string didn't match the passed cn argument.
exit 1;
}
# If depth is nonzero, tell OpenVPN to continue processing
# the certificate chain.
exit 0;