Virgin Media  DNS hijacking 

Having own DNS servers is a good practice, rather than letting your ISP to direct traffic to their liking. Virgin Media's stupid landing page for unresolved DNS was driving me nuts. Even after running my own bind9 I noticed that the DNS queries  are still being hijacked by VirginMedia and reroute via their garbage .   The simple test to prove this  is dnsleak . 

 

The ISP column will have a Virgin Media entry.

Lets see how we can work around this . 

• setup a £5/month VPS &  run bind9 on it
•  link the home gateway & VPS via wireguard  & point all DNS upstream to this VPS
  
• add iptables rule to PREROUTE   plus usual masquarding rules on wireguard interface
  

iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to 192.168.6.1:53

 

where 192.168.6.1 is the VPS  

• run dnsleak test again

 

yay ! its the cloud provider's DNS - which I dont mind. 

 

a few days later I get a letter in the post ...  

 

 According these wankers my router is "misconfigured" -  ODNSR  vulnerability my arse !

 

 

 

 

External USB disk storage for Zoneminder

Its often useful to have an external storage for ZM videos , stills and events

Create usb disk , partition & format with label ZMDATA

create a directory  /var/lib/zmdata

edit /etc/fstab and add entry :

LABEL=ZMDATA    /var/lib/zmdata    ext4    defaults    0    0

mount  the disk and create directories :

/var/lib/zmdata/zoneminder/{events,images}

edit  / create a new file  /etc/zm/conf.d/03-usbmount.conf with contents

ZM_DIR_EVENTS=/var/lib/zmdata/zoneminder/events
ZM_DIR_IMAGES=/var/lib/zmdata/zoneminder/images

set permissions,  chown -R 33.33  /var/lib/zmdata/zoneminder/

add the new storage and delete default, restart zoneminder

 

 

systemd service inside a namespace

 Network namespaces are a very versatile feature in Linux. Here we implement a service (dhclient) in an isolated namespace.

 This implementation was tested  on a NanoPi R4S - 1GB . 

 

This kit has two gigabit ethernet interfaces. eth0 is the wan interface and at startup systemd service moves this interface to red  namespace and linked by a veth pair to the main namespace.

There are three files involved in this systemd approach. Two template files and one service file.

netns@.service

This service called as netns@red.service where red is %i in the script

 

[Unit]
Description=Named network namespace %i
StopWhenUnneeded=true

[Service]
Type=oneshot
RemainAfterExit=yes
PrivateNetwork=yes

ExecStart=/sbin/ip netns add %i
ExecStart=/bin/umount /var/run/netns/%i
ExecStart=/bin/mount --bind /proc/self/ns/net /var/run/netns/%i

ExecStop=/sbin/ip netns delete %i
ExecStop=iptables -F -t nat

attach-eth0@.service

invoked as attach-eth0@red.service, (%i = red)

 

[Unit]
Description=Attach eth0 to Named network namespace %i and link with a veth pair
Requires=netns@%i.service
After=netns@%i.service
PartOf=red.service

[Service]
Type=oneshot
RemainAfterExit=yes


ExecStart=/sbin/ip link set eth0 netns %i
ExecStart=/sbin/ip netns exec %i ip l set up dev eth0
ExecStart=/sbin/ip link add veth-%i0 type veth peer name  veth-%i1
ExecStart=/sbin/ip link set veth-%i1 netns %i
ExecStart=/sbin/ip netns exec %i ip a a 192.168.99.1/24  dev veth-%i1
ExecStart=/sbin/ip a a 192.168.99.2/24  dev veth-%i0
ExecStart=/sbin/ip l s up dev veth-%i0
ExecStart=/sbin/ip r a default via 192.168.99.1  dev veth-%i0
ExecStart=/sbin/ip netns exec %i ip l set up dev veth-%i1
ExecStart=/sbin/ip netns exec %i ip l set up dev lo 
ExecStart=/sbin/ip netns exec %i iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 
ExecStart=/sbin/ip netns exec %i sysctl -w net.ipv4.ip_forward=1 
ExecStart=iptables -t nat -A POSTROUTING -o veth-%i0 -j MASQUERADE 
ExecStart=sysctl -w net.ipv4.ip_forward=1 


ExecStop=/sbin/ip netns exec red iptables -F 
ExecStop=/sbin/ip netns exec red iptables -F -t nat
ExecStop=/sbin/ip netns exec %i ip a f  dev veth-%i1 
ExecStop=/sbin/ip a f 192.168.99.2/24  dev veth-%i0
ExecStop=/sbin/ip link delete veth-%i0
ExecStop=/sbin/ip netns exec %i ip l set down dev eth0

 

the parameter PartOf ensures this service is shut off when the calling service is stopped.

 

 

red.service

[Unit]
Description=Systemd service for red namespace

# Require the network namespace is set up
Requires=netns@red.service
After=netns@red.service
JoinsNamespaceOf=netns@red.service

# Require the interface is set up
Requires=attach-eth0@red.service
After=attach-eth0@red.service

[Service]
Type=simple

PrivateNetwork=true
ExecStart=/sbin/ip netns exec red /sbin/dhclient -4 eth0



[Install]
WantedBy=multi-user.target

 when systemctl start red.service is invoked, the "Requires" stanza starts attach-eth0@red.service & netns@red.service. 

 

footnote : This method may not be very processor efficient. 

 

Rock3 - a very capable router board

This is the $35 SBC, Rock3 from Radxa. 

ROCK3 features a quad core Cortex-A55 ARM processor, 32bit 3200Mb/s LPDDR4, with a 2-lane PCI-e 3.0  m.2 M key  and and a PCI-e 2.0  E key slot,  a gig Ethernet port and a  host of other interfaces.

 

The PCI-e 3.0 , 2x port is capable of 650MB/sec write speed on a PCI 3.0 nvme device. A quick check as a nas / gitea server reveled the processor maxing out on ssh/git process, ending up around 30 MB/s write speed. Nevertheless this kit is the prime candidate for the edge router.

The second ethernet device from aliexpress will go on pci-e 3.0 interface. The initial testing using a standard RTL8111 PCI network card  sustained a throughput of 940Mbit/s.

An Atheros QCNFA222 is used as the 2.4 G access point device for initial tests. Atheros devices  always proven to be rock solid and the widest interoperabilty

Software

Radxa's kernel comes from rockchip bsp (4.19.193) - RK3568 support  has just landed upstream 5.16 - with only one dts; Hopefully the rock3 will follow soon.

The initial build is based  on  Radxa wiki . The u-boot build creates :

292864 Dec 25 19:10 idbloader.img

440768 Dec 25 19:10 rk356x_spl_loader_ddr1056_v1.06.110.bin

4194304 Dec 25 19:07 trust.img

4194304 Dec 25 19:07 uboot.img

1402368 Dec 25 19:10 u-boot.itb 

The relationship of each item is explained in this image from Rockchip :

Our boot process follows boot flow 2, hence we need to :

dd the idbloader.img to the SD card at 0x40 (seek 64)

u-boot.itb goes to 0x4000 (seek 16384)

The GPT layout of the disk starts from sector 32768 (0x8000); The u-boot environment can be squeezed at 0x6000. 

The rk36x..bin file is for the rkdeveloper tool use (maskrom mode) (top left path)

Wireguard performance:

.. and here is how good this board is .. 

 

iperf between an i7 host and this board via a gigabit lan ... 821Mbits/sec !!!!