Archive for the ‘Linux’ tag

Using BOPM with InspIRCd  

Posted at 11:47 pm in Uncategorized

Using Blitzed Open Proxy Monitor (BOPM) with a fairly new version of InspIRCd needed a slightly different configuration than suggested here and there. The following is working for me, using InspIRCd 2.0.9 and the BOPM package provided by Ubuntu (Lucid, but shouldn’t make much of a difference).

First of all, the BOPM service wasn’t granted the proper user mode and consequently never registered the connect notifications. The InspIRCd documentation suggests that the proper modes might be set either in bopm.conf or InspIRCd’s configuration. BOPM’s documentation seems to suggest that the following is the correct config setting:

# bopm.conf
mode = "+c";

However, running BOPM in debug mode, it complained about mode c being unknown:

501 bopm c :is unknown mode char to me

This worked so much better:

# bopm.conf
mode = "+s +cC";

Now, BOPM will be notified upon every client connect, both local and remote. Next task is finding the proper regexp for detecting client connections. This is how a connect notification might look like:

*** CONNECT: Client connecting on port 6667 (class unnamed-26): ircnick!ircnick@server.example.com (192.168.200.103) [ircnick]

To catch the above notification, the following regular expression added to bopm.conf seems to work:

# bopm.conf
connregex = "\\*\\*\\* CONNECT: Client connecting on port [0-9]+.*?: ([^!]+)!([^@]+)@([^ ]+) \\(([0-9\\.]+)\\) \\[.*\\]";

Note: For some previous versions of InspIRCd, it seems the client IP is shown in brackets instead of parentheses. Also, it seems to not show the connection class. Obviously that will require a modified connregex.

For reference, this extract from inspircd.conf shows the necessary configuration on the InspIRCd side:

# inspircd.conf (or opers.conf)
<class name="BanOnly" commands="ZLINE" usermodes="s">
<type name="BOPM" classes="BanOnly" modes="+s +cC">
<oper name="bopm" password="bopmpass" host="*@localhost *@127.0.0.1" type="BOPM">

Written by bjorn on November 11th, 2012

Tagged with , , , ,

Reaching multiple instances of the same IP address  

Posted at 7:01 pm in Uncategorized

A friend recently presented me with the following challenge: Configure a system through which several appliances, all of them having an identical, non-routable, default IP configuration, can be reached simultaneously. All appliances are preconfigured with an IP address of 192.168.1.1 and they had no routing configuration enabled. Yet they should all be reachable over the Internet. The diagram below shows the basic infrastructure.

For the server (the nice grey cabinet to the left) to reach all those systems at the same time, a VLAN setup was required, so we set up a VLAN trunk to a nearby switch. Then the different appliances were connected to different un-tagged switch ports in dedicated VLANs – the first appliance was connected to a switch port in VLAN 10, the next to a switch port in VLAN 11, etc. Corresponding VLAN interfaces were configured on the server, and a local IP address was configured on each. To keep a minimum level of sanity, I configured the VLAN interface on vlan10 as 192.168.1.10, while vlan11 got 192.168.1.11, etc. To avoid too much confusion on the switch, I also set the MAC address on each VLAN interface to distinct values.

Next step was to configure correct IP routing using iproute2:
# VLAN 10
/sbin/ip link add link eth1 name eth1.10 type vlan id 10
/sbin/ip link set dev eth1.10 down
/sbin/ip link set dev eth1.10 address 00:04:de:ad:be:10
/sbin/ip link set dev eth1.10 up
/sbin/ip addr add local 192.168.1.10/24 brd 192.168.1.255 dev eth1.10
/sbin/ip route add 192.168.1.0/24 dev eth1.10 proto kernel scope link src 192.168.1.10 table 10
/sbin/ip rule add from 192.168.1.10 lookup 10 prio 1010
# VLAN 11
/sbin/ip link add link eth1 name eth1.11 type vlan id 11
/sbin/ip link set dev eth1.11 down
/sbin/ip link set dev eth1.11 address 00:04:de:ad:be:11
/sbin/ip link set dev eth1.11 up
/sbin/ip addr add local 192.168.1.11/24 brd 192.168.1.255 dev eth1.11
/sbin/ip route add 192.168.1.0/24 dev eth1.11 proto kernel scope link src 192.168.1.11 table 11
/sbin/ip rule add from 192.168.1.11 lookup 11 prio 1011

