Add domain-fronting-ip option

[ivulit]

Summary

• Add domain-fronting-ip option to specify an explicit IP address for the domain fronting host instead of resolving it via DNS
• The hostname from the secret is still used for SNI in the TLS handshake
• Useful when DNS resolution of the fronting hostname is blocked

Changes

• mtglib/proxy_opts.go — new DomainFrontingIP field in ProxyOpts
• mtglib/proxy.go — DomainFrontingAddress() uses the IP when set
• internal/cli/simple_run.go — --domain-fronting-ip CLI flag
• internal/cli/run_proxy.go — wire the option into ProxyOpts
• internal/config/config.go, parse.go — config file support
• example.config.toml — commented example

[codecov-commenter]

Codecov Report

❌ Patch coverage is 33.33333% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.50%. Comparing base (432e530) to head (21129b6).

Files with missing lines	Patch %	Lines
internal/cli/simple_run.go	0.00%	3 Missing ⚠️
mtglib/proxy.go	60.00%	1 Missing and 1 partial ⚠️
internal/cli/run_proxy.go	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #334      +/-   ##
==========================================
- Coverage   68.63%   68.50%   -0.13%     
==========================================
  Files          84       84              
  Lines        2707     2715       +8     
==========================================
+ Hits         1858     1860       +2     
- Misses        752      757       +5     
- Partials       97       98       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[9seconds]

PR itself is great, I have no comments. Sorry for this mess about 2 config datastructure: at that time there was no a good way of having TOML with reliable custom unmarshallers. I guess, it is a time to cleanup this place a little bit.

But if PR itself is ready to be merged, I'm still wondering about this usecase. My idea of having DOH by default for each and every network communication was exactly because of this usescase, when VM works in hazardous perimeter, and DNS queries are intercepted. OTOH, DOH is kinda a couple of TLS connections to legit huge domains. I understand that it is always possible to setup DNS stub resolver to use some DNSCrypt, DoT or DoH upstreams and not bother doing it here, I decided that it worth to have it this way.

Just out of curiousity, what kind of blocking could happen on this level? If some huge DoH servers like Quad9 and Cloudflare could be banned, there are many small ones that are equaly good.

[ivulit]

I'm still wondering about this usecase

This use case emerged when you added Proxy Protocol support and I moved mtg behind a reverse proxy. I use domain fronting with a stub website hosted on the same machine. The issue is that I can't simply forward traffic from mtg to localhost, because a mandatory DNS resolution happens on the DoH server. Of course, to avoid a routing loop, I could use available option and redirect to a different port with on the WAN interface and block it externally via firewall — but being able to forward directly to localhost feels like a more elegant and correct solution.

[9seconds]

Yes, I see now. Thank you very much for your help!

[ivulit]

Yes, I see now. Thank you very much for your help!

Glad to help. Thank you for your great project!