• Poul-Henning Kamp's avatar
    ACL code rewrite: · 97178f9b
    Poul-Henning Kamp authored
    	Add IPv6 support (untested!)
    
    	Implement evil-acls
    
    IPv6 support
    ------------
    
    I have implemented IPv6 filtering support, but I have done so blindly
    as I have no IPv6 networks to test with.
    
    Please double check before relying on this to work, and please report
    your findings back to us.
    
    Syntax
    ------
    
    The ACL rules still have the same syntax, but the sematics have
    expanded to handle IPv6 also:
    
        acl foo {
    
            "foohost";              // Match, if the address is one of the 
                                    // ipv4 or ipv6 addresses of "foohost"
    
            ! "foohost";            // Fail, if...
    
            "192.168.1.7" / 24;     // Use mask for comparison:  The '7' is
                                    // ignored
    
    				// Implicit masks:
    	!"172.16";		// Fail 172.16.0.0 to 172.16.255.255
    	"10.0.0";		// Match 10.0.0.0 to 10.0.0.255
    	
    
            "www.freebsd.org" / 24; // This will give compile error, because
                                    // the "www.freebsd.org" has both ipv4 
                                    // and ipv6 addresses, and using the same
                                    // mask for both kinds do not make sense.
    
            ( ... );                // Ignore this rule if DNS lookup fails.
    
            ( ! "idiot.net" );      // If we can resolve "idiot.net", then
                                    // return Failure to match, if we see them.
        }
    
    Please notice that DNS lookup happens *only* on VCL compilation, if a
    DNS record changes you need to recompile (ie: vcl.load or vcl.inline)
    your VCL code again, it is not enough to just switch vcl (vcl.use).
    
    (This is the same as with backend DNS lookups)
    
    Evil-acls
    ---------
    
    Most firewall or ip-filtering facilities, compile the lists of
    networks and masks to a table, and matches proceed sequentially
    through that table until the table is exhausted or a match is found.
    
    Since we compile our ACLs into C-code, we might as well implement the
    "evil-acl" concept, and compile the rules directly into C-code instead.
    
    An ACL like this:
    
    	acl foo {
    		"172.16";
    		!"172.16.17";
    		"172.16.17.18";
    		"172.16"/18;
    	}
    
    Compiles to:
    
    	if (fam == 2) {
    	 if (a[0] == 172) {
              if (a[1] == 16) {
               if (a[2] == 17) {
                if (a[3] == 18) {
                 VRT_acl_log(sp, "MATCH bar " "172.16.17.18");
                 return (1);
                }
                VRT_acl_log(sp, "NEG_MATCH bar " "172.16.17");
                return (0);
               }
               else if ((a[3] & 0xc0) == 0) {
                VRT_acl_log(sp, "MATCH bar " "172.16" "/18" );
                return (1);
               }
               VRT_acl_log(sp, "MATCH bar " "172.16");
               return (1);
              }
             }
            }
    	VRT_acl_log(sp, "NO_MATCH bar");
    	return (0);
    
    As can be seen, for example the comparison with "172" is now shared
    for all four rules in the ACL, instead of being carried out once for
    each of the four rules.
    
    In addition to this optimization, the C-compiler will of course use
    its usual (and unusual) tricks to speed things up, quite likely inlining
    the ACL code in the VCL functions where they are referenced.
    
    It will also be noticed, that the compiler sorts the rules in "most
    specific order".
    
    This means that:
    		"172.16.17.18";
    gets tested before
    		!"172.16.17";
    even though it is listed later in the ACL.
    
    Previously we tested the rules in the order given.
    
    
    
    git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2995 d4fa192b-c00b-0410-8231-f00ffab90ce4
    97178f9b