XNUXER.OR.ID





XNUXER


Xnuxer Research Laboratory of Internet Security and Open Source

www.xnuxer.or.id - we are concern to research technology about internet security and open source
 Address Pools And Load Balancing using OpenBSD  
An address pool is a supply of two or more addresses whose use is shared among a group of users. An address pool can be specified as the redirection address in rdr rules, as the translation address in nat rules, and as the target address in route-to, reply-to, and dup-to filter options.

There are four methods for using an address pool:

bitmask - grafts the network portion of the pool address over top of the address that is being modified (source address for nat rules, destination address for rdr rules). Example: if the address pool is 192.0.2.1/24 and the address being modified is 10.0.0.50, then the resulting address will be 192.0.2.50. If the address pool is 192.0.2.1/25 and the address being modified is 10.0.0.130, then the resulting address will be 192.0.2.2.
random - randomly selects an address from the pool.
source-hash - uses a hash of the source address to determine which address to use from the pool. This method ensures that a given source address is always mapped to the same pool address. The key that is fed to the hashing algorithm can optionally be specified after the source-hash keyword in hex format or as a string. By default, pfctl(8) will generate a random key every time the ruleset is loaded.
round-robin - loops through the address pool in sequence. This is the default method and also the only method allowed when the address pool is specified using a table.

Except for the round-robin method, the address pool must be expressed as a CIDR (Classless Inter-Domain Routing) network block. The round-robin method will accept multiple individual addresses using a list or table.

The sticky-address option can be used with the random and round-robin pool types to ensure that a particular source address is always mapped to the same redirection address.
NAT Address Pool
An address pool can be used as the translation address in nat rules. Connections will have their source address translated to an address from the pool based on the method chosen. This can be useful in situations where PF is performing NAT for a very large network. Since the number of NATed connections per translation address is limited, adding additional translation addresses will allow the NAT gateway to scale to serve a larger number of users.

In this example a pool of two addresses is being used to translate outgoing packets. For each outgoing connection PF will rotate through the addresses in a round-robin manner.

nat on $ext_if inet from any to any -> { 192.0.2.5, 192.0.2.10 }

One drawback with this method is that successive connections from the same internal address will not always be translated to the same translation address. This can cause interference, for example, when browsing websites that track user logins based on IP address. An alternate approach is to use the source-hash method so that each internal address is always translated to the same translation address. To do this, the address pool must be a CIDR network block.


nat on $ext_if inet from any to any -> 192.0.2.4/31 source-hash

This nat rule uses the address pool 192.0.2.4/31 (192.0.2.4 - 192.0.2.5) as the translation address for outgoing packets.

Each internal address will always be translated to the same translation address because of the source-hash keyword.

Load Balance Incoming Connections
Address pools can also be used to load balance incoming connections. For example, incoming web server connections can be distributed across a web server farm:

web_servers = "{ 10.0.0.10, 10.0.0.11, 10.0.0.13 }"

rdr on $ext_if proto tcp from any to any port 80 -> $web_servers \
round-robin sticky-address

Successive connections will be redirected to the web servers in a round-robin manner with connections from the same source being sent to the same web server. This "sticky connection" will exist as long as there are states that refer to this connection. Once the states expire, so will the sticky connection. Further connections from that host will be redirected to the next web server in the round robin.


Load Balance Outgoing Traffic
Address pools can be used in combination with the route-to filter option to load balance two or more Internet connections when a proper multi-path routing protocol (like BGP4) is unavailable. By using route-to with a round-robin address pool, outbound connections can be evenly distributed among multiple outbound paths.

One additional piece of information that's needed to do this is the IP address of the adjacent router on each Internet connection. This is fed to the route-to option to control the destination of outgoing packets.

The following example balances outgoing traffic across two Internet connections:

lan_net = "192.168.0.0/24"
int_if = "dc0"
ext_if1 = "fxp0"
ext_if2 = "fxp1"
ext_gw1 = "68.146.224.1"
ext_gw2 = "142.59.76.1"

