I'm very unfamiliar with Linux so forgive me if this has been answered before, I've read quite a few answers but I'm never sure if they actually relate to my question.
I have a headless raspberry pi that connects to my phone's bluetooth automatically, my phone shares its internet access by tethering. I use this initial and reliable connection to SSH to my raspberry pi, and use the desktop with VNC viewer.
I would like to connect to a WiFi network that uses a captive portal, but the browser always uses the bluetooth connection so it never redirects me to the portal page. The bluetooth connection is just to be able to use the desktop so I can get through the portal, then I would like to either disconnect bluetooth or just not use it, mainly because of the low bandwidth it provides.
I've added wlan0 as a priority interface with ifmetric, but that hasn't worked.
I was thinking that forcing all HTTP connections through the wlan0 interface could solve the problem, but there may be a simpler way, feel free to tell me.
Can you explain in "simple" terms the best way to achieve this ?
Of course, there are multiple solutions. The simplest is making sure that there is only one correct default route.
There are 3 situations:
You are only connected via bluetooth via ssh
You are connected via bluetooth and via wifi, but not yet through the splash
You are through the splash
Each will require a different network configuration.
In 1, your network config will probably be:
some IP address (let's call it IP-bt) and network mask
Default gateway is your phone
With route -n you can verify this.
In 2, the network config will depend a bit on the wifi network, but in general, your network config will be:
you'll still have IP-bt
you will have a new address on the wifi adapter (which we call IP-wifi)
the default gateway should be the gateway on the wifi network.
When you verify this with route -n, you might still see a route with destination 0.0.0.0 towards your phone. You can delete this route. Your phone should be on a directly connected network and your ssh session should therefore not break.
If the default gw is not on the wifi network, you can still remove the route that sets your phone as default gw.
Under 3, the default gw must be on the wifi network, and not on the phone. You will still be able to use your phone, because it is directly connected.
Something to watch out for in this scenario is that your phone will act as a DHCP server. That means once in a while your DHCP lease will refresh, and the bluetooth default route may re-appear. Disconnecting bluetooth will prevent this.
The second solution is to use ifmetric. Instead of making wlan0 a lower metric, make your bluetooth a higher metric. Again verify with route -n that the metrics are as you want them to be. Verify with a traceroute how the packets are moving.
A third, and most complex option would be to install Quagga and configure correct routing.
Related
I have multiple virtual machine(vmware)(linux) but would like to make one as the server, meaning all the client who wants to access the internet, uses the server internet so, the server is able to view all the incoming and outgoing data packets.
Also, I would like to install another virtual machine to act as an IDS to track the server packet, if anything is wrong it is able to flag out.
Thanks for your help in advance
You can setup one Linux server as the gateway for the others. All you need is to create two virtual ethernet interfaces for it, one in bridged mode and other in virtual network mode.
One will be bridged with your actual network and act as the WAN, and the other will be act as a LAN gateway for others VM's.
So other VM's should use your server virtual network IP address as main gateway, and you can use tcpdump or wireshard or everything you like to sniff traffic forwarded.
One thing you need to configure on the server is IP forwarding option in sysctl, which is disabled by default:
net.ipv4.ip_forward = 1
You may find more relevant information here too.
Hope it will help you.
I have very little experience on this so I am asking to see if this is even possible. I have 4 different ADSL connections that each one is connected to one access point so I have 4 total different lans. I provide free hotspot on each access point (same SSID) and the user roaming from one access point to the other as they move into the area. (The area is a long road and the distance beetween each AP is about 100m).
Anyway i saw on the modems the option for dhcp relay so I am asking this.
Can I build a central server (internet accessable) with ubuntu and dhcp server on it and setup the modems to use this as DHCP server? So the user keep the same IP as it moves from one AP to the other. All adsl modems will have the same IP so the gateway will remain same for all networks. I dont know if this is good so I am asking this question just to tell me what is the best way? To build a central server or to leave each modem act as dhcp server
Because my English are not very well I hope you understand my question
Thanks a lot!
This can be done, but I don't know if it will provide any benefit to you:
User comes online from AP1, DHCP discover is received by the modem and relayed to the DHCP server, response is sent back and the user receives and binds to IP.
User crosses the threshold and changes to AP2. Because the media has changed, the user will re-discover and perform the DHCP process again. They will most likely be allocated the same address again (presuming the lease hasn't expired or been administratively removed), but you're still re-binding the IP. Because you are re-binding the IP on the User, any open TCP connections would likely be severed.
I think that this is what you're trying to avoid by allocating the same address across all devices, but please do correct me if I'm wrong.
I have two NIC cards with 4 ports each on Redhat 6.1.
When the application comes up, it creates a bonded interface with one port from each NIC (example: eth1 and eth4), and assigns a virtual IP to that interface. Once this interface is up, all the packets from this machine should go through the bonded interface.
To achieve this currently, I'm changing the default gw device name to the bonded interface using the ip route command: ip route replace default via 10.3.2.1 dev INT-BOND.
When stopping the application, we bring down the bonded interface and change the default gw device name back to eth0.
The problem with my approach is if someone brings down the bonded interface (ifdown), then it removes the default gw.
I need confirmation that my currently working approach is fine to proceed with going forward; otherwise, should I go with modifications to the iptables/ip rules, or are there any better suggestions?
Let's say I want to make an application where stored data is encrypted so only my application is able to read it.
But I want the application to be accessed only if the user is on a particular network.
For instance the application is an Android app that deals with medical records in a hospital.
How to be sure that the device is connected to the network of the hospital ? The idea is that outside this network, the app won't work.
The question is not particularly related to wireless networks, wireless devices or Android, this is general to programming and network identification.
Could a certificate do that ? I'm new to this.
Does a network "identifier" could be faked ? For instance I'm pretty sure that a WiFi SSID is easy to fake.
Cheers.
More details:
Let's assume that the point of the local data is not for an "offline mode", but to avoid network latency. In that case, the data needs to remain accessible only if connected to a particular network, in case the device is stolen.
But if there is no way to be sure of the network's identity... What about a server that would answer to the question "Heya am I on the right network ?" and if no response comes out I know that I'm not on the right one ? (Or that the server just does not respond...) But, again, if the app is hacked, that can be faked too.
Interesting problem.
Generally speaking the purpose of storing data locally is so that it can be accessed while "offline".
However, I think there may be some underlying misconceptions here. Presumably the only reason you'd want to do this is to try and prevent a stolen device from giving up it's secrets. Fact of the matter is, you can't. If the device is no longer under your physical control then it's just a matter of time before it can be hacked.
If we are talking about sensitive data, it shouldn't be stored on the devices. Instead the device should retrieve the data it needs from your server when it needs it and delete it locally when no longer necessary.
The fact that you want the device to only work when connected to your local network implies that you can accomplish this goal.
As a side note, this is why things such as "remote wipe" exist. It's also why every time the device connects to your network it needs to test it's authentication and authorization. Point is if someone reports the device lost or stolen then you need to be able to ban it from your network AND, if the device supports this, remotely disable it.
Bearing in mind that it is entirely possible to pull a device from the network and therefore disable a remote wipe from executing.
With that out of the way, there is absolutely no way you can ensure the device is on a given network. All of that can be faked. It's kind of trivial to setup a router of a given name and change it's MAC to masquerade as whatever, and assign it certain IP addresses. For all intents and purposes it could be made to look exactly like an access point you have... And that's just with normal run of the mill wireless routers you can buy at your local computer store.
You could write your program so that the key to decrypt the data is stored on a server on the hospital network. If your program never stores the key, it makes it harder (although not impossible) for someone to access the device's data outside of the network.
As Chris pointed out a remote wipe would definitely be desirable. You could put in logic so that if the device ever attempts to read the data while not connected to the network, it wipes the data (this might lead to unintended wipes). Blacklisting is good too, so that if the device tries to reconnect to the network, you can essentially brick it. One thing that would be really bad is if you have a network outage, and all your devices accidentally get wiped.
Any network can duplicate another's SSID, so that's not reliable. You could start using a combination of SSID and a MAC address of a known router, but MAC addresses can be duplicated (although not on the same network) so that doesn't work either.
Frankly, unless the wireless network in question is using certificates to identify devices you're going to have no reliable way do it it, and even then this supposes you have a way in your application to get the certificate used the wifi network returns during network authentication.
Perhaps you could use IPSec tunnels. Many routers and firewalls support IPSec. What I'm thinking is something like this:
-----------------------------------
/ IPSec tunnel \
+---------+ \
A | IPSec | B Untrusted \
trusted network -------| capable |------- Networks ----------- Your application
| router | Internet, etc.
+---------+
The gateway router/firewall that provides access for the trusted network has an IPSec tunnel configured between itself and your application. On both the router and your application server, the tunnel looks like another network interface. A route on the router directs traffic for your application to the tunnel interface. A filter can be used on the router to ensure traffic is forwarded to the tunnel only if it arrives on interface A (i.e. the trusted network). Traffic arriving on interface B destined to your application can just be dropped by a filter on the router since it's obviously going the wrong way.
If your application binds its listening socket to just the tunnel interface, you'll know you're only accepting connections received over the tunnel.
You can use whatever combination of encryption and authentication mechanisms you want to to ensure the traffic is secure. Most IPSec implementations support just about anything you could want.
I have a black-box device with a modem attached (which I can send commands to), and would like to be able to connect to send data to a server from it. What connectivity options do I have, is PPP the protocol I need to use or is there a better option?
ppp is certainly the most common solution for getting an IP connection over a modem. There are other solutions, but there's no reason not to use PPP if what you need is an IP connection.
If you don't need an IP connection and you're writing both the client and the server, you could also do a straight serial connection from one modem to another, but that's kind of old-school.
PPP is probably your best option, if you also want an IP gateway and routing. If you only need terminal access to the device, and it runs some form of *nix, you probably have getty+serial communication as an option. You can use any number of modem terminal clients on the other side.