At this point I could reach the different appliances from the different source IPs:
# ping -I 192.168.1.10 192.168.1.1 -c1
PING 192.168.1.1 (192.168.1.1) from 192.168.1.10 : 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.119 ms

Snooping with tcpdump on the different VLAN interfaces, also showing the MAC addresses, confirmed that the pings were reaching the correct appliance.

Then I set up corresponding IP addresses on the outside interface (eth0). The 10.0.0.195 address matches the device in VLAN 10, 10.0.0.196 matches VLAN 11 and so on. The outside IP addresses are official IP addresses, but I’ve changed them to protect the innocent.

/sbin/ip addr add local 10.0.0.195/24 dev eth0
/sbin/ip rule add to 10.0.0.195 fwmark 10 table 10
/sbin/ip rule add fwmark 10 lookup 10
/sbin/ip addr add local 10.0.0.196/24 dev eth0
/sbin/ip rule add to 10.0.0.196 fwmark 11 table 11
/sbin/ip rule add fwmark 11 lookup 11

To make sure the packets were being identified correctly all the way through, they were tagged upon reaching the outside interface, based on the IP on which they arrived.

So far so good, now it was time for iptables to show its powers:
# VLAN 10
/sbin/iptables -t mangle -A PREROUTING -i eth0 -d 10.0.0.195 -j MARK --set-mark 10
/sbin/iptables -t nat -A PREROUTING -i eth0 -d 10.0.0.195 -j DNAT --to-destination 192.168.1.1
/sbin/iptables -A FORWARD -m mark --mark 10 -j ACCEPT
/sbin/iptables -t nat -A POSTROUTING -m mark --mark 10 -j SNAT --to-source 192.168.1.10
# VLAN 11
/sbin/iptables -t mangle -A PREROUTING -i eth0 -d 10.0.0.196 -j MARK --set-mark 11
/sbin/iptables -t nat -A PREROUTING -i eth0 -d 10.0.0.196 -j DNAT --to-destination 192.168.1.1
/sbin/iptables -A FORWARD -m mark --mark 11 -j ACCEPT
/sbin/iptables -t nat -A POSTROUTING -m mark --mark 11 -j SNAT --to-source 192.168.1.11

The above commands maps the outside addresses on eth0 to the corresponding VLANs on the inside. Note that every incoming packet is destination NATed (DNAT) to 192.168.1.1 while they are being source NATed (SNAT) based on the VLAN to which they are mapped. As the appliances were not able to route traffic, all communication had to look like it happened on the local network only.

Now I expected to be able to access each appliance from the outside, but it turned out that only one appliance could be reached. tcpdumping on each VLAN interface confirmed that traffic from the outside reached each appliance, and the appliance responded, but the response never came all the way back. This was rather puzzling as nothing appeared in any log. However, my colleagues reminded me about rp_filter, which dropped weird traffic without logging anything. Thus, the key that unlocked everything was this:
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1.10/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1.11/rp_filter

And voila – from the outside world, we were able to reach every single appliance on the inside, all with the same unroutable RFC1918 address.

Written by bjorn on February 24th, 2011

Tagged with , , , , ,

GeoIP and MySQL  

Posted at 10:16 am in Uncategorized

For my own and possibly others’ reference, these are quick notes on how to use GeoIP data from MaxMind in their new split file formats. Older tutorials describe using the GeoIP data from a time when they were one file, it seems now MaxMind have split into two files.

The files are split into Location and Blocks, so we create two tables to accommodate this:

