I used to see Cisco's approach when configure BGP:
router bgp 64511
network 101.10.0.0 mask 255.255.255.0
...
ip route 101.10.0.0 255.255.255.0 null0
that is, I need to add the network to routing table so I can advertise it.
Now I need to configure FRR routing suite which mostly mimics the Cisco's config language, and I really doubt if I should (or shouldn't ) add the line route ... null0.
The idea behind adding the line is that Cisco used to require that, idea behind not adding is that Linux (which is underline layer) won't be happy to see extra subnet in its routing table.
Please advice!
(Sorry if I misplace the question, not aware where network questions should go to).
Any routing protocol is working this way: it is sharing routes from it's own routing table to the next hop. You don't need to add route to the Null0 (route to nowhere) if you already have it in your routing table (got it from other hop or it is configured for another interface).
Route to the Null at the example used to add it to the local routing table of the device.
BTW using route to the Null0 is good way if you want to summarize you networks and advertise only this one big network instead of lot of small networks. Routing still be working (because small network have highter priority) and if you will get packets to the host to non existing network it will just drop it by rule => Null0.
Related
In my network infrastructure I have multiple subnets intended to segregate different types of devices. I would like the ability to serve different DNS responses from different DNS servers based on the requesting subnet. For example I'd like to use Google's DNS for one subnet but say CloudFlare's anti-malware DNS for another. I would also like the ability to then further lock down by using different "address" declarations on the different subnets.
One way that some people accomplish the first part is to use the "dhcp-option" declaration to serve different server addresses to the different subnets but this kind of defeats the purpose of DNSMASQ and turns it basically into just a DHCP server and also defeats using a firewall to restrict access to port 53 to control any hard-coded dns servers.
The other option I've seen is to run 2 instances of DNSMASQ however this creates a highly customized setup which doesn't allow any of the system level configuration files or run scripts which I'd like to avoid.
So I'm hoping someone can offer a solution for this.
Thanks in advance.
Presumably you want to all of the subnets to use DNSMasq to resolve local domain names, but you want the subnets to use different recursive resolvers for Internet queries?
You should be able to do that with the DHCP settings (so that each subnet will received two DNS entries - one for DNSMasq and one for another resolver e.g. 8.8.8.8). These entries will end up in the /etc/resolv.conf for each device and will be attempted in order when the device needs to resolve DNS. If DNSMasq is set to resolve local queries only, then the device will be forced to try the second address (e.g. 8.8.8.8) to resolve Internet queries.
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.
I'm developing a proof-of-concept of some kind of transparent proxy on Linux.
Transparent proxy intercepts TCP traffic and forwards it to backend.
I use https://www.kernel.org/doc/Documentation/networking/tproxy.txt and spoofing sockets for outgoing TCP connection.
On my dev PC I was able to emulate network using Docker and all works fine.
But I need to deploy test environment on AWS.
Proposed design:
Three VMs within the same subnet:
client, 192.168.0.2
proxy, 192.168.0.3
backend, 192.168.0.4
On client I add route to 192.168.0.4 thru 192.168.0.3
On proxy I confugure TPROXY to intercept TCP packets and forward it to backend with 192.168.0.2 IP source address. Here our transparent proxy works.
On backend I run simple web server. Also I add route to 192.168.0.2 thru 192.168.0.3 otherwise packets will go back directly to 192.168.0.2
The question:
Will proposed network design work as expected?
AWS uses some kind of software defined network and I don't know will it work in the same way as I would connect 3 Linux boxes to one Ethernet switch.
Will proposed network design work as expected?
Highly unlikely.
The IP network in VPC that instances can access is, from all appearances, an IP network (Layer 3), not an Ethernet network (Layer 2), even though it's presented to the instances as though it were Ethernet.
The from/to address that is "interesting" to an Ethernet switch is the MAC address. The from/to address of interest to the EC2 network is the IP address. If you tweak your instance's IP stacks by spoofing the addresses and manipulating the route tables, the only two possible outcomes should be one of these: the packets will actually arrive at the correct instance according to the infrastructure's knowledge of where that IP address should exist... or the packets will be dropped by the network. Most likely, the latter.
There is an IP Source/Destination Check Flag on each EC2 instance that disables some of the network's built-in blocking of packets the network would otherwise have considered spoofed, but this should only apply to traffic with IP addresses outside the VPC supernet CIDR block -- the IP address of each instance is known to the infrastructure and not subject to the kind of tweaking you're contemplating.
You could conceivably build tunnels among the instances using the Generic Route Encapsulation (GRE) protocol, or OpenVPN, or some other tunneling solution, and then the instances would have additional network interfaces in different IP subnets where they could directly exchange traffic using a different subnet and rules they make up, since the network wouldn't see the addresses on the packets encapsulated in the tunnels, and wouldn't impose any restrictions on the inner payload.
Possibly related: In a certain cloud provider other than AWS, a provider with a network design that is far less sensible than VPC, I use inter-instance tunnels (built with OpenVPN) to build my own virtual private subnets that make more sense than what that other cloud provider offers, so I would say this is potentially a perfectly viable alternative -- the increased latency of my solution is sub-millisecond.
But this all assumes that you have a valid reason for choosing a solution involving packet mangling. There should be a better, more inside-the-box way of solving the exact problem you are trying to solve.
I understand that
a. one can maintain multiple routing tables in linux using "ip route ..... table "
b. forwarding decision for packets that ingress from outside network could be done using "ip rule add iif dev table "
However, if I want an user-app to talk to the outside world using specific routing table, I don't see an easy way out except to use "ip netns".
Is there a way to tell the system to use "lookup route" using specific routing table?
My understanding is "ip rules" apply only after a packet has been generated, but the user-apps consult the routing table even before the packet is generated so that ARP for the gateway can be sent.
This is a bit complicated matter. You should familiarize with SELinux labels and containers.
Docker documentation for RedHat states:
by default, docker creates a virtual ethernet card for each container. each container has its own routing tables and iptables. in addition to this, when you ask for specific ports to be forwarded, docker creates certain host iptables rules for you. the docker daemon itself does some of the proxying. the takeaway here is that if you map applications to containers, you provide flexibility to yourself by limiting network access on a per-application basis.
I want build a router to control my internet access (wlan via server).
Only a few websites (via white/blacklist) should be available at specific times.
Are there any good packages for routing/proxying web (http/s, ftp) and email (pop/imap/smtp) traffic?
What you actually need is a good Firewall. Any decent firewall should be able to filter traffic by day-of-week and time-of-day. Even many of the better SOHO routers can do this. If your router can't do this, you should use a spare PC or server to act as a gateway, run Linux or BSD on that and configure a firewall accordingly. Most Linux versions have IPTABLES which is a simple but effective firewall which will do what you want.
To make things easy, set the PC up to be the DHCP server for the network and configure it so that, when other PC's get an IP address, the gateway IP is set to the same box (you may be able to get your normal router to do this instead otherwise turn off DHCP on the router).
Ideally, if using a gateway PC, set your routers to ONLY accept traffic from that gateway - better still, turn off NAT on the router and let the gateway do it too.
Here is a fairly comprehensive "how-to".
If all of that seems too much, you should consider upgrading your router to one that does all this for you. I personally use the Billion 7800N which would probably be suitable.
If you need an HTTP proxy check out node-http-proxy. I don't know much about FTP and mail proxies though.