2015-08-26

BIND (named) server remidiation

Since I virtualised my old failing physical server into a VM, I have found it less and less easy to administer and maintain (read: configuration files).

So, I am looking and spinning up new Debian servers for more specific tasks, network services, games servers, file services etc.

The fist, and most important thing I need to migrate is DNS. That way I can have it simply running in parallel with the old, ready to essentially, stop the service (after making sure DHCP serves out this DNS IP address as well of course!).

Now, here comes the "clever" part or the goals of this approach (or so I thought):

  1. Install named.
  2. Configure it to be a slave for the existing zones
  3. re-configure it to be a master (complete with zone files)

Pretty simple right? Not so much. Well, thanks be to the 'Debian' way of doing things, it was very quick and easy to have a the zones slaved, but when I went to look at the files I was expecting, they where still empty, since I had created empty zone files to begin with.

Some poking around later and I discover that it is transferring the zones fine, but there was an issue with permissions for the zone files, or more specifically, the directory where they lived. A quick chmod -R 0777 /zone/file/directory later and a restart of the service, voila! Except.... something was not right...

The zone files seemed to be in a binary format as file would have me believe they were of type: data

I could have converted them back to plain text using the bind-tool named-compilezone(8) but, I couldn't commit my time to learning how to get the syntax correct for one small job, besides I learned that it is a crazy default in order to get a performance increase, however minuscule that would be given such a small DNS server implementation (for now).

So as per the article "Bind 9.9 – Binary DNS Slave file format" (linked above) or more authoratively as per the Chapter 6. BIND 9 Configuration Reference section of the BIND 9.9 Administrator Reference Manual (ARM) which states (incorrectly):

masterfile-format
Specifies the file format of zone files (see the section called “Additional File Formats”). The default value is text, which is the standard textual representation, except for slave zones, in which the default value is raw. Files in other formats than text are typically expected to be generated by the named-compilezone tool, or dumped by named.

So, knowing this I edited /etc/bind/named.conf.options to include the following:

masterfile-format text;

Perfect. (Just like me ;-) I now have a duplicate of the zones served on the master server, which can, and will soon be decommissioned, not to mention the new servers zones getting a makeover with many many more zones as well as a dynamic-update zone - more to come on this soon.

2015-08-05

Great Success

Finally after weeks, no months of agonising failure though trial and error, I finally managed to get the outcome I desired with my Raspberry Pi 2!



History



A few years back I acquired a Cisco 3560 and quickly realised the potential of vlans and separate subnets for the purposes of testing among other valid reasons, and came to find that the nodes on most of the vlans could not communicate with the outside world (read: internet). It was then that I realised that something was wrong...

Long story short: the Netgear DGND4000 that I own does not route/NAT anything other than its resident subnet and I sure as heck was not going to implement double NAT!




Thanks be to LIbVirt's NAT networking which gave me an interim workaround and helped confirm this.


Getting the necessary bits


NAT issues aside, I began by purchasing a second-hand Netgear DM111P v2 from some random guy on Gumtree. The ADSL Modem in itself wasn't enough because it too, seemed to suffer from the same issue as the DGND4000 did, although admittedly, I didn't put much effort into testing that theory as I wanted a solution not more testing.

I then purchased a Raspberry Pi 2 along with a bunch of accessories. In the meantime (while I was waiting the excessively long shipping time). I did some research on the distributions that are capable of running on the bcm2709-based board and decided with OpenWRT. Yes, I know that I could have used Raspbian but OpenWRT seemed the most logical choice given the fact that it is essentially an internet router anyway, just without the wireless and ADSL modem.

Turns out I made the right choice despite the fact that OpenWRT is still in trunk (RC3 at the time of writing this).

Lastly (after destroying the extremely cheap Rpi2 case) I managed to get an image booted (helps when you use the bcm2709 not the bcm2708 barrier breaker version, thats for the Raspberry Model B!).





Configuration


First of all, this would have gone a lot smother had I have just tested with the USB network adapter I bought along with the Pi, but it didn't get here in time with partial shipping.

I configured the switch with a trunk port with two vlans, one for the LAN side of things (internal link) and another for the WAN or pppoe (public/externat/internets) and set the mode appropriately.

NOTE: VLANS and IP addresses have been altered in order to not reflect my actual configuration. Call me paranoid.


Cisco 3650 partial configuration


!
vlan 20
vlan 69
!
int vlan 69
description LAN
description WAN/PPPoE
!
interface Vlan69

 ip address 192.168.69.1 255.255.255.248
!
!
interface GigabitEthernet0/15
 switchport access vlan 69
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 20,69

 switchport mode trunk
!
exit
!
ip route 0.0.0.0 0.0.0.0 192.168.69.66
!
end


OpenWRT network configuration


root@OpenWRT# vi /etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config interface 'lan'
        option proto 'static'
        option delegate '0'
        option _orig_ifname 'eth0'
        option _orig_bridge 'false'
        option ifname 'eth0.69'
        option ipaddr '192.168.69.66'
        option netmask '255.255.255.248'

