2021-11-02 12:04:40 +01:00
|
|
|
package netxlite
|
|
|
|
|
2022-05-15 19:25:27 +02:00
|
|
|
//
|
|
|
|
// Transparent proxy (for integration testing)
|
|
|
|
//
|
|
|
|
|
2021-11-02 12:04:40 +01:00
|
|
|
import (
|
|
|
|
"context"
|
|
|
|
"net"
|
|
|
|
"time"
|
|
|
|
|
2022-01-03 13:53:23 +01:00
|
|
|
"github.com/ooni/probe-cli/v3/internal/model"
|
2021-11-02 12:04:40 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
// TProxy is the fundamental variable controlling how netxlite creates
|
2022-01-03 13:53:23 +01:00
|
|
|
// net.Conn and model.UDPLikeConn, as well as how it uses the stdlib
|
2021-11-02 12:04:40 +01:00
|
|
|
// resolver. By modifying this variable, you can effectively transparently
|
|
|
|
// proxy netxlite (and hence OONI) activities to other services. This is
|
|
|
|
// quite convenient when performing quality assurance tests.
|
2022-01-03 13:53:23 +01:00
|
|
|
var TProxy model.UnderlyingNetworkLibrary = &TProxyStdlib{}
|
2021-11-02 12:04:40 +01:00
|
|
|
|
2022-01-03 13:53:23 +01:00
|
|
|
// TProxyStdlib is the default model.UnderlyingNetworkLibrary using
|
2021-11-02 12:04:40 +01:00
|
|
|
// the stdlib in the most obvious way for every functionality.
|
|
|
|
type TProxyStdlib struct{}
|
|
|
|
|
|
|
|
// ListenUDP calls net.ListenUDP.
|
2022-01-03 13:53:23 +01:00
|
|
|
func (*TProxyStdlib) ListenUDP(network string, laddr *net.UDPAddr) (model.UDPLikeConn, error) {
|
2021-11-02 12:04:40 +01:00
|
|
|
return net.ListenUDP(network, laddr)
|
|
|
|
}
|
|
|
|
|
getaddrinfo: fix CGO_ENABLED=0 and record resolver type (#765)
After https://github.com/ooni/probe-cli/pull/764, the build for
CGO_ENABLED=0 has been broken for miniooni:
https://github.com/ooni/probe-cli/runs/6636995859?check_suite_focus=true
Likewise, it's not possible to run tests with CGO_ENABLED=0.
To make tests work with `CGO_ENABLED=0`, I needed to sacrifice some
unit tests run for the CGO case. It is not fully clear to me what was happening
here, but basically `getaddrinfo_cgo_test.go` was compiled with CGO
being disabled, even though the ``//go:build cgo` flag was specified.
Additionally, @hellais previously raised a valid point in the review
of https://github.com/ooni/probe-cli/pull/698:
> Another issue we should consider is that, if I understand how
> this works correctly, depending on whether or not we have built
> with CGO_ENABLED=0 on or not, we are going to be measuring
> things in a different way (using our cgo inspired getaddrinfo
> implementation or using netgo). This might present issues when
> analyzing or interpreting the data.
>
> Do we perhaps want to add some field to the output data format that
> gives us an indication of which DNS resolution code was used to
> generate the the metric?
This comment is relevant to the current commit because
https://github.com/ooni/probe-cli/pull/698 is the previous
iteration of https://github.com/ooni/probe-cli/pull/764.
So, while fixing the build and test issues, let us also distinguish
between the CGO_ENABLED=1 and CGO_ENABLED=0 cases.
Before this commit, OONI used "system" to indicate the case where
we were using net.DefaultResolver. This behavior dates back to the
Measurement Kit days. While it is true that ooni/probe-engine and
ooni/probe-cli could have been using netgo in the past when we
said "system" as the resolver, it also seems reasonable to continue
to use "system" top indicate getaddrinfo.
So, the choice here is basically to use "netgo" from now on to
indicate the cases in which we were built with CGO_ENABLED=0.
This change will need to be documented into ooni/spec along with
the introduction of the `android_dns_cache_no_data` error.
## Checklist
- [x] I have read the [contribution guidelines](https://github.com/ooni/probe-cli/blob/master/CONTRIBUTING.md)
- [x] reference issue for this pull request: https://github.com/ooni/probe/issues/2029
- [x] if you changed anything related how experiments work and you need to reflect these changes in the ooni/spec repository, please link to the related ooni/spec pull request: https://github.com/ooni/spec/pull/242
2022-05-30 07:34:25 +02:00
|
|
|
// DefaultResolver returns the default resolver.
|
|
|
|
func (*TProxyStdlib) DefaultResolver() model.SimpleResolver {
|
|
|
|
return &tproxyDefaultResolver{}
|
2021-11-02 12:04:40 +01:00
|
|
|
}
|
|
|
|
|
2022-01-03 13:53:23 +01:00
|
|
|
// NewSimpleDialer returns a &net.Dialer{Timeout: timeout} instance.
|
|
|
|
func (*TProxyStdlib) NewSimpleDialer(timeout time.Duration) model.SimpleDialer {
|
2021-11-02 12:04:40 +01:00
|
|
|
return &net.Dialer{Timeout: timeout}
|
|
|
|
}
|
getaddrinfo: fix CGO_ENABLED=0 and record resolver type (#765)
After https://github.com/ooni/probe-cli/pull/764, the build for
CGO_ENABLED=0 has been broken for miniooni:
https://github.com/ooni/probe-cli/runs/6636995859?check_suite_focus=true
Likewise, it's not possible to run tests with CGO_ENABLED=0.
To make tests work with `CGO_ENABLED=0`, I needed to sacrifice some
unit tests run for the CGO case. It is not fully clear to me what was happening
here, but basically `getaddrinfo_cgo_test.go` was compiled with CGO
being disabled, even though the ``//go:build cgo` flag was specified.
Additionally, @hellais previously raised a valid point in the review
of https://github.com/ooni/probe-cli/pull/698:
> Another issue we should consider is that, if I understand how
> this works correctly, depending on whether or not we have built
> with CGO_ENABLED=0 on or not, we are going to be measuring
> things in a different way (using our cgo inspired getaddrinfo
> implementation or using netgo). This might present issues when
> analyzing or interpreting the data.
>
> Do we perhaps want to add some field to the output data format that
> gives us an indication of which DNS resolution code was used to
> generate the the metric?
This comment is relevant to the current commit because
https://github.com/ooni/probe-cli/pull/698 is the previous
iteration of https://github.com/ooni/probe-cli/pull/764.
So, while fixing the build and test issues, let us also distinguish
between the CGO_ENABLED=1 and CGO_ENABLED=0 cases.
Before this commit, OONI used "system" to indicate the case where
we were using net.DefaultResolver. This behavior dates back to the
Measurement Kit days. While it is true that ooni/probe-engine and
ooni/probe-cli could have been using netgo in the past when we
said "system" as the resolver, it also seems reasonable to continue
to use "system" top indicate getaddrinfo.
So, the choice here is basically to use "netgo" from now on to
indicate the cases in which we were built with CGO_ENABLED=0.
This change will need to be documented into ooni/spec along with
the introduction of the `android_dns_cache_no_data` error.
## Checklist
- [x] I have read the [contribution guidelines](https://github.com/ooni/probe-cli/blob/master/CONTRIBUTING.md)
- [x] reference issue for this pull request: https://github.com/ooni/probe/issues/2029
- [x] if you changed anything related how experiments work and you need to reflect these changes in the ooni/spec repository, please link to the related ooni/spec pull request: https://github.com/ooni/spec/pull/242
2022-05-30 07:34:25 +02:00
|
|
|
|
|
|
|
// tproxyDefaultResolver is the resolver we use by default.
|
|
|
|
type tproxyDefaultResolver struct{}
|
|
|
|
|
|
|
|
// LookupHost implements model.SimpleResolver.LookupHost.
|
|
|
|
func (r *tproxyDefaultResolver) LookupHost(ctx context.Context, domain string) ([]string, error) {
|
|
|
|
return getaddrinfoLookupHost(ctx, domain)
|
|
|
|
}
|
|
|
|
|
|
|
|
// Network implements model.SimpleResolver.Network.
|
|
|
|
func (r *tproxyDefaultResolver) Network() string {
|
|
|
|
return getaddrinfoResolverNetwork()
|
|
|
|
}
|