pass in on $int_if route-to \
{ ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin \
from $lan_net to any keep state

The route-to option is used on traffic coming in on the internal interface to specify the outgoing network interfaces that traffic will be balanced across along with their respective gateways. Note that the route-to option must be present on each filter rule that traffic is to be balanced for. Return packets will be routed back to the same external interface that they exited (this is done by the ISPs) and will be routed back to the internal network normally.


To ensure that packets with a source address belonging to $ext_if1 are always routed to $ext_gw1 (and similarly for $ext_if2 and $ext_gw2), the following two lines should be included in the ruleset:


pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 \
to any
pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 \
to any

Finally, NAT can also be used on each outgoing interface:


nat on $ext_if1 from $lan_net to any -> ($ext_if1)
nat on $ext_if2 from $lan_net to any -> ($ext_if2)

A complete example that load balances outgoing traffic might look something like this:

lan_net = "192.168.0.0/24"
int_if = "dc0"
ext_if1 = "fxp0"
ext_if2 = "fxp1"
ext_gw1 = "68.146.224.1"
ext_gw2 = "142.59.76.1"

# nat outgoing connections on each internet interface
nat on $ext_if1 from $lan_net to any -> ($ext_if1)
nat on $ext_if2 from $lan_net to any -> ($ext_if2)

# default deny
block in from any to any
block out from any to any

# pass all outgoing packets on internal interface
pass out on $int_if from any to $lan_net
# pass in quick any packets destined for the gateway itself
pass in quick on $int_if from $lan_net to $int_if
# load balance outgoing tcp traffic from internal network.
pass in on $int_if route-to \
{ ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin \
proto tcp from $lan_net to any flags S/SA modulate state
# load balance outgoing udp and icmp traffic from internal network
pass in on $int_if route-to \
{ ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } round-robin \
proto { udp, icmp } from $lan_net to any keep state

# general "pass out" rules for external interfaces
pass out on $ext_if1 proto tcp from any to any flags S/SA modulate state
pass out on $ext_if1 proto { udp, icmp } from any to any keep state
pass out on $ext_if2 proto tcp from any to any flags S/SA modulate state
pass out on $ext_if2 proto { udp, icmp } from any to any keep state

# route packets from any IPs on $ext_if1 to $ext_gw1 and the same for
# $ext_if2 and $ext_gw2
pass out on $ext_if1 route-to ($ext_if2 $ext_gw2) from $ext_if2 to any
pass out on $ext_if2 route-to ($ext_if1 $ext_gw1) from $ext_if1 to any

How can I do equal-cost multipath routing?
Equal-cost multipath routing refers to having multiple routes in the routing table for the same network, such as the default route, 0.0.0.0/0. When the kernel is doing a route lookup to determine where to send packets destined to that network, it can choose from any of the equal-cost routes. In most scenarios, multipath routing is used to provide redundant uplink connections, e.g., redundant connections to the Internet.

The route command is used to add/change/delete routes in the routing table. The -mpath argument is used when adding multipath routes.

# route add -mpath default 10.130.128.1
# route add -mpath default 10.132.0.1


Verify the routes:

# netstat -rnf inet | grep default
default 10.130.128.1 UGS 2 134 - fxp1
default 10.132.0.1 UGS 0 172 - fxp2


In this example we can see that one default route points to 10.130.128.1 which is accessible via the fxp1 interface, and the other points to 10.132.0.1 which is accessible via fxp2.

Since the mygate(5) file does not yet support multipath default routes, the above commands should be added to the bottom of the hostname.if(5) files for the fxp1 and fxp2 interfaces. The /etc/mygate file should then be deleted.

/etc/hostname.fxp1
!route add -mpath default 10.130.128.1
/etc/hostname.fxp2
!route add -mpath default 10.132.0.1

Lastly, don't forget to activate the use of multipath routes by enabling the proper sysctl(3) variable.

# sysctl net.inet.ip.multipath=1
# sysctl net.inet6.ip6.multipath=1


Be sure to edit sysctl.conf to make the changes permanent.

Now try a traceroute to different destinations. The kernel will load balance the traffic over each multipath route.

# traceroute -n 154.11.0.4
traceroute to 154.11.0.4 (154.11.0.4), 64 hops max, 60 byte packets
1 10.130.128.1 19.337 ms 18.194 ms 18.849 ms
2 154.11.95.170 17.642 ms 18.176 ms 17.731 ms
3 154.11.5.33 110.486 ms 19.478 ms 100.949 ms
4 154.11.0.4 32.772 ms 33.534 ms 32.835 ms


# traceroute -n 154.11.0.5
traceroute to 154.11.0.5 (154.11.0.5), 64 hops max, 60 byte packets
1 10.132.0.1 14.175 ms 14.503 ms 14.58 ms
2 154.11.95.38 13.664 ms 13.962 ms 13.445 ms
3 208.38.16.151 13.964 ms 13.347 ms 13.788 ms
4 154.11.0.5 30.177 ms 30.95 ms 30.593 ms


For more information about how the route is chosen, please refer to RFC2992, "Analysis of an Equal-Cost Multi-Path Algorithm".


Please register, you are currently just a guest here.
 
Similar Articles:
  • Using IPv6 On Debian Etch
  • Ultimate Security Proxy With Tor
  • Ubuntu: Using apt-p2p For Faster Upgrades From Hardy To Intrepid
  • Howto install nginx webserver in Debian
  • GOM Player 2.0.12.3375 (.ASX File) Stack Overflow Exploit
  •  (Votes #: 5)
    Comments (2)  Print
     
     #1 Author: neverovarteom  


    Member

    Publications: 0 | Comments: 1
       
     
     #2 Author: antoshka2541  


    Member
    Здарова всем! Нашел рабочий сервис для просмотра гостей Вконтакте - http://vk-guests.com

    Publications: 0 | Comments: 88
       
     
     Information  

    Members of Guest cannot leave comments.

     

    Welcome

    Welcome to XNUXER.OR.ID, by visit our site we like to help you to get main information about internet security and opensource so dont forget to update your knowledge every time using our website.

    Archives

    To access file download or private information here you must register, please register here.

    The Best News - Top 10

    Calendar

    «    February 2012    »
     
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
     

    Site Statistics

    Top Contributors:
      1    webmaster 166


    Articles:
      This Hour: 0
      Today: 0
      This Month: 0
      All Time: 164


    Membership:
      Registered Today :18
      This Hour:1
      This Month:333
      Total:4540
      Banned:0

    Site Survey

    What do you think about our website?

    Excellent
    Good
    Fair
    Poor
    Bad

    Security Tracker

    Vuln: Pligg CMS 'status' Parameter SQL Injection Vulnerability
    Pligg CMS 'status' Parameter SQL Injection Vulnerability

    Vuln: Joomla! Multiple Information Disclosure Vulnerabilities
    Joomla! Multiple Information Disclosure Vulnerabilities

    Vuln: QEMU KVM CVE-2012-0029 Local Privilege Escalation Vulnerability
    QEMU KVM CVE-2012-0029 Local Privilege Escalation Vulnerability

    Vuln: Mozilla Firefox/SeaMonkey/Thunderbird XPConnect Security Check Cross Domain Scripting Vulnerability
    Mozilla Firefox/SeaMonkey/Thunderbird XPConnect Security Check Cross Domain Scripting Vulnerability

    Bugtraq: [ MDVSA-2012:013 ] mozilla
    [ MDVSA-2012:013 ] mozilla

    Visitor


    Translator

    Whois Info

    IP