... | @@ -96,10 +96,10 @@ In practice, we don't need buckets for each possible combination of mapping and |
... | @@ -96,10 +96,10 @@ In practice, we don't need buckets for each possible combination of mapping and |
|
|
|
|
|
### Determining NAT behaviour
|
|
### Determining NAT behaviour
|
|
|
|
|
|
We determine the NAT behaviour of clients by using the tricks in [RFC 5780](https://tools.ietf.org/html/rfc5780). We worked with [pion](https://github.com/pion) to implement the necessary functionality in their STUN library https://github.com/pion/stun. For standalone proxies written in Go, we use the same method.
|
|
We determine the NAT behaviour of clients by using the tricks in [RFC 5780](https://tools.ietf.org/html/rfc5780). We worked with [pion](https://github.com/pion) to implement the necessary functionality in their STUN library https://github.com/pion/stun.
|
|
|
|
|
|
However, this method does not work for web-based proxies such as those run with the badge or Snowflake webextension. The Mozilla and Chrome WebRTC APIs do not expose the ability to perform the STUN tests in RFC 5780, nor do these browser allow arbitrary UDP connections to be made by javascript (and for good reason). This presented a problem considering the vast majority of our proxies are web-based.
|
|
However, this method does not work for web-based proxies such as those run with the badge or Snowflake webextension. The Mozilla and Chrome WebRTC APIs do not expose the ability to perform the STUN tests in RFC 5780, nor do these browser allow arbitrary UDP connections to be made by javascript (and for good reason). This presented a problem considering the vast majority of our proxies are web-based.
|
|
|
|
|
|
To solve this, we set up a probe service that allows proxies to test their NAT compatibility by attempting to connect to symmetrically NAT'd WebRTC peer. If it is able to successfully open a datachannel with this peer, we classify it as an unrestricted proxy. If the proxy times out without opening the datachannel, we sort it into the restricted bucket.
|
|
To solve this, we set up a probe service that allows proxies to test their NAT compatibility by attempting to connect to symmetrically NAT'd WebRTC peer. If it is able to successfully open a datachannel with this peer, we classify it as an unrestricted proxy. If the proxy times out without opening the datachannel, we sort it into the restricted bucket. For standalone proxies written in Go, we use the same method.
|
|
|
|
|
|
[^1]: there is an edge case here where clients with port-dependent filtering behaviour (AI,PD) won't work with symmetrically mapped proxies, i.e. proxies with (AO,X) or (AP,X) behaviours. However, symmetric mapping is relatively rare. At the time of writing this post, (AI,PD) clients work with over 80% of restricted proxies. |
|
[^1]: there is an edge case here where clients with port-dependent filtering behaviour (AI,PD) won't work with symmetrically mapped proxies, i.e. proxies with (AO,X) or (AP,X) behaviours. However, symmetric mapping is relatively rare. At the time of writing this post, (AI,PD) clients work with over 80% of restricted proxies. |
|
|
|
\ No newline at end of file |