config route
        option interface 'lan'
        option target '192.168.0.0'
        option netmask '255.255.0.0'
        option gateway '192.168.69.1'

config interface 'WAN'
        option proto 'pppoe'
        option ifname 'eth0.20'
        option delegate '0'
        option username 'myusername'
        option password 'mY$eCr3tP4sSw0rD'


Caveats/Adendums/Extra information


By now you may be wondering, "Why are there no IP addresses set for vlan 20"? There is no need for them! That, and the fact one might only want traffic to go via one vlan and then the other (remember, this is a router on a stick and we want to separate the vlan's into L3 traffic for one and L2 for the other).

If  were thinking "The netmask and destination network IP for the LAN route is wrong!", you would be incorrect. This is a perfectly legitimate summary route. It allows for much easier (read: slack) administration so I don't have to continually add and change multiple static routes (short of running a routing protocol) and it has the added benefit of consuming less memory and is a much better design for range of subnets that I might run on my network. Neat huh? I thought so too :-)


Conclusion


Let it be said that although this configuration is simple there where hurdles hurdles along the way. The one single most important thing that I kept getting wrong was routing. I had to remember to change the 'gateway of last resort' (Cisco's way of saying default route) on the switch so that the all subnets will route to the internet and the static (summarised) route for traffic to get back into the network from whence they came. That and trying to test this when the internet is depended upon so much by the two people in this household, was frustrating as my change windows where often short and had to be rolled back constantly.

I must say that "out-of-the-box" pppoe/nat/routing on OpenWRT worked with minimal configuration and I need to develop the scenario a little further so I can secure the connection by way of its firewall (read: iptables), but that itself is a beast I have yet to conquer.


2015-08-04

Rasbpberri Pi Internet Connectivity Lab

I have successfully built a lab for testing internet connectivity to the Raspberry Pi 2, by using my phone in a USB tethering configuration.

I followed the majority of the configuration listed in the OpenWRT wiki, except I used the LuCI web configuration instead of the final manual step of using uci to use usb0 as the WAN connection

This will now allow me to test various scenarios including multiple default routes with different metrics as well as testing firewall configurations using OpenWRT running on the Rpi2.

The one gotcha is that I forgot to set the rout back to the internal network for which was previously miss-configured.

I am getting one step closer to having much more control of my internet as well as being able to NET/Route all of my subnets!

2015-07-25

failure to focus

I have confirmed that I can get the Raspberry Pi to connect to the ISP using PPPoE through a VLAN, however, I cannot (or rather my brain cannot) get the OpenWrt to accept traffic other then ICMP to/from the device itself (I probably need to understand iptables or I am overlooking something very simple).

I'm finding it extremely hard to focus and get the networking part of this lab working right now when I don't actually have a lab to do it on and when others in the household rely on internet so much including myself, when I need to refer to something while trying to troubleshoot and find a solution to this 'router-on-a-stick' model of networking to overcome the shortfall of the existing router.

I've also lost my 4Gb micro SD for which I was planning using for building a Bluetooth (A2DP) Audio receiver from the Raspberri Pi which is making me a little less than happy considering they are not as easy to come by due to the size and I will have to spend another $10 (effectively $20 now) in order to get one.

For now, I'm going to go watch something and try again later (including looking for the SD card).

2011-11-20

Google Plus killed the technology blog

This may be the final entry in this and my other blogs.

I managed to painstakingly avoid using Facebook for many years, and instead waited patiently for Google to create it's social networking site, Google Plus (If you have never heard of Google+, I strongly urge you to go back to the rock you have so obviously been living under and/or go read some other non-technical site).

Ever since I have been active on Google+ (since soon after it's initial Beta period), have found it to be absolutely brilliant, if not addictive, and a far better medium to which I can expose my technical knowledge and findings to the masses.

This means that there is little or no time for the blog and I am almost positively confident of using one or more Google+ page(s) to replace this and most probably all of my other blogs.

Thank you Blogger for your great blogging service, but thank you so much more Google plus for finally giveing me what I (and so many other Google fans) wanted.

2011-03-10

mirgating to libata

Since IDE/MFM/RLL is now depreciated, I thought I'd share my experiences of migrating to the newer libsata (SATA prod) drivers in 2.6 kernel.

Since I only have 2 devices on IDE ports (WD 320Gb HDD and a cdrw), there was very little for me to do as I had just about everything spread across both ata and libsata, so I removed all instances of ata, set built-in ATA driver support (since the system boots from IDE - for now) under libsata and enabled what I needed as modules for my SATA JBOD's

The whole thing almost went perfectly as planned (and as documented), except for the following minor irritations:

  1. Forgot to change the real_root option in grub.conf from /dev/hda3 to /dev/sda3 :-P
  2. udev was naming my cdrom to cdrw1/cdrom1

Admittedly, it took my a while figure out that I forgot to change the bootloader for the change in device names, but I quickly worked out how to change the cdrom device name back to default, by editing "/etc/udev/rules.d/70-persistent-cd.rules"

 
Google+