sown / tasks

Tasks for sown projects
0 stars 0 forks source link

Investigate weirdness with 10.5.0.212 IP address #85

Closed drn05r closed 2 years ago

drn05r commented 2 years ago

When login.sown.org.uk was offline it was still possible to SSH to 10.5.0.212. This suggests some other device is also on this IP address. We need to investigate what this is.

drn05r commented 2 years ago

ssh -v 10.5.0.212 suggests it is a Raspberry Pi:

debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Raspbian-10+deb9u4 debug1: match: OpenSSH_7.4p1 Raspbian-10+deb9u4 pat OpenSSH* compat 0x04000000 Raspbian / Debian 10 is Buster.

drn05r commented 2 years ago

According to @cjsoftuk this is a Wireless Quality Monitoring (WQM) box sat on @heliosfa desk. I am going to check the DNS to see if it is registered, otherwise I will add it. Either way I will move login to a new private IP address.

drn05r commented 2 years ago

This is rather odd there is staff-wqm looks to be on 10.5.0.250 and student-wqm is on 10.5.0.251. Based on a matching ECDSA key fingerprint it looks like student-wqm is also on 10.5.0.212 for some reason.

TimStallard commented 2 years ago

I think the WQMs were renumbered a while ago when we changed how our IP space was split up - maybe it retained the old IP as well?

drn05r commented 2 years ago

I have done the following:

  1. Added STUDENT-WQM and STAFF-WQM to netbox with appropriate interfaces and IP addresses (inc. 10.5.0.212) for STUDENT-WQM (assign hostname student-wqm-alt for now).
  2. Updated netbox nftables.conf and bird.conf to update addresses and routing for login. For ntftables.conf and bird.conf, I have committed this changes to their gits so they can be deployed on both gateways. I have reloaded nftables and bird on both gateway servers.
  3. Added LOGIN to auth2 admin site for consistency. Added virtual interface with hostnane student-wqm-alt and IP 10.5.0.212 to STUDENT-WQM. Everything now looks to be working as expected.
drn05r commented 2 years ago

I don't know how easy it will be for @heliosfa to sort out the errant 10.5.0.212 IP registration on STUDENT-WQM. Therefore better to reassign login. I did not want to use 10.5.0.211 or 10.5.0.210, as arp on auth2 suggested these may be in use.

heliosfa commented 2 years ago

I'm not sure if I have login to them but happy to give both of the WQMs a reboot when I am in.

There is also the Odroid that we were using for something - is that registered in all the right places?

drn05r commented 2 years ago

@heliosfa That may be useful at clearing the rogue IP address on student-wqm. It would be useful to get that cleared. Also trying to work out why arp -a on auth2 is reporting part records for the following:

? (10.5.0.210) at <incomplete> on eth1 ? (10.5.0.211) at <incomplete> on eth1

heliosfa commented 2 years ago

210 rings a bell as being the odroid.

Did the other WQM used to be 11?

drn05r commented 2 years ago

@helios Neither is pingable as you expect from that result from arp. It would make sense that are odroid and staff-wqm, as they are still contiguous now they have been moved. I assume they must sometimes respond as I rebooted auth2 earlier today, so I would only expect results from arp -a since the server was rebooted. I guess a reboot on all three of these devices might help.

trickeydan commented 2 years ago

This is all quite interesting given that I pinged and arped for the IP before assigning it to LOGIN initially.

drn05r commented 2 years ago

@heliosfa That may be useful at clearing the rogue IP address on student-wqm. It would be useful to get that cleared. Also trying to work out why arp -a on auth2 is reporting part records for the following:

? (10.5.0.210) at <incomplete> on eth1 ? (10.5.0.211) at <incomplete> on eth1

These I reckon might be as a result of me trying to ping IP addresses to test if they were in use. Therefore, the main concern is just 10.5.0.212. As you can see the ARP entry below has a MAC address rather than saying incomplete:

? (10.5.0.212) at b8:27:eb:d3:0c:43 [ether] on eth1