20 Lines or Less #62: Browser Control, DMZ access and Port Redirection
What could you do with your code in 20 Lines or Less? That's the question I like to ask for the DevCentral community, and every time I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head.
From iRules that appeared in the illustrious Post of the Week, to users answering their own questions, this week's 20 Lines or Less offers some goodies for everyone. Three different iRules supplied by three different community members go to show just a few more things that this awesome technology can do in a short amount of space and likely time. This week we've got browser controlling, port redirection and DMZ access concerns all being addressed in less than 21 lines of code. If you're still not convinced that iRules can do some hawesome things in a small package, or if you are and are excited about learning more, read on.
Control Browser Version
During last week's Post of the Week Joe and I chatted about a request from user Kemstar wherein he was looking for a way to control which browser versions were allowed to access a particular application. We responded in the affirmative and described a bit how to do this. Not shockingly Kemstar soon whipped up his very own iRule and, with a little help from Joe, now has a functional solution to the original problem. Not only is he famous in DCLand, but his problem got solved too, how about that?
1: when HTTP_REQUEST {
2: if {not ([string tolower [HTTP::header User-Agent]] contains "msie 8.0")} {
3: HTTP::respond 200 content { sorry, but the browser is not supported. }
4: log local0. "Unhandled User Agent: [HTTP::header User-Agent]"
5: } 6: }iRule to check Datagroup for allowed servers through a default VS
User Mike posed a question last week asking if it was possible to control which DMZ servers were allowed access to a set of internal servers, based on IP address of the inbound request. The answer is yes of course, but I needn't post that to the thread, it would seem. Mike figured this out himself, and the very next day posted the solution for everyone else to benefit from as well. Thanks Mike, and way to be resourceful!
1: when CLIENT_ACCEPTED {
2: # Is client IP address defined in the FE datagroup?
3: if { [class match [IP::client_addr] equals sj01-fe-servers] }{
4: # Log the client IP address:port -> destination IP address:port
5: log local0. "admin request accepted from client: \
6: [IP::client_addr]:[TCP::client_port] -> [IP::local_addr]:[TCP::local_port]" 7: } elseif { [class match [IP::client_addr] equals sj01-strongmail-servers] }{
8: # Client IP address is defined in the strongmail datagroup
9: # Log the client IP address:port -> destination IP address:port
10: log local0. "restricted client request accepted from client: \
11: [IP::client_addr]:[TCP::client_port] -> [IP::local_addr]:[TCP::local_port]" 12: } else {
13: # Request didn't match the conditions for allowing the request
14: # Log the client IP address:port -> destination IP address:port
15: log local0. "unknown request rejected from client: \
16: [IP::client_addr]:[TCP::client_port] -> [IP::local_addr]:[TCP::local_port]" 17: drop
18: } 19: }Port Based Redirection
Regardless of what the original topic was, Nitass managed to deliver a mighty cool iRule that I figured I'd snatch up and spam out to the masses 20LoL style. This iRule acts once per connection and does a bit of magic that disables SSL for all connections, then for port 443 connections it re-enables it, and for any connection not on ports 80 or 443, it fires them off to a separate node at the originally specified port. Pretty tricky, and very cool. This one could be the basis for many a nifty functions methinks.
1: when CLIENT_ACCEPTED {
2: SSL::disable clientside
3: switch [TCP::local_port] {
4: 80 { }5: 443 { SSL::enable clientside }
6: default {
7: node 200.200.200.102 [TCP::local_port]
8: } 9: } 10: }