![]() |
|
||
IPv6 communicationThe Dante distribution has support for IPv6 in the server part (the socksify client part does currently not support IPv6). Communicating via IPv6IPv6 in Dante is to a large extent handled automatically based on the address types found in the server configuration file. In most cases, no changes will be required to existing IPv4-only based Dante configurations, but in some cases, changes will be necessary. These cases are described below. IPv4-only configurationsDante configurations that only use IPv4-addresses in their sockd.conf file will generally not need to consider IPv6. IPv4 rules will process SOCKS requests for IPv4 addresses while IPv6 traffic will be blocked unless there are specific IPv6 rules that allow it. Note however that if any rules are specified using hostnames or interface names, rather than explicit IPv4-addresses, the hostnames or interfacenames might expand to IPv6 addresses. In this case, you do not have a IPv4-only configuration, and you need to take care to understand the implications IPv6-support in Dante entails for your configuration. Changes to sockd.conf in an IPv4-only usage scenarios are only necessary if either of Dante's internal or external interface addresses are specified in sockd.conf using interfacenames (e.g., external: eth0) or hostnames (e.g., internal: dante-int.example.com), and these interfacenames or hostnames now, or possibly in the future, will contain IPv6 addresses. The Dante server will by default use all addresses found on an internal interface if the interface is specified by it's name (rather than by one of its IP-addresses). If the interface has one or more IPv6 addresses, this will result in the Dante server also using the IPv6 addresses. Unless the sockd.conf file is changed to also accept IPv6 traffic, or includes hostnames that resolve to IPv6-addresses in Dante's ACL rules, all connections made to any IPv6 address will however be blocked, so this should have no practical security related consequences. If it is desired to only listen to IPv4 addresses, the internal keyword in the sockd.conf file should however, if possible, explicitly specify the IPv4 address the server should bind to, instead of using a interface name or hostname.
Similarly, the external keyword in the sockd.conf file should explicitly specify the IPv4 address the server should bind to on the external side, instead of using the interface or hostname. This will prevent Dante from opening any IPv6 connections.
Mixed IPv4/IPv6 configurationsFor a Dante server to accept requests on both IPv4 and IPv6 addresses, it is necessary to specify either a network interface that has both types of addresses as an argument to the internal sockd.conf keyword, or specify the keyword multiple times with different addresses. For example: #accept SOCKS requests on 10.0.0.1 (IPv4) and fc00::01 (IPv6) internal: 10.0.0.1 port = 1080 internal: fc00::1 port = 1080 Dante's config file will also need rules for both address types. #accept connections from any IPv4 client client pass { from: 0.0.0.0/0 to: 0.0.0.0/0 } The above is an example of a rule for IPv4 addresses that will allow any IPv4 client to connect to the Dante server. An equivalent rule for IPv6 can look like the following: #accept connections from any IPv6 client client pass { from: ::/0 to: ::/0 } Both of the above rules match only one address type, the first only IPv4, the second only IPv6. To add a rule that accepts any address, regardless of address family, the following special Dante-specific address syntax can be used (0/0): #accept connections from any client client pass { from: 0/0 to: 0/0 } The rule above will match both IPv4 and IPv6 clients, connecting to either Dante's internal IPv4 address (if any) or Dante's internal IPv6 address (if any). IPv6-only configurationsAs with the IPv4-only configurations described above, allowing only IPv6 clients to connect can be achieved by using rules that only match IPv6 addresses and fully specifying the IPv6 addresses that the server should bind to on the internal and external interfaces, rather than using interfacenames/hostnames. Specifying an interfacename as the value for an internal keyword will result in the Dante server listening to both IPv4 and IPv6 addresses, if that interface has both types of addresses. No IPv4 clients will however be accepted unless the client pass rules in the configuration file also allow access by clients using IPv4 addresses. Interface-level control of address familyNOTE: This functionality is only found in Dante 1.4.1 and later. When an interface is used with the internal or external keywords to specify the interface addresses, Dante will by default use all available addresses, both IPv4 and IPv6, but this behavior can be controlled with the internal.protocol and external.protocol keywords. These keywords accept any combination of the values ipv4 and ipv6, for example: #use any ipv4 and ipv6 addresses found on eth0 for the internal side internal.protocol: ipv4 ipv6 internal: eth0 #use only ipv4 addresses found on eth0 for the internal side internal.protocol: ipv4 internal: eth0 #use only ipv6 addresses found on eth0 for the internal side internal.protocol: ipv6 internal: eth0 For the external side, the behavior is the same: #use any ipv4 and ipv6 addresses found on eth1 for the external side external.protocol: ipv4 ipv6 external: eth1 #use only ipv4 addresses found on eth1 for the external side external.protocol: ipv4 external: eth1 #use only ipv6 addresses found on eth1 for the external side external.protocol: ipv6 external: eth1 Note that the order of the keywords is important; the protocol specification must always precede the interface specification. Failure to do this will result in an error when starting the server. The default behavior is as follows: #default behavior; both ipv4 and ipv6 addresses used, if available. internal.protocol: ipv4 ipv6 internal: eth0 #default behavior; both ipv4 and ipv6 addresses used, if available. external.protocol: ipv4 ipv6 external: eth1 It is in other words only necessary to specify the protocol family if only one address family is wanted on either the internal or external side. Limiting the protocols in use will result in the following behavior:
The protocol specifications can be changed for a running server by updating the configuration file and sending SIGHUP to the server. No change will be made for existing clients, but new requests should use the new values. Additional notes
|