Pluto中的路由和erouting机制

做Strongswan测试的时候，我发现strongswan不能为同一个目的网络建立起多条隧道，百思不得其解，最后在pluto的man手册里找到了答案，里面郑重声明pluto不支持相同目标网络而不同隧道，即使是拥有不同的IP或设备接口。但同样使用pluto做IKE daemon的openswan对待这种情况的政策却比较宽松，在其比较靠后的版本里，默认支持不同设备+IP到同一目标网络（通常配置为rightsubnet）的多条隧道。Pluto 的路由策略都在两者的codebase中指定，路径为：/openswan-x.x.x/programs/pluto/kernel.c ,  或者/strongswan-x.x.x/src/pluto/kernel.c , 有兴趣的朋友可以研究下。相关内容如下：

>>  /* If there is already a route for peer's client subnet
>>   * and it disagrees about interface or nexthop, we cannot steal it.
>>   * Note: if this connection is already routed (perhaps for another
>>   * state object), the route will agree.
>>   * This is as it should be -- it will arise during rekeying.
>>   */
>>  if (ro != NULL && !routes_agree(ro, c))
>>  {
>>   loglog(RC_LOG_SERIOUS, "cannot route -- route already in use for \"%s\""
>>    , ro->name);
>>   return route_impossible;  /* another connection already
>>           using the eroute */
>>  }

 

