search

refraction-networking / conjure

Conjure Refraction Networking station code
https://refraction.network
Apache License 2.0
70 stars 21 forks source link

IPv6 phantom replaced by IPv4 address sometimes. #240

Closed jmwample closed 1 year ago

jmwample commented 1 year ago

There seems to be a bug somewhere in the phantom selection process where it is possible for the two phantoms associated with a registration to be IPv4. I am not sure how this happend. My theory about how it was happening seems incorrect

  1. IPv6 Phantom Selection bug that allows selection of IPv4 phantom when the number of IPv4 phantoms is sufficiently small.
    • This doesn't seem to be happening.
  2. When using a bidirectional registrar maybe we are not careful enough when setting the phantom in the response and the v6 address gets overwritten when it should be the v4 address.

Example

Happened with 1164

[15:05:21] [4-7c2dd1] Shared Secret  - 7c2dd17772859cb9dc1ed1bc5a728717d02536f32e7775714f65dc178911810e
[15:05:21] [4-7c2dd1] Representative - b5b9edd1a8a57d6ac1c371e660ed910928f85eb216dc55c1cf5d144e0f125a8d
[15:05:22] [4-7c2dd1] Attempting to Connect using prefix_TLSAlertFatal libcj_v4...
[15:05:23] [4-7c2dd1] failed to dial phantom 35.6.193.242: dial tcp 35.6.193.242:443: i/o timeout
[15:05:23] [4-7c2dd1] Connected to phantom 35.6.134.193:443 using transport prefix_TLSAlertFatal
[15:05:53] copy loop ended

^ why does it say dial failed then it successfully connects to a different v4 address?

jmwample commented 1 year ago

this is the fault of the sever side phantom selection and I am not sure how things ever work given the bug here.

https://github.com/refraction-networking/conjure/blob/cd66eca4d2911f7702e185a7318c212017b794fa/pkg/station/lib/phantom_selector.go#L240C1-L247C1

When selecting IPv6 phantoms the client filters to only IPv6 subnets, however, the station includes all subnets, IPv4 and Ipv6.

When Selecting IPv4 phantom, both the client and the station filter to only IPv4 subnets.

jmwample commented 1 year ago

This was a station side only issue which does not require changes to the client. It was the bidirectional registrar that was causing this issue.

Closed by #241