NAT on Cisco. Part 2
Good afternoon again, colleagues!
I continue a series of articles about NAT on Cisco, since previous article all found some positive reviews.
In this article we will consider, as promised, inside destination NAT. Who cares - Wellcome under cat.
')
Before reading further - a disclaimer : colleagues, I understand that not everyone is exactly Cisco in general, CLI in particular, and tsiskari in particular. But let's still not throw out holivars and make the discussion more constructive, namely, to discuss specifically this article and the technology being described. Since the blog is thematic, then the article in its subject. And another request, let us, in the absence of opinions, not go beyond the framework of correctness. :) everything, sorry for the lyrical digression.
So,
In fact, a very, very exotic type of NATa, created specifically for load balancing between servers operating on the TCP protocol. In real life, occurs no more than a solar eclipse :)
Let's dive .
1. So, this broadcast works ONLY when the connection is initiated (sorry for such a word) from the outside side of the interface towards the inside of the interface and for the return traffic. But if the traffic is initiated from the inside, the broadcast will not occur.
2. This NAT works only for TCP.
Why do we need such joy ?
Suppose we have a dozen web servers that have addresses from 10.0.0.1 to 10.0.0.10. On all servers, the same site is spinning (or rather, it may just be a frontend server) and they also have one port, for simplicity, 80 (HTTP).
Clients outside are tapped to our “smeared” website at 11.1.1.1:80.
And we want to balance the load between them on the principle of RR (Round Robin), i.e. so that every next client that is accessing our router from the outside through a global address, will contact the next server in the top ten (in a circle).
This is where this tricky NAT will help.
How does it work ?
1. Live broadcast . Contrary to the logical and familiar expectations, based on the logic of inside source NAT, for this type of live broadcast is the one that is created when you turn from the outside to the inside. When TCP (and only it, I repeat) traffic appears on the outside interface, the traffic is first checked for compliance with the inside destination NAT. If it matches, the destination address is changed to the next one in the pool and the translation is recorded in the list of broadcasts. After that, a packet with an already changed destination address is routed.
___
UPD : non-TCP traffic will be directed to the first address in the pool. Thanks for the comment Ilya_Drey
2. Reverse broadcast . Again - much the opposite. Reverse translation occurs in the direction of inside-to-outside. And here, the routing first works out, if it drops traffic from inside to outside and there is a corresponding entry in the translation table - the packet is broadcast.
Remarks .
1. Unlike static inside source NAT and static inside source PAT, the router does not respond to ARP requests for the global address, unless of course this address is assigned to its interface. Therefore, you may need to add it to the interface as secondary.
2. As in the case of inside source NAT, the traffic of the router is also subject to translation, even if there is no inside interface.
3. Corollary from paragraph 2: if there are no inside-interfaces, only the traffic of the router itself is transmitted.
let's now see how it is configured .
1. So, first create a pool. Addresses in the pool - the addresses of our servers.
I specifically singled out the word rotary - for this type of NAT, the pool should be rotational (that is, we just indicate that the addresses will be taken one by one
in a circle, otherwise the next packet will be dropped after reaching the end of the pool).
2. Create an access-list that will allocate traffic to be broadcast. Specially made it advanced:
Those. We will broadcast traffic sent to our global address and even to a specific port (TCP!).
3. Create a broadcast, there are little things left:
4. And mark the interfaces (where the server is inside, where the outside world is outside)
And now, we can observe a picture of calls to our server:
we see that the same port of the global address (namely, 11.1.1.1:80) was sent to different addresses.
___
UPD : Naturally, the traffic is balanced per-session, which is necessary for the correct operation of TCP. Thanks for the comment Ilya_Drey
Remarks .
1. You can not redirect any port of the global address to other ports of servers (for example, 80y to 8080y), the ports must match. If you really need to - you can attach a loopback, broadcast it to the usual inside source static PAT with the port replaced, from there to the server using inside destination NAT. And absolutely it is impossible (the feeling that with the help of nat enable is also possible) this can be done if the same protocol on the servers is responding to different ports (somewhere 80, and somewhere 8080 for example). But if someone needs to be shot up - write, try to figure it out.
2. If two broadcasts are configured, one inside destination, as above, and the other inside source dynamic PAT for the same servers, i.e. for traffic coming from them outside, but not falling in the inverse translation (for example, for server access to repositories):
We see that they overlap, i.e. the response from the servers from port 80 must undergo a reverse translation inside the destination and a direct inside source (by the way, both of them will work only after routing). In this case, the reverse translation wins and everything will work as expected.
3. It is impossible to make static inside destination NAT. For this you need to use static inside source NAT.
In conclusion . Summing up, I want to once again note the following:
1. Inside destination NAT - address translation technology for balancing and it works only for the TCP protocol.
2. Although the interfaces are labeled the same as in the case of inside source NAT, the direction of the direct and reverse broadcast is the opposite.
3. NAT priorities (inside-to-outside and outside-to-inside) are the same as in the case of inside source NAT.
4. If the traffic is initiated in the direction of inside-to-outside, then it does not undergo broadcasting (unless you have completed the inside source NAT there).
I decided not to overload the article, so we will look at outside source NAT in the next article.
By tradition - I am open to suggestions and suggestions. While in the list saw policy-NAT.
I continue a series of articles about NAT on Cisco, since previous article all found some positive reviews.
In this article we will consider, as promised, inside destination NAT. Who cares - Wellcome under cat.
')
Before reading further - a disclaimer : colleagues, I understand that not everyone is exactly Cisco in general, CLI in particular, and tsiskari in particular. But let's still not throw out holivars and make the discussion more constructive, namely, to discuss specifically this article and the technology being described. Since the blog is thematic, then the article in its subject. And another request, let us, in the absence of opinions, not go beyond the framework of correctness. :) everything, sorry for the lyrical digression.
So,
inside destination NAT
In fact, a very, very exotic type of NATa, created specifically for load balancing between servers operating on the TCP protocol. In real life, occurs no more than a solar eclipse :)
Let's dive .
1. So, this broadcast works ONLY when the connection is initiated (sorry for such a word) from the outside side of the interface towards the inside of the interface and for the return traffic. But if the traffic is initiated from the inside, the broadcast will not occur.
2. This NAT works only for TCP.
Why do we need such joy ?
Suppose we have a dozen web servers that have addresses from 10.0.0.1 to 10.0.0.10. On all servers, the same site is spinning (or rather, it may just be a frontend server) and they also have one port, for simplicity, 80 (HTTP).
Clients outside are tapped to our “smeared” website at 11.1.1.1:80.
And we want to balance the load between them on the principle of RR (Round Robin), i.e. so that every next client that is accessing our router from the outside through a global address, will contact the next server in the top ten (in a circle).
This is where this tricky NAT will help.
How does it work ?
1. Live broadcast . Contrary to the logical and familiar expectations, based on the logic of inside source NAT, for this type of live broadcast is the one that is created when you turn from the outside to the inside. When TCP (and only it, I repeat) traffic appears on the outside interface, the traffic is first checked for compliance with the inside destination NAT. If it matches, the destination address is changed to the next one in the pool and the translation is recorded in the list of broadcasts. After that, a packet with an already changed destination address is routed.
___
UPD : non-TCP traffic will be directed to the first address in the pool. Thanks for the comment Ilya_Drey
2. Reverse broadcast . Again - much the opposite. Reverse translation occurs in the direction of inside-to-outside. And here, the routing first works out, if it drops traffic from inside to outside and there is a corresponding entry in the translation table - the packet is broadcast.
Remarks .
1. Unlike static inside source NAT and static inside source PAT, the router does not respond to ARP requests for the global address, unless of course this address is assigned to its interface. Therefore, you may need to add it to the interface as secondary.
2. As in the case of inside source NAT, the traffic of the router is also subject to translation, even if there is no inside interface.
3. Corollary from paragraph 2: if there are no inside-interfaces, only the traffic of the router itself is transmitted.
let's now see how it is configured .
1. So, first create a pool. Addresses in the pool - the addresses of our servers.
(config)# ip nat pool NAME_OF_POOL 10.0.0.1 10.0.0.10 netmask 255.255.255.0 type rotaryI specifically singled out the word rotary - for this type of NAT, the pool should be rotational (that is, we just indicate that the addresses will be taken one by one
in a circle, otherwise the next packet will be dropped after reaching the end of the pool).
2. Create an access-list that will allocate traffic to be broadcast. Specially made it advanced:
(config)# access-list 100 permit tcp any host 11.1.1.1 eq wwwThose. We will broadcast traffic sent to our global address and even to a specific port (TCP!).
3. Create a broadcast, there are little things left:
(config)# ip nat inside destination list 100 pool NAME_OF_POOL4. And mark the interfaces (where the server is inside, where the outside world is outside)
(config)# int fa0/0
(config-if)# ip nat inside
(config-if)# int fa0/1
(config-if)# ip nat outsideAnd now, we can observe a picture of calls to our server:
R3#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 11.1.1.1:80 10.0.0.1:80 11.1.1.251:18747 11.1.1.251:18747
tcp 11.1.1.1:80 10.0.0.2:80 11.1.1.250:52943 11.1.1.250:52943we see that the same port of the global address (namely, 11.1.1.1:80) was sent to different addresses.
___
UPD : Naturally, the traffic is balanced per-session, which is necessary for the correct operation of TCP. Thanks for the comment Ilya_Drey
Remarks .
1. You can not redirect any port of the global address to other ports of servers (for example, 80y to 8080y), the ports must match. If you really need to - you can attach a loopback, broadcast it to the usual inside source static PAT with the port replaced, from there to the server using inside destination NAT. And absolutely it is impossible (the feeling that with the help of nat enable is also possible) this can be done if the same protocol on the servers is responding to different ports (somewhere 80, and somewhere 8080 for example). But if someone needs to be shot up - write, try to figure it out.
2. If two broadcasts are configured, one inside destination, as above, and the other inside source dynamic PAT for the same servers, i.e. for traffic coming from them outside, but not falling in the inverse translation (for example, for server access to repositories):
ip nat inside source list 110 interface FastEthernet0/1 overload
access-list 110 permit ip 10.0.0.0 0.0.0.255 anyWe see that they overlap, i.e. the response from the servers from port 80 must undergo a reverse translation inside the destination and a direct inside source (by the way, both of them will work only after routing). In this case, the reverse translation wins and everything will work as expected.
3. It is impossible to make static inside destination NAT. For this you need to use static inside source NAT.
In conclusion . Summing up, I want to once again note the following:
1. Inside destination NAT - address translation technology for balancing and it works only for the TCP protocol.
2. Although the interfaces are labeled the same as in the case of inside source NAT, the direction of the direct and reverse broadcast is the opposite.
3. NAT priorities (inside-to-outside and outside-to-inside) are the same as in the case of inside source NAT.
4. If the traffic is initiated in the direction of inside-to-outside, then it does not undergo broadcasting (unless you have completed the inside source NAT there).
I decided not to overload the article, so we will look at outside source NAT in the next article.
By tradition - I am open to suggestions and suggestions. While in the list saw policy-NAT.
Source: https://habr.com/ru/post/108978/
All Articles