CREATE TABLE location (
 LocId INT(8) NOT NULL,
 PRIMARY KEY (LocId),
 country CHAR(2),
 region VARCHAR(255),
 city VARCHAR(255),
 postalCode VARCHAR(255),
 latitude DECIMAL(20,17),
 longitude DECIMAL(20,17),
 metroCode VARCHAR(50),
 areaCode VARCHAR(50)
) ENGINE=INNODB;
CREATE TABLE blocks (
 startIpNum INT(10) NOT NULL,
 EndIpNum INT(10) NOT NULL,
 LocId INT(8) NOT NULL,
 FOREIGN KEY (LocID) REFERENCES location(LocId) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=INNODB;

Now it’s time to import the data from the files. Since LocId is a foreign key to the blocks table, location must be inserted first.

mysql> LOAD DATA LOCAL INFILE '/root/GeoLiteCity_20090601/GeoLiteCity-Location.csv' INTO TABLE location FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n' (LocId, country, region, city, postalCode, latitude, longitude, metroCode, areaCode);
Query OK, 248276 rows affected, 13 warnings (9.65 sec)
Records: 248277 Deleted: 0 Skipped: 1 Warnings: 9
mysql> LOAD DATA LOCAL INFILE '/root/GeoLiteCity_20090601/GeoLiteCity-Blocks.csv' INTO TABLE blocks FIELDS TERMINATED BY ',' ENCLOSED BY '"' LINES TERMINATED BY '\n' (startIpNum, EndIpNum, LocId);
Query OK, 4132041 rows affected, 65535 warnings (15 min 20.44 sec)
Records: 4132041 Deleted: 0 Skipped: 0 Warnings: 2739156

That done, we try a select.

mysql> select A.country from location A
  JOIN blocks B on A.LocId = B.LocId
  AND 404232216 >= startIpNum AND 404232216 <= EndIpNum;
+---------+
| country |
+---------+
| US      |
+---------+
1 row in set (2 min 3.58 sec)

As I had no indexes yet, the query took some time. So let’s add them:

mysql> CREATE INDEX startIp_ind ON blocks (startIpNum);
Query OK, 4132041 rows affected (9 min 22.23 sec)
Records: 4132041 Duplicates: 0 Warnings: 0
mysql> CREATE INDEX endIp_ind ON blocks (endIpNum);
Query OK, 4132041 rows affected (9 min 22.33 sec)
Records: 4132041 Duplicates: 0 Warnings: 0
mysql> CREATE INDEX LocId_ind ON location (LocId);
Query OK, 248276 rows affected (4.08 sec)
Records: 248276 Duplicates: 0 Warnings: 0

And voila:

mysql> select A.country from location A
  JOIN blocks B on A.LocId = B.LocId
  AND 404232216 >= startIpNum AND 404232216 <= EndIpNum;
+---------+
| country |
+---------+
| US      |
+---------+
1 row in set (0.55 sec)

Also, a better SQL query could’ve been more efficient, but hey – this is for illustrative purposes.

Written by bjorn on June 25th, 2009

Tagged with , , ,

Remote syslogging with OpenWRT Kamikaze 8.09  

Posted at 7:44 pm in Uncategorized

For Kamikaze 8.09 (RC1) the documentation on remote syslogging is a bit inaccurate or outdated – but this ticket pointed me in the right direction. Add the following to /etc/config/system:

log_ip 10.20.30.40

Reboot your unit and watch the logs roll in. Verify by checking what syslog is up to:

root@OpenWRT:~# ps -ef | grep syslog
87 root 1928 S syslogd -C16 -L -R 10.20.30.40

Now, that said, I also found how to set the name servers (for /etc/resolv.conf) the correct way – adding an option entry under a suitable interface definition in /etc/config/network. Note that for several DNS servers the IPs should be space separated, like this:

option ‘dns’ ‘10.0.0.1 10.0.0.2’

This creates an /etc/resolv.conf looking like this one:

nameserver 10.0.0.1
nameserver 10.0.0.2

Written by bjorn on January 12th, 2009

Tagged with , ,

VLAN woes  

Posted at 5:30 pm in Uncategorized

I’ve been planning to do this for a long time and now I’m finally there. My home network now consists of two virtual host servers (one Xen and one KVM) and a firewall between them, all nodes understanding VLANs. On top of this, add a small but powerful Linksys switch and a Linksys wireless access point running OpenWRT Kamikaze 8.09 (RC1). Among other things, this setup should facilitate testing Munin and other stuff without breaking the current functionality too much.

I got great help from this article on tweaking VLANs on the Xen host, and this article on VLANs with kvm. Thanks!

Written by bjorn on January 9th, 2009

Tagged with , , , ,