dan
/
docs
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

some last guides from 2005

This commit is contained in:
Dan Ballard 2016-01-04 17:22:13 -08:00
parent 019beece8e
commit b72f49b030
2 changed files with 284 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

159
mindstab.net_blog/2005-09-23-openvpn-on-gentoo-and-openbsd.md Normal file
View File

@ -0,0 +1,159 @@
# OpenVPN on Gentoo and OpenBSD #
*Sep 23, 2005*
Well, in the name of helping add to the wonderful and useful infrastructure this city is building of unsecured wifi access points I've not been wanting to use WEP or anything. How ever I've been concerned about the easy access to my network. So I finally popped another ethernet card into Janus my firewall and routed the wifi box through that. Voila, segregated wireless. But now my laptop Nika wasn't on my network and couldn't share files easily etc.
So the solution was to create a VPN. I'd been wanting to do this already so I could use it from remotely, but now I finally had some really good motivation.
So, to start, I pkg_add openvpn with OpenBSD on Janus and emerge openvpn on my laptop Nika. Portage notified my that the 2.x series won't work with the 1.x series that OpenBSD 3.7 has. So I pkg_delete ed that and downloaded and installed a fresh version on Janus from the openvpn site. One hitch, had to ./compile with `--with-lzo-headers=/usr/local/include --with-lzo-lib=/usr/local/lib`.
Then came the fun of configuring them and using SSL/TLS. Useful reference in vague order are:
* [Official OpenVPN 2.x HowTo](http://openvpn.net/howto.html)
* [VPN Guide on Gentoo Wiki](http://gentoo-wiki.com/HOWTO_Road_Warriors_with_OpenVPN)
* [OpenBSD networking tutorial: Networking, Bridging, and OpenVPN](http://www50.brinkster.com/dachee/)
* [OpenVPN 2.x on OpenBSD](http://blog.innerewut.de/articles/2005/07/04/openvpn-2-0-on-openbsd)
A couple points were that while syntax like
dev tap
worked on Linux, you needed
dev-type tap
dev tun0
on OpenBSD
Only the instructions in the official OpenVPN guide that told you to use the easy-rsa directory and tools that openvpn supplies worked for generating SSL certs and stuff that didn't cause connection errors.
Also, when as a client, and using the remote server name.com, you can also add the 'float' command so that the client will accept packets from other IPs (in my case I specify Janus.mindstab.net so it will resolve from any where on the internet, but when I'm at home it resolves to a private network address).
OpenBSD bridging is pretty easy
# cat /etc/bridgename.bridge0
add vr0
add tun0
up
# cat /etc/hostname.tun0
link0 up
Then I added some rules to pf so as to segregate my wireless network and allow the vpn to work.
The relevant parts of my 'pf.conf' are below:
ext_if="vr0"
int_if="vr1"
wi_if="xl0"
vpn_if="tun0"
int="192.168.1.0/24"
wi="192.168.2.0/24"
vpn="192.168.3.0/24"
inferno="192.168.1.2/32"
scrub in all
nat on vr0 from $int to any -> (vr0)
nat on vr0 from $wi to any -> (vr0)
# FTP proxy
rdr on $int_if proto tcp from any to $ext_if port 21 -> 127.0.0.1 port 8021
rdr on $wi_if proto tcp from any to $ext_if port 21 -> 127.0.0.1 port 8021
rdr on $vpn_if proto tcp from any to $ext_if port 21 -> 127.0.0.1 port 8021
# VNC
rdr on $ext_if proto tcp from any to (vr0) port 5900 -> $inferno
# BitTorrent
rdr on $ext_if proto tcp from any to (vr0) port 6881 -> $inferno
# for active mode FTP connections
pass in on $ext_if inet proto tcp from port 20 to ($ext_if) user proxy flags S/SA keep state
antispoof quick for $int_if inet
antispoof quick for $wi_if inet
antispoof quick for $vpn_if inet
# segregate wireless (making it dmz ish)
block in on $wi_if from any to $int_if
block in on $int_if from any to $wi
block in on $vpn_if from any to $wi
# secure janus
block in on $wi_if from any to 192.168.2.1
pass in on $wi_if proto udp from any to $wi_if port 1194
# don't really need since vpn is working
#pass in on $wi_if proto tcp from any to $wi_if port ssh
#pass in on $wi_if proto udp from any to $wi_if port ssh
...
My server's OpenVPN 'local.conf':
dev-type tap
dev tun0
server 192.168.3.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/mindstab/ip_pool
mode server
status /var/log/openvpn-status.log
# extra auth channel encryption. One of the non official
# tutorials first showed me how to nicely set this up
tls-auth /etc/openvpn/mindstab/mindstab-key.txt 0
keepalive 10 30
client-to-client
#max-clients 150
verb 3
tls-server
dh /etc/openvpn/mindstab/dh1024.pem
ca /etc/openvpn/mindstab/ca.crt
cert /etc/openvpn/mindstab/server.crt
key /etc/openvpn/mindstab/server.key
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
And the laptop's client's OpenVPN 'local.conf':
#float allows openvpn to accept packets from
#ips that aren't what the remote line resolves to
float
remote janus.mindstab.net
dev tap
client
resolv-retry infinite
mute-replay-warnings
verb 3
persist-tun
persist-key
tls-auth /etc/openvpn/mindstab/mindstab-key.txt 1
tls-client
ca /etc/openvpn/mindstab/ca.crt
cert /etc/openvpn/mindstab/nika.crt
key /etc/openvpn/mindstab/nika.key
comp-lzo
# adds a route to the routing table while
# this vpn is active
# in this case any request for my home network
# are routed through this vpn
route 192.168.1.0 255.255.255.0
And that's about it. A day's work. Really. Follow the first guide, it'll save you a lot of time and problems. the others all just didn't work for me.
Once you're ready, it's just `/etc/init.d/openvpn start` on Gentoo, and `rc-update add openvpn default` if you're confident. For testing just run `openvpn --config local.conf`.
On OpenBSD for persistance, add `/usr/local/sbin/openvpn --daemon openvpn --writepid /var/run/openvpn.pid --config /etc/openvpn/mindstab/local.conf` to your '/etc/rc.local'.
Now weather I'm at home or school I can just open my ssh mount and browse Inferno (my desktop) for files.

125
mindstab.net_blog/2005-10-16-starcraft-in-qemu-on-linux.md Normal file
View File

@ -0,0 +1,125 @@
# Starcraft in QEmu on Linux #
*Oct 16, 2005*
So I've finally got Starcraft LAN party and battle.net worthy without giving up Linux. What a journey.
So, to start with grab a fresh copy of Qemu, I have 0.7.2, and KQemu.
With recent kernels (2.6.13.2) I've found that the /dev/kqemu device isn't created when the kqemu module is loaded. This will probably be fixed in the next release but in the mean time create:
**mk_kqemu_node.sh**
#!/bin/sh
modprobe kqemu
mknod /dev/kqemu c 250 0
Once that's done Qemu should work with the accelerator. It runs at quite acceptable speeds. Then throw on your favorite windows version in QEmu. I find windows 98 is a nice and small installation, perfect for Starcraft.
~/qemu $ qemu-image create hd/win98.img 1G
~/qemu $ qemu -hda hd/win98.img -cdrom cd/win98.iso -boot d
That should be all you need to get windows up and running.
Next install Starcraft.
# Starcraft Install
~/qemu $ qemu -hda hd/win98.img -cdrom /dev/cdrom0
# Broodwars Install
~/qemu $ qemu -hda hd/win98.img -cdrom cd/broodwars.iso
It is a great idea to rip the broodwars cd so you can just use the image and never have to carry the cd around with you. Qemu won't care and windows won't know.
Also, you can run qemu with ` -monitor stdio` to get a qemu command prompt in the terminal. From there you can unmount cds and remount new ones while the system is running. Very handy.
eject cdrom
change cdrom /dev/cdrom
Now the easy part is done. Starcraft should run in qemu and you should be able to play single player, and connect to battle.net and get upgrades, but not play online. This is because the default qemu networking is good for making requests but doesn't accept incoming connections. So we have to make qemu use it's tun device support, create a virtual network between qemu and our computer, and then bridge that network to the real one.
the tools you need are:
* kernel with tun/tap device support
* kernel with bridge support
* bridge tools supplying the 'brctl' command
Equipped with these you can write simple shell scripts (my approach) or more flexible scripts (for another day). I just took the instructions I found and put them in a script for quick use. Still have to edit it for each different network for now but it shouldn't be too hard to extend.
(Note: I had issues with using this setup with wireless devices. You may too. If you have a choice, go wired. Might make it work.)
**qemu-bridge.sh**
#!/bin/sh
# The network interface
IF=eth0
# Our computers desired IP address on the network
IP=90.0.0.193
BROADCAST=90.0.0.255
GATEWAY=90.0.0.254
ifconfig $IF down
echo "Creating bridge..."
brctl addbr br0
ifconfig $IF 0.0.0.0 promisc up
ifconfig tun0 0.0.0.0 promisc up
#echo "Bringing up br0 (dhcpcd)..."
#dhcpcd br0
echo "Bringing up br0 ($IP)..."
ifconfig br0 $IP netmask 255.255.255.0 broadcast $BROADCAST up
echo "Configuring bridge..."
brctl stp br0 off
brctl setfd br0 1
brctl sethello br0 1
brctl addif br0 $IF
brctl addif br0 tun0
route add default gw $GATEWAY
**qemu-cleanup.sh**
#!/bin/sh
IF=eth0
ifconfig br0 down
ifconfig tun0 down
ifconfig $IF down
brctl delbr br0
Also, for qemu to actually know there is a tun device to use, you also need to create:
**/etc/qemu-ifup**
#!/bin/sh
sudo /sbin/ifconfig $1
Which can be tweaked a bit. I've been running qemu as root so you wouldn't need the sudo front to the ifconfig command, however I may not need to be running as root.
Anyways, to get this to all work, you have to launch qemu in one console first. Qemu creates the tun device you'll be using so every time you launch qemu you need to run the bridge script and every time it exits you need to run the cleanup script. So in one terminal run something like:
qemu -monitor stdio -hda hd/win98.img -cdrom cd/broodwars.iso -enable-audio
Then in a separate console run the `qemu-bridge.sh` once you have it configured to your surroundings. You may need to make windows renew it's IP if you are using dhcp. With windows 98 go to start->run 'winipcfg' and select the network adapter and click 'renew' to get windows to aquire an address on the physical network.
Then, ideally you should be all done, and ready to play Starcraft on battle.net or at a LAN party. Good luck!
### Update 2005.11.09 ###
Qemu uses a sound blaster card of somesort that does also not seem to be plug and play. So to get it to be detected you have to go into add/remove hardware and have it search, and when that fails, have it do the long search for non plug and play hard ware. It should then detect the sound blaster and request the windows cd.
That was pretty much all it took for me. QEmu seems to still use OSS and /dev/dsp, so you may have issues related to that, but it can work.
### Update 2006.06.11 ###
Well, with Qemu 0.8.0 out for a while I decided to finally get my networked starcraft working with it. There were several changes but it’s not too bad.
The first simple easy change to take note of is that the ‘-enable-audio’ flag no longer works. They have added support for several sound cards of which you have to pick one. If you want to maintain the Soundblaster you previously had working you should now use ‘-soundhw sb16’. However if this is a fresh install you may find that one of the other drivers ‘-soundhw adlib’ or ‘-soundhw es1370’ work better for you or you could use the ‘-soundhw all’ option and have QEmu emulate them all and let Windows pick what it likes best.
There are some networking changes that I will outline here.
* QEmu now uses a tap device instead of a tun device so go through bridge.sh and cleanup.sh and change all references to ‘tun0’ to ‘tap0’.
* The QEmu command line options for network configuration are now more powerful so you can delete ‘/etc/qemu-ifup’ since it is no longer required. Instead, when you are starting QEmu for Starcraft on the network use ‘-net nic,vlan=0 -net tap,vlan=0,ifname=tap0’.
And that’s it. Now you are good to play networked starcraft in QEmu 0.8.0 on Linux.