Snowpack currently also supports user-defined configuration for multiple paths, on which, user can:
To enable this function, user needs to execute Snowpack with the following arguments:
./snowpack-cli -m user -mr <config_file_path>
with config_file_path is the path to configuration file. An explanation of detail format of configuration file can be found in the following section.
The configuration file is in JSON format. If no version number is provided in the file, it is considered to be in v0 format
Noted that configurations introduced in later versions cannot be parsed with older version numbers and will be ignored.
Supported versions are currently :
An example of the config file v0 can be found below.
{
"ROUTE1": {
"Id": 1,
"Route": {
"Pu1": "192.168.9.92",
"Ps1": "192.168.9.94",
"Pu2": "192.168.9.97",
"Ps2": "192.168.9.95",
"PR": "192.168.9.96"
},
"Protocols":
[
{
"name": "udp",
"not daddr": ["35.180.139.74", "1.1.1.1"],
"not dport": ["8081", "2000-2050", "3000-4000"]
}
]
},
"ROUTE2": {
"Id": 2,
"Route": {
"Pu1": "192.168.9.92",
"Ps1": "192.168.9.95",
"Ps2": "192.168.9.94",
"public_ip_country": "France"
},
"Protocols":
[
{
"name": "icmp"
},
{
"name": "tcp",
"daddr": ["8.8.8.8"],
"dport": ["8081", "2000-2050", "3000-4000"]
}
]
}
}
In the version v1.0, new configuration entry_country is introduced and the file format is modified to include version and config field.
{
"version": "1.0",
"config": {
"ROUTE1": {
"Id": 1,
"Route": {
"entry_country": "Poland",
"Ps1": "192.168.9.94",
"Ps2": "192.168.9.95",
"PR": "192.168.9.96"
},
"Protocols":
[
{
"name": "udp",
"not daddr": ["35.180.139.74", "1.1.1.1"],
"not dport": ["8081", "2000-2050", "3000-4000"]
}
]
}
}
}
In the version v1.1, nodes can now be constrained by their continent location in addition of country and IP.
Those constraint are now deduced and reuse the same fields Pu1, Pu2, Ps1, Ps2, PR.
Fields entry_country and public_ip_country are deprecated and replaced by entry and public_ip fields that support IP, country or continent.
{
"version": "1.1",
"config": {
"ROUTE1": {
"Id": 1,
"Route": {
"Pu1" : "192.168.9.94",
"Pu2" : "Switzerland",
"Ps1": "Europe",
"Ps2": "192.168.9.96",
"public_ip": "France"
},
"Protocols":
[
{
"name": "udp",
"not daddr": ["35.180.139.74", "1.1.1.1"],
"not dport": ["8081", "2000-2050", "3000-4000"]
}
]
}
}
}
Since V1.0
Configuration file format version. Supported values include:
Since V1.0
Contains a list of route each identified by a unique key representing the name of the route. Each value contains the configuration of the route accompanied by the characteristics of the data traversing through it. Each value must contain the following fields:
Since V0
Non-negative integer which is unique for each route. It is also the id of the queue used by nftables to store traffic of the route.
Since V0
Used to specify constraints on the nodes IPs or location.
Can contain the following fields :
All fields are optional, any node not constrained will be chosen at random.
V0 to V1.0
IP address of the corresponding nodes.
Since V1.1
IP address, country or continent of the corresponding nodes.
V0 to V1.0
Country of PR node, where services see user’s traffic coming out. When using this keyword, specifying PR address is unnecessary and will be ignored.
Since V1.1
Deprecated field : use public_ip instead.
V0 to V1.0
Country of Pu1 and Pu2 nodes, where user’s traffic initially arrives. When using this keyword, specifying Pu1 and Pu2 IP address is unnecessary and will be ignored.
Since V1.1
Deprecated field : use entry instead.
Since V1.1
IP, country or continent of PR node, where services see user’s traffic coming out. When using this keyword, specifying PR is unnecessary and will be ignored.
Since V1.1
IP, country or continent of Pu1 and Pu2 nodes, where user’s traffic initially arrives. When using this keyword, specifying Pu1 and Pu2 is unnecessary and will be ignored.
Since V0
Procotol-related configurations for each route. Mutiple configurations for diffrent protocols in a single route are supported.
– name: , transport protocol name, currently only supports tcp, udp and icmp. You can use any if you want to take all protocols.
– dport: <list>, list of all destination ports in string format are included in this route. The range of ports is also supported, which is given by the following format: “-” where the lower and upper bound are separated by ‘-’.
– daddr: <list>, list of all destination ip addresses in string format are included in this route. The range of addresses is also supported, which is given by the following format: “-” where the lower and upper bound are separated by ‘-’.
– not dport: <list>, list of all destination ports in string format are excluded in this route. The range of ports is also supported, which is given by the following format: “-” where the lower and upper bound are separated by ‘-’.
– not daddr: <list>, list of all destination ip addresses in string format are excluded in this route. The range of addresses is also supported, which is given by the following format: “-” where the lower and upper bound are separated by ‘-’.
If neither dport nor not dport are given, traffic to any ports is captured by Snowpack. This also can be done by specifying: “dport”: “any”. Same rule is applied for daddr.
Note that there is no notion of port in icmp packets, therefore, giving dport or not dport for icmp configuration is ignored.
You can use the following commands to get info on the existing nodes:
./snowpack-cli --exit_country_info
./snowpack-cli --public_ip_info
./snowpack-cli --continent_info
./snowpack-cli --nodes_info