貌似国内网站上对*swan的讨论比较少，有也只是一些基本安装配置，其实那些硬件防火墙和路由器的实现好多都是以swan的代码为基础的，swan们的功能是相当强大的，我们国内的东东基本就是把那些现成的代码复制过来再稍加修改的。呵呵。这次来学习下pluto的路由机制吧。

    1 Routing and Erouting in Pluto
    2 =============================
    3
    4 This is meant as internal documentation for Pluto.  As such, it
    5 presumes some understanding of Pluto's code.
    6
    7 It also describes KLIPS 1 erouting, including details not otherwise
    8 documented.  KLIPS 1 documentation would be better included in KLIPS.
    9
   10 Routing and erouting are complicated enough that the Pluto code needs
   11 a guide.  This document is meant to be that guide.
   12
   13
   14 Mechanisms available to Pluto
   15 -----------------------------
   16
   17 All outbound packets that are to be processed by KLIPS 1 must be
   18 routed to an ipsecN network interface.  Pluto only uses normal routing
   19 (as opposed to "Advanced Routing"), so the selection of packets is
   20 made solely on the basis of the destination address.  (Since the
   21 actual routing commands are in the updown script, they could be
   22 changed by the administrator, but Pluto needs to understand what is
   23 going on, and it currently assumes normal routing is used.)
   24
   25 When an outbound packet hits an ipsecN interface, KLIPS figures out
   26 how to process it by finding an eroute that applies to the source and
   27 destination addresses.  Eroutes are global: they are not specific to a
   28 particular ipsecN interface (routing needs to get the packets to any
   29 ipsecN interface; erouting takes it from there, ignoring issues of
   30 source IP address and nexthop (because nobody knows!)).  If multiple
   31 eroutes apply to the packet, among the ones with the most specific
   32 source subnet, the one with the most specific destination subset is
   33 chosen (RGB thinks).  If no eroute is discovered, KLIPS acts as if it
   34 was covered by a DROP eroute (this is the default behaviour; it can be
   35 changed).  At most one eroute can exist for a particular pair of
   36 client subnets.
   37
   38 There are fundamentally two kinds of eroutes: "shunt" eroutes and ones
   39 that specify that a packet is to be processed by a group of IPSEC SAs.
   40 Shunt eroutes specify what is to be done with the packet.  Remember
   41 that these only apply to outbound packets.
   42
   43 - TRAP: notify Pluto of the packet (presumably to attempt to negotiate
   44   an appropriate group of IPSEC SAs).  At the same time, KLIPS
   45   installs a HOLD shunt (see below) for the specific source and
   46   destination addresses from the packet and retains the packet
   47   for later reprocessing (KLIPS does not yet implement retention).
   48   Beware: if the TRAP's subnets both contained a single IP address
   49   then installing the HOLD would actually delete the TRAP.
   50
   51 - PASS: let the packet through in the clear
   52
   53 - DROP: discard the packet
   54
   55 - REJECT: discard the packet and notify the sender
   56
   57 - HOLD: (automatically created by KLIPS when a TRAP fires) block
   58   the packet, but retain it.  If there is already a retained
   59   packet, drop the old one and retain the new.  When the HOLD
   60   shunt is deleted or replaced, the retained packet is reinjected --
   61   there might now be a tunnel.  Note that KLIPS doesn't yet
   62   implement the retention part, so HOLD is really like a DROP.
   63
   64 One consequence of there being only one eroute for a pair of clients
   65 is that KLIPS will only use one SA group for output for this pair,
   66 even though there could be several SA groups that are authorised and
   67 live.  Pluto chooses to make this the youngest such group.
   68
   69
   70
   71 KLIPS lets through in the clear outbound UDP/500 packets that would
   72 otherwise be processed if they originate on this host and meet certain
   73 other conditions.  The actual test is
   74     source == me
   75     && (no_eroute || dest == eroute.dest || isanyaddr(eroute.dest))
   76     && port == UDP/500
   77 The idea is that IKE packets between us and a peer should not be
   78 sent through an IPSEC tunnel negotiated between us.  Furthermore,
   79 our shunt eroutes should not apply to our IKE packets (shunt eroutes
   80 will generally have an eroute.dest of 0.0.0.0 or its IPv6 equivalent).
   81
   82 Inbound behaviour is controlled in a quite different way.  KLIPS
   83 processes only those inbound packets of ESP or AH protocol, with a
   84 destination address for this machine's ipsecN interfaces. The
   85 processing is as dictated by the SAs involved.  Unfortunately, the
   86 decapsulated packet's source and destination address are not checked
   87 (part of "inbound policy checking").
   88
   89 To prevent clear packets being accepted, firewall rules must be put in
   90 place.  This has nothing to do with KLIPS, but is nonetheless in
   91 important part of security.  It isn't clear what firewalling makes
   92 sense when Opportunism is allowed.
   93
   94
   95 For routing and firewalling, Pluto invokes the updown script.  Pluto
   96 installs eroutes via extended PF_KEY messages.
   97
   98
   99 Current Pluto Behaviour
  100 -----------------------
  101
  102 Data Structures:
  103
  104 Routes and most eroutes are associated with connections (struct
  105 connection, a potential connection description).  The enum routing_t
  106 field "routing" in struct connection records the state of routing and
  107 erouting for that connection.  The values are:
  108     RT_UNROUTED,    /* unrouted */
  109     RT_UNROUTED_HOLD,    /* unrouted, but HOLD shunt installed */
  110     RT_ROUTED_PROSPECTIVE,    /* routed, and TRAP shunt installed */
  111     RT_ROUTED_HOLD,    /* routed, and HOLD shunt installed */
  112     RT_ROUTED_FAILURE,    /* routed, and failure-context shunt installed */
  113     RT_ROUTED_TUNNEL    /* routed, and erouted to an IPSEC SA group */
  114 Notice that the routing and erouting are not independent: erouting
  115 (except for HOLD) implies that the connection is routed.
  116
  117 Several struct connections may have the same destination subnet.  If
  118 they agree on what the route should be, they can share it -- any of
  119 them may have routing >= RT_ROUTED_PROSPECTIVE.  If they disagree,
  120 they cannot simultaneously be routed.
  121
  122 invariant: for all struct connections c, d:
  123     (c.that.client == d.that.client
  124         && c.routing >= RT_ROUTED_PROSPECTIVE
  125         && d.routing >= RT_ROUTED_PROSPECTIVE)
  126     => c.interface == d.interface && c.this.nexthop == d.this.nexthop
  127
  128 There are two kinds of eroutes: shunt eroutes and ones for an IPSEC SA
  129 Group.  Most eroutes are associated with and are represeented in a
  130 connection.  The exception is that some HOLD and PASS shunts do not
  131 correspond to connections; those are represented in the bare_shunt
  132 table.
  133
  134 An eroute for an IPSEC SA Group is associated with the state object
  135 for that Group.  The existence of such an eroute is also represented
  136 by the "so_serial_t eroute_owner" field in the struct connection.  The
  137 value is the serial number of the state object for the Group.  The
  138 special value SOS_NOBODY means that there is no owner associated with
  139 this connection for the eroute and hence no normal eroute.  At most
  140 one eroute owner may exist for a particular (source subnet,
  141 destination subnet) pair.  A Pluto-managed eroute cannot be associated
  142 with an RT_UNROUTED connection.
  143
  144 invariant: for all struct connection c:
  145     c.routing == RT_EROUTED_TUNNEL || c.eroute_owner == SOS_NOBODY
  146
  147 invariant: for all struct connections c, d:
  148     c.this.client == d.this.client && c.that.client == d.that.client
  149         && &c != &d
  150     => c.routing == RT_UNROUTED || d.routing == RT_UNROUTED
  151
  152 If no normal eroute is set for a particular (source subnet,
  153 destination subnet) pair for which a connection is routed, then a
  154 shunt eroute would have been installed.  This specifies what should
  155 happen to packets snared by the route.
  156
  157 When Pluto is notified by KLIPS of a packet that has been TRAPped,
  158 there is no connection with which to associate the HOLD.  It is
  159 temporarily held in the "bare_shunt table".  If Opportunism is
  160 attempted but DNS doesn't provide Security Gateway information, Pluto
  161 will replace the HOLD with a PASS shunt.  Since this PASS isn't
  162 associated with a connection, it too will reside in the bare_shunt
  163 table.  If the HOLD can be associated with a connection, it will be
  164 removed from the bare_shunt table and represented in the connection.
  165
  166 There are two contexts for which shunt eroutes are installed by Pluto
  167 for a particular connection.  The first context is with the prospect
  168 of dealing with packets before any negotiation has been attempted.  I
  169 call this context "prospective".  Currently is a TRAP shunt, used to
  170 catch packets for initiate opportunistic negotiation.  In the future,
  171 it might also be used to implement preordained PASS, DROP, or REJECT
  172 rules.
  173
  174 The second context is after a failed negotiation.  I call this context
  175 "failure".  At this point a different kind of shunt eroute is
  176 appropriate.  Depending on policy, it could be PASS, DROP, or REJECT,
  177 but it is unlikely to be TRAP.  The shunt eroute should have a
  178 lifetime (this isn't yet implemented).  When the lifetime expires, the
  179 failure shunt eroute should be replaced by the prospective shunt
  180 eroute.
  181
  182 The kind and duration of a failure shunt eroute should perhaps depend
  183 on the nature of the failure, at least as imperfectly detected by
  184 Pluto.  We haven't looked at this.  In particular, the mapping from
  185 observations to robust respose isn't obvious.
  186
  187 The shunt eroute policies should be a function of the potential
  188 connection.  The failure shunt eroute can be specified for a
  189 particular connection with the flags --pass and --drop in a connection
  190 definition.  There are four combinations, and each has a distinct
  191 meaning.  The failure shunt eroute is incompletely implemented and
  192 cannot be represented in /etc/ipsec.conf.
  193
  194 There is as yet no control over the prospective shunt eroute: it is
  195 always TRAP as far as Pluto is concerned.  This is probably
  196 reasonable: any other fate suggests that no negotiation will be done,
  197 and so a connection definition is inappropriate.  These should be
  198 implemented as manual conns.  There remains the issue of whether Pluto
  199 should be aware of them -- currently it is not.
  200
  201
  202 Routines:
  203
  204 [in kernel.c]
  205
  206 bool do_command(struct connection *c, const char *verb)
  207     Run the updown script to perform such tasks as installing a route
  208     and adjust the firewall.
  209
  210 bool could_route(struct connection *c)
  211     Check to see whether we could route and eroute the connection.
  212     <- shunt_eroute_connection (to check if --route can be performed)
  213     <- install_inbound_ipsec_sa (to see if it will be possible
  214        to (later) install route and eroute the corresponding outbound SA)
  215     <- install_ipsec_sa (to see if the outbound SA can be routed and erouted)
  216
  217 bool trap_connection(struct connection *c)
  218     Install a TRAP shunt eroute for this connection.  This implements
  219     "whack --route", the way an admin can specify that packets for a
  220     connection should be caught without first bringing it up.
  221
  222 void unroute_connection(struct connection *c)
  223     Delete any eroute for a connection and unroute it if route isn't shared.
  224     <- release_connection
  225     <- whack_handle (for "whack --unroute)
  226
  227 bool eroute_connection(struct connection *c
  228 , ipsec_spi_t spi, unsigned int proto, unsigned int satype
  229 , unsigned int op, const char *opname UNUSED)
  230     Issue PF_KEY commands to KLIPS to add, replace, or delete an eroute.
  231     The verb is specified by op and described (for logging) by opname.
  232     <- assign_hold
  233     <- sag_eroute
  234     <- shunt_eroute
  235
  236 bool assign_hold(struct connection *c
  237 , const ip_address *src, const ip_address *dst)
  238     Take a HOLD from the bare_shunt table and assign it to a connection.
  239     If the HOLD is broadened (i.e. the connection's source or destination
  240     subnets contain more than one IP address), this will involve replacing
  241     the HOLD with a different one.
  242
  243 bool sag_eroute(struct state *st, unsigned op, const char *opname)
  244     SA Group eroute manipulation.  The SA Group concerned is
  245     identified with a state object.
  246     <- route_and_eroute several times
  247
  248 bool shunt_eroute(struct connection *c, unsigned int op, const char *opname)
  249     shunt eroute manipulation.  Shunt eroutes are associated with
  250     connections.
  251     <- unroute_connection
  252     <- route_and_eroute
  253     <- delete_ipsec_sa
  254
  255 bool route_and_eroute(struct connection *c, struct state *st)
  256     Install a route and then a prospective shunt eroute or an SA group
  257     eroute.  The code assumes that could_route had previously
  258     given the go-ahead.  Any SA group to be erouted must already
  259     exist.
  260     <- shunt_eroute_connection
  261     <- install_ipsec_sa
  262
  263 void scan_proc_shunts(void)
  264     Every SHUNT_SCAN_INTERVAL scan /proc/net/ipsec_eroute.
  265     Delete any PASS eroute in the bare_shunt table that hasn't been used
  266     within the last SHUNT_PATIENCE seconds.
  267     For any HOLD for which Pluto hasn't received an ACQUIRE (possibly
  268     lost due to congestion), act as if an ACQUIRE were received.
  269
  270 [in connection.c]
  271
  272 struct connection *route_owner(struct connection *c, struct connection **erop)
  273     Find the connection to connection c's peer's client with the
  274     largest value of .routing.  All other things being equal,
  275     preference is given to c.  Return NULL if no connection is routed
  276     at all.  If erop is non-null, sets it to a connection sharing both
  277     our client subnet and peer's client subnet with the largest value
  278     of .routing.
  279     The return value is used to find other connections sharing
  280     a route.  The value of *erop is used to find other connections
  281     sharing an eroute.
  282     <- could_route (to find any conflicting routes or eroutes)
  283     <- unroute_connection (to find out if our route is still in use
  284        after this connection is finished with it)
  285     <- install_inbound_ipsec_sa (to find other IPSEC SAs for the
  286        same peer clients; when we find them WE KILL THEM; a
  287        kludge to deal with road warriors reconnecting)
  288     <- route_and_eroute (to find all the connections from which the
  289        route or eroute is being stolen)
  290
  291 Uses:
  292
  293 - setting up route & shunt eroute to TRAP packets for opportunism
  294   (whack --route).  Perhaps also manually designating DROP, REJECT, or
  295   PASS for certain packets.
  296
  297   whack_handle() responds to --route; calls route_connection()
  298
  299
  300 - removing same (whack --unroute)
  301
  302   whack_handle() responds to --unroute; calls unroute_connection()
  303
  304 - installing route & normal eroute for a newly negotiated group of
  305   outbound IPSEC SAs
  306
  307   + perhaps an (additional) route is not needed: if the negotiation
  308     was initiated by a TRAPped outgoing packet, then there must
  309     already have been a route that got the packet to ipsecN.  Mind
  310     you, it could have been the wrong N!
  311
  312   install_ipsec_sa()
  313
  314 - updating a normal eroute when a new group of IPSEC SAs replaces
  315   an old one due to rekeying.
  316
  317   install_ipsec_sa()
  318
  319 - replacing an old eroute when a negotiation fails.  But this is
  320   tricky.  If this was a rekeying, we should just leave the old
  321   normal eroute be -- it might still work.  Otherwise, this was
  322   an initial negotiation: we should replace the shunt eroute
  323   with one appropriate for the failure context.
  324
  325 - when a group of IPSEC SAs dies or is killed, and it had the eroute,
  326   its normal eroute should be replaced by a shunt eroute.  If there
  327   was an attempt to replace the group, the replacement is in the
  328   failure context; otherwise the replacement is in the prospective
  329   context.