5:30 this morning did not start to write articles, but to the West Bay mangrove connected run away toss the nearly 20 kilometers, came back after 8 points more ... After a shower, sit back and start writing a story about me.
From 2014 to 2015, I was in charge of developing a wireless security gateway, in fact, a VPN, access devices including mobile phones, xpad, boxes ... The OS for these devices is basically Linux-based Android, in addition to iOS. This gateway is generally used for a variety of applications requiring high-performance encrypted communication, before data transmission requires a relatively strong authentication, the server support 4G encryption bandwidth, support complex access control and access control, support complex QoS, in addition, You can also connect two or more VPN gateway devices to form a complex mesh hybrid topology, support network network, the function is very powerful ... This is where the ad ends.
Now let's talk about the access device, which is the client's thing.
During the development and deployment, the most headache is not the gateway side, but the access device side, that is, those Android clients.
A typical requirement is to build a sandbox for a group of apps, and the app in the sandbox walks the VPN tunnel to the gateway, while apps outside the sandbox are unaffected. For example, the traffic police use of mobile policing app is obviously to protect the data, and traffic police in the shift while bored to see Sina Weibo should not be affected, and mobile police app and Sina Weibo can not exchange visits.
...
I used to spend a lot of time explaining to my clients how "smart" Our Android client is, to ensure that data from specific and only specific apps goes into the VPN tunnel, which is actually the work of the MDM vendor, which is an added feature for my product. Therefore, in order to achieve this function, we have to constantly investigate whether a version of Android can operate the routing table in a non-root situation, operation Iptables (this is unlikely), can Nat, if possible, is not through a local monitoring agent can complete the work of diversion ... For a VPN that is implemented with a Tun network card, it's all about a need to get specific app data out of a specific route!
Unfortunately, in the previous version of Android kernel, such a simple requirement is very difficult to implement. Now the Linux 4.10 kernel has brought a new feature, that is, to configure different policy routes for different UID, which is enough to solve my problem, just about two or three years later:
ADD support for Per-uid routing. It allows the administrator to configure rules such as:
# IP rule add uidrange 100-200 Lookup 123.
This functionality have been in use by all Android devices since 5.0. It is primarily used to impose Per-app routing policies (on Android, every app have its own UID) without have to resort T o rerouting packets in iptables, which breaks getsockname () and MTU/MSS calculation, and generally disrupts end-to-end co Nnectivity
Another exciting feature is the linkage between routing and iptables.
As early as the end of 2014, I built a routing table in the OpenVPN program to prevent someone from manually adding a route so that they could access the resources that they should not have access to. Maybe you think it's good to do enough access control on the server? Yes, I also know that I am a self-styled master of OpenVPN, from the source to the configuration to optimize the refactoring, how may not know this. What excites me is that the Linux kernel finally provides a generic mechanism that does not rely on OpenVPN to implement this requirement:
Introduce an nftables RT expression for routing related data with support for nexthop (i.e. the directly connected IP addr ESS, an outgoing packet are sent to), which can being used either for matching or accounting, e.g.
# nft Add rule filter postrouting IP daddr 192.168.1.0/24 rt nexthop! = 192.168.0.1 Drop
This'll drop any traffic to 192.168.1.0/24 that's not routed via 192.168.0.1
See, this is configured using Nftables instead of iptables. This is not my nftables another point of clamor, but to express Iptables has gradually migrated to Nftables. I would have written a iptables module two years ago, but not now.
...
Now talk about my other story, you can see a lot of network technology.
There were four problems that kept me up and down for months, but fortunately, these problems were eventually solved by NetFilter:
1. Routing lookup and forwarding overhead is relatively large
At first I was using the optimized nf_conntrack to solve the problem. In general, the processing of the IP layer is shorted, using Cisco's CEF technology to isolate a forwarding post, and then save the table entry in the Conntrack key. Then I simply abandoned the conntrack, but directly using the DXRPRO structure to complete the search, see the "DXR algorithm thought as a benchmark for the design of the route positioning structure diagram."
The first reason to use conntrack is that it can efficiently locate a stream and save the flow information, while the forward item can be saved in the stream ... If there is a more efficient way than locating a stream, then there is no need for conntrack, and it turns out that I have found this more efficient way.
2. Too many filter entries, resulting in a sharp decline in packet performance
The Iptables filter was completely abandoned by me, replaced by Nf-hipac and Ipset, and later I found a better way, when I gave Conntrack in the routing lookup, I introduced it to the ACL match. Specifically, I keep the first packet ACL results of the stream in the Conntrack table entry, which is used directly behind, and no more matching is needed. Of course, my conntrack is optimized by me, not native.
bidirectional static NAT cannot be configured in 3.Linux.
About Linux NAT, which is originally stored in conntrack, only matches the first packet to the NAT rule, and then uses it for subsequent packages to be removed directly from Conntrack. So it cannot be static, nor can it be bidirectional. My approach is simply to implement a new NAT mechanism: https://github.com/marywangran/static-stateless-2-way-NAT-on-Linux-with-iptables
All of these three questions, in addition to the last one, the overall idea is to find it once, save it multiple times.
In the face of these three problems, the problem solving ideas and solutions almost occupy a lot of my blog space, I also got the company's recognition and new job opportunities. But if it stops, it's pathetic.
Network technology has been rapid development, every day there are new things out, must continue to learn to be forever recognized by the company, never lack of new opportunities.
4.Linux Bridge Problem
I clearly remember the question I was asked when I went to my last interview on March 19, 2010: Do you know anything about Linux bridge? I said to understand, so I tried to say to see ... In fact, at that time I just saw the source of the Linux bridge, fortunately, the interviewer (and later became my career to thank and never forget the mentor ...) Where the business group is not dominated by this bridge, so I also muddle through, at best at the time I also know the general principle of brdige, further things are not known.
I thought I would never get out of the Linux network from now on, but ... By the end of 2011, what I was going to do lay the course of my future.
To tell the truth, I do VPN products may include all the Linux network technology, from the bottom up to say, Pcie,msi, soft interrupt load balancing, bonding,spanning Tree,bridge call IP netfilter,ip layer netfilter, IP routing, Policy Routing, TCP distribution, tun character device, TLS encryption decryption (symmetric encryption, asymmetric encryption, abstract ...), Http,https (I tried to learn, but eventually did not learn the HTTP related application layer ...), VRRP,HSRP,OSPF ... I learned the ECC Elliptic curve algorithm and know what is called Double certificate authentication, but I think the most important thing for me is that I changed the logic of Linux Bridge in 2013, making it conform to the idea of SDN!
What? Why?
2013, SDN has been put forward for many years, but I do not know this concept, I really was in 2013 years to know the concept, as if also wrote a few soft wen (generally pretend people will write soft text), but understand the meaning of SDN in the years after.
...
I focus on SDN because I think it coincides with the idea of what I was doing at the time. I was in the network layer need a centralized control mechanism, whether it is routing policy or QoS, need to centrally control the central side, and then the policy issued to the sub-nodes, the child node has no intelligent logic, it is only blindly implement the central side of the policy issued, My approach seems to be contrary to the distributed network control mechanism, but I am tired of spanning tree,rip this uncontrollable thing, at the same time I do not like TCP, do not like blockchain, I need to find a theoretical backing to support my authoritarian centralized control mechanism, and then on the way to work on the day, I use mobile phone to see the technical website, found the concept of SDN ...
What does this have to do with bridge?
I was hoping that packets would bypass IP routing and directly implement a centralized VPN policy that would include not only routing but also many others, such as two-layer or three-tier routing. So I need to customize a matching chain, each packet to match the matching chain, once hit to execute the match indicates the action, similar to iptables. However, the Conntrack connection tracking was borrowed directly. So the matching chain can be directly used Conntrack itself, and then add an action field in the Conntrack item, the packet enters the kernel stack will be unconditionally associated with a Conntrack table entry, and then directly perform the action indicated by the Conntrack table entry.
But as you know, Nf_conntrack is at the prerouting point, which is already on the IP layer. What I want is to make a match on the bridge layer, and then decide whether the direct bridge layer is forwarded or broute to the IP layer based on the action of the matching Conntrack table entry. Fortunately, the Linux Bridge has a call IP netfilter mechanism (see/proc/sys/net/bridge/bridge-nf-call-iptables), just what I mean! But the call point was executed after deciding whether or not to redirect, so I had to reverse the position of the two, and see the design questions about Bridge-nf-call-iptables.
In my design, the system's IP routing mechanism is almost useless. The child node VPN daemon receives the forwarding policy from the central node and injects it into the Conntrack table entry, which is then ready for packet forwarding. My programming is not good, but I have a good understanding of the Linux kernel stack process, so I can make use of all ready-made things, small repairs can meet my needs, I borrowed conntrack, I borrowed bridge-nf-call-iptables ...
At that time I do not know OvS (ie, openvswitch), if you know that there is such a thing, I even conntrack,bridge do not need to take a closer look, OvS realize my above demand, is not very direct? Essentially, OvS is the enhanced version of Linux Bridge, which previously required you to move back and forward the functions are now integrated in the OvS interior. OvS inside there is a flow table, but also multi-level, you can receive the SDN controller injected flow table entries, everything is already standardized, ready-made things are also many. If I had known a OvS a few years earlier, it would have been much less work.
I have not mentioned Vxlan, nor mention Lisp, in fact, they are essentially building a sophomore layer of technology, I do things casually, advocating grassroots wind, with OpenVPN set up a sophomore layer, covered in the Shanghai city of a city area network, this is overlay ...
As for NFV, it's just a noun. I miss my that spent countless days and nights made of things, it contains too many things, if mastered it, you also mastered the core of the network technology, in the development period, contact with a variety of Linux kernel network things, during the deployment, fortunately with ccnp/ie all kinds of confrontation, Master the core network of many things, even on the road of delivery, late at night on the way home, will suddenly come out a lot of ideas ... The story is not finished yet, but I don't want to talk about it any more. For the manager who gave me the opportunity to do this, thank you, but thanks!
Here's what to say about BGP and DCI ... If there is time tomorrow.
Two new features in Linux 4.10 A story with Me
