ddidderr/softlan-vpn
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(client): clear TAP before resolving relay

Browse Source 
The previous startup ordering loaded the virtual MAC before touching TAP, but it
also resolved the relay endpoint before clearing stale TAP media state. That
left a post-crash TAP adapter able to influence DNS or route selection before
the client had pinned the relay path.

Split Windows client startup config into a local phase and a resolved runtime
phase. The local phase reads the certificate, room, TAP adapter selection, and
client identity without performing DNS. Windows startup now writes the TAP
NetworkAddress value and marks TAP media disconnected before resolving the relay
endpoint or opening the QUIC connection.

A regression test uses an intentionally unresolved relay hostname to prove that
building the startup config does not resolve DNS. The client still resolves the
relay before activation and still validates the driver-reported TAP MAC before
bridging.

Test Plan:
- cargo test -p lanparty-client-win
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- cargo fmt --check
- git diff --check
- cargo check -p lanparty-client-win --target x86_64-pc-windows-gnu
  - blocked by missing x86_64-w64-mingw32-gcc for ring on this host

Refs: PLAN.md Windows routing / metric handling
This commit is contained in:
ddidderr
2026-05-22 05:47:27 +02:00
parent 563a073d24
commit 2c490b2693
2 changed files with 92 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+11 -10
View File
@@ -217,16 +217,17 @@ cargo run -p lanparty-client-win -- \
The Windows client binary currently connects to the relay as `role = client`
with a generated locally administered virtual MAC persisted in
`lanparty-client-identity.json`. It resolves the relay DNS name before TAP
activation, writes the generated tunnel MAC to the selected TAP driver's
`NetworkAddress` registry setting, and marks TAP media disconnected before
connecting to the relay. That clears stale connected state from a previous
crashed run without letting the TAP adapter influence relay routing. The client
then completes the control-stream hello/welcome handshake, pins a host route
for the resolved relay IP on the current pre-TAP interface, verifies that the
relay route still uses that pinned host route after TAP activation, and bridges
Ethernet frames between the relay and the TAP-Windows6 adapter until shutdown.
`--relay` accepts a DNS name or socket address; bare hosts default to UDP/443.
`lanparty-client-identity.json`. Before resolving or connecting to the relay,
it writes the generated tunnel MAC to the selected TAP driver's
`NetworkAddress` registry setting and marks TAP media disconnected. That clears
stale connected state from a previous crashed run without letting the TAP
adapter influence relay DNS or route selection. The client then resolves the
relay endpoint, completes the control-stream hello/welcome handshake, pins a
host route for the resolved relay IP on the current pre-TAP interface, verifies
that the relay route still uses that pinned host route after TAP activation,
and bridges Ethernet frames between the relay and the TAP-Windows6 adapter
until shutdown. `--relay` accepts a DNS name or socket address; bare hosts
default to UDP/443.
TAP frames whose source MAC does not match that generated tunnel MAC are
dropped locally before they can consume relay bandwidth; the relay still
enforces the same source-MAC rule.