Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forward incoming tailnet connections to the host's primary interface #454

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

lmagyar
Copy link
Contributor

@lmagyar lmagyar commented Jan 20, 2025

Proposed Changes

TLDR: Without this, users have to enable subnet routing only to access the host, really different user experience compared to the general Tailscale client (and when there are multiple 192.168.1.x subnets, more trouble).

This is identical what Tailscale's docker image does (here). Though compared to Tailscale's docker image, this PR is using only -A append, that is less intrusive than -I insert.

When userspace networking is enabled, tailscaled automatically forwards incoming tailnet connections to localhost. Not in TS docs, only an issue comment (here), but tested and true. Without this, there would be no way to access anything on the host.

When userspace networking is disabled, tailscaled doesn't do anything, but in a container, services not running on all interfaces will not be accessible on tailscale0 interface, and by default they are running only on the HA managed interfaces.

I've added a config switch to be able to disable this forwarding in case it interferes with some complex networking setup.

UPDATE: Tested with real subnet routing, rPI3, rPI4, HA OS VM, userspace_networking enabled/disabled, snat_subnet_routes enabled/disables, stateful_filtering enabled/disabled, it didn't interfere with these settings.

Related Issues

Summary by CodeRabbit

  • New Features
    • Introduced enhanced network forwarding for Tailscale integration, supporting both IPv4 and IPv6.
    • Added dynamic management of forwarding rules with improved logging for better connectivity.
    • Enabled a streamlined, one-time execution mode for the forwarding service.
    • Integrated conditional logic to disable network forwarding based on specific configuration settings.

Copy link

coderabbitai bot commented Jan 20, 2025

Walkthrough

Several new scripts and configuration changes have been introduced to enhance the forwarding service within the S6 overlay. A new finish script removes IP forwarding rules during shutdown, and a new run script manages the setup of iptables rules for both IPv4 and IPv6. Additionally, a new oneshot service type entry has been added along with an operational component in the forwarding directory. A conditional block in the stage2 hook now disables the forwarding service based on the userspace networking configuration.

Changes

File(s) Change Summary
tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/{finish, run, up, type} Added new scripts and configurations for managing IP forwarding. The finish script removes forwarding rules, the run script sets up forwarding using iptables, and the type file now includes an oneshot entry.
tailscale/rootfs/etc/s6-overlay/scripts/stage2_hook.sh Integrated a new conditional block that disables the forwarding service if the "userspace_networking" configuration is missing or set to true.

Sequence Diagram(s)

sequenceDiagram
  participant S6 as "S6 Service Manager"
  participant Run as "forwarding/run Script"
  participant Validator as "get_forwardable_address()"
  participant Ipt as "iptables/ip6tables"

  S6->>Run: Trigger forwarding service startup
  Run->>Run: Retrieve Tailscale IPv4 & IPv6 addresses
  Run->>Validator: Validate IPv4 address
  Validator-->>Run: Return valid IPv4 address
  Run->>Run: Call setup_forwarding for IPv4
  Run->>Ipt: Append iptables rule for IPv4
  Run->>Validator: Validate IPv6 address
  Validator-->>Run: Return valid IPv6 address
  Run->>Run: Call setup_forwarding for IPv6
  Run->>Ipt: Append ip6tables rule for IPv6
  Run->>S6: Forwarding rules established
Loading
sequenceDiagram
  participant S6 as "S6 Service Manager"
  participant Finish as "forwarding/finish Script"
  participant Remover as "remove_forwarding()"
  participant Ipt as "iptables/ip6tables"

  S6->>Finish: Trigger forwarding service shutdown
  Finish->>Remover: Execute removal for IPv4
  Remover->>Ipt: Delete DNAT rule for IPv4
  Finish->>Remover: Execute removal for IPv6
  Remover->>Ipt: Delete DNAT rule for IPv6
  Finish->>S6: Cleanup complete
Loading

Suggested labels

new-feature, bugfix

Suggested reviewers

  • frenck

Poem

I'm a rabbit on a coding spree,
Hopping through scripts so nimbly and free.
New rules set up, old ones now cleared,
With each line of code, I've thoroughly cheered.
In the world of forwarding, carrots rhyme with glee!
🐇💻


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bb48404 and ba266a7.

📒 Files selected for processing (3)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/finish (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/run (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/scripts/stage2_hook.sh (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
  • tailscale/rootfs/etc/s6-overlay/scripts/stage2_hook.sh
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/run
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/finish

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@lmagyar lmagyar marked this pull request as ready for review January 26, 2025 21:24
Copy link

coderabbitai bot commented Jan 26, 2025

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Nitpick comments (4)
tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/finish (1)

22-24: Make warning messages more specific.

The warning messages should indicate whether it's IPv4 or IPv6 forwarding removal that failed.

-    bashio::log.warning "Removing forwarding is unsuccessful"
+    bashio::log.warning "Failed to remove IPv4 forwarding rule from ${from_address_ipv4} to ${to_address}"
-    bashio::log.warning "Removing forwarding is unsuccessful"
+    bashio::log.warning "Failed to remove IPv6 forwarding rule from ${from_address_ipv6} to ${to_address}"

Also applies to: 32-34

tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/run (2)

31-35: Add error message for ipcalc failures.

When ipcalc fails, it would be helpful to log the reason.

-  if ! ipinfo="$(/usr/bin/ipcalc --json "${address}")"; then
+  if ! ipinfo="$(/usr/bin/ipcalc --json "${address}" 2>&1)"; then
+    bashio::log.debug "Address ${address} is not valid: ${ipinfo}"
     return 1
   fi

44-48: Consider handling multiple addresses more robustly.

The current implementation takes the first valid address but doesn't log skipped addresses. Adding debug logging would help troubleshooting.

   for address in "$(bashio::network.ipv4_address)"; do
+    bashio::log.debug "Checking IPv4 address: ${address}"
     if to_address_ipv4=$(get_forwardable_address "${address}"); then
+      bashio::log.debug "Using IPv4 address: ${to_address_ipv4}"
       break
+    else
+      bashio::log.debug "Skipping non-forwardable IPv4 address: ${address}"
     fi
   done

Also applies to: 51-55

tailscale/DOCS.md (1)

166-168: Minor style improvement needed in the documentation.

The abbreviation "ie." should be written as "i.e." (that is) with two periods.

-Home Assistant (ie. not on all interfaces), are not accessible directly from the
+Home Assistant (i.e., not on all interfaces), are not accessible directly from the
🧰 Tools
🪛 LanguageTool

[uncategorized] ~167-~167: The abbreviation “i.e.” (= that is) requires two periods.
Context: ...e interfaces managed by Home Assistant (ie. not on all interfaces), are not accessi...

(I_E)


[style] ~167-~167: Consider using “inaccessible” to avoid wordiness.
Context: ...istant (ie. not on all interfaces), are not accessible directly from the tailnet when userspac...

(NOT_ABLE_PREMIUM)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 7438621 and c2c128d.

📒 Files selected for processing (9)
  • tailscale/DOCS.md (2 hunks)
  • tailscale/config.yaml (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/down (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/finish (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/run (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/type (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/up (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/scripts/stage2_hook.sh (1 hunks)
  • tailscale/translations/en.yaml (1 hunks)
✅ Files skipped from review due to trivial changes (2)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/down
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/up
🧰 Additional context used
🪛 LanguageTool
tailscale/DOCS.md

[uncategorized] ~167-~167: The abbreviation “i.e.” (= that is) requires two periods.
Context: ...e interfaces managed by Home Assistant (ie. not on all interfaces), are not accessi...

(I_E)


[style] ~167-~167: Consider using “inaccessible” to avoid wordiness.
Context: ...istant (ie. not on all interfaces), are not accessible directly from the tailnet when userspac...

(NOT_ABLE_PREMIUM)

🔇 Additional comments (5)
tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/type (1)

1-1: LGTM! Appropriate service type chosen.

The oneshot service type is correct for this use case as the forwarding setup should run once at startup.

tailscale/config.yaml (1)

37-37: LGTM! Schema addition follows existing patterns.

The new forward_to_host field is properly defined as an optional boolean, maintaining consistency with other similar configuration options.

tailscale/rootfs/etc/s6-overlay/scripts/stage2_hook.sh (1)

17-23: LGTM! Well-structured service management logic.

The new conditional block follows the established pattern for service management and correctly handles the configuration checks for the new forward_to_host feature.

tailscale/translations/en.yaml (1)

37-42: LGTM! Clear and consistent translation entry.

The translation entry for forward_to_host is well-documented and follows the established format.

tailscale/DOCS.md (1)

151-175: LGTM! Comprehensive documentation of the new feature.

The documentation thoroughly explains the feature's purpose, behavior, and limitations. The notes about Tailscale's serve/funnel features and hairpinning limitations are particularly helpful for users.

🧰 Tools
🪛 LanguageTool

[uncategorized] ~167-~167: The abbreviation “i.e.” (= that is) requires two periods.
Context: ...e interfaces managed by Home Assistant (ie. not on all interfaces), are not accessi...

(I_E)


[style] ~167-~167: Consider using “inaccessible” to avoid wordiness.
Context: ...istant (ie. not on all interfaces), are not accessible directly from the tailnet when userspac...

(NOT_ABLE_PREMIUM)

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (4)
tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/finish (1)

18-29: LGTM! Consider improving error handling.

The function correctly removes forwarding rules. However, consider capturing and logging the specific error message when rule removal fails.

-      if ! ${cmd} -t nat -D PREROUTING -d ${from_address} -j DNAT --to-destination ${to_address}; then
-        bashio::log.warning "Removing forwarding is unsuccessful (${ip_version})"
+      if ! error=$(${cmd} -t nat -D PREROUTING -d ${from_address} -j DNAT --to-destination ${to_address} 2>&1); then
+        bashio::log.warning "Failed to remove ${ip_version} forwarding: ${error}"
tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/run (2)

12-37: Enhance error messages for better debugging.

The function correctly validates addresses but could provide more specific error messages.

 if [[ "${address}" =~ .*:.* ]]; then
   if [[ $(</proc/sys/net/ipv6/conf/all/forwarding) -eq 0 ]]; then
+    bashio::log.debug "IPv6 forwarding is disabled"
     return 1
   fi
 else
   if [[ $(</proc/sys/net/ipv4/ip_forward) -eq 0 ]]; then
+    bashio::log.debug "IPv4 forwarding is disabled"
     return 1
   fi
 fi

41-53: Add success logging for better visibility.

Consider adding a log message when a valid address is found.

   if ! bashio::var.equals "$(bashio::network.${ip_version}_method)" "disabled"; then
     for address in "$(bashio::network.${ip_version}_address)"; do
       if get_forwardable_address "${address}"; then
+        bashio::log.debug "Found valid ${ip_version} address: ${address}"
         break
       else
         bashio::log.debug "Skipping non-forwardable ${ip_version} address: ${address}"
       fi
     done
   fi
tailscale/DOCS.md (1)

151-174: Improve documentation clarity and conciseness.

The documentation is comprehensive but could be more concise. Consider:

  1. Combining the first two notes about service accessibility
  2. Making the hairpinning note more prominent as it's a key limitation
-**Note:** Without forwarding, services running only on the interfaces managed by
-Home Assistant (i.e. not on all interfaces), are not accessible directly from
-the tailnet when userspace networking is disabled.
-
-**Note:** Tailscale's serve and funnel features have priority over this plain
-port forwarding, those connections won't be forwarded directly to the host.
+**Note:** Without forwarding, services running only on Home Assistant-managed
+interfaces are inaccessible from the tailnet when userspace networking is disabled.
+Tailscale's serve and funnel features take priority over this forwarding.
 
-**Note:** Hairpinning is not implemented, do not test forwarding by accessing
-the host, from itself, through the tailscale0 interface.
+**Important:** Hairpinning is not implemented. Do not test forwarding by accessing
+the host from itself through the tailscale0 interface.
🧰 Tools
🪛 LanguageTool

[style] ~167-~167: Consider using “inaccessible” to avoid wordiness.
Context: ...stant (i.e. not on all interfaces), are not accessible directly from the tailnet when userspac...

(NOT_ABLE_PREMIUM)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c2c128d and b7b7cf6.

📒 Files selected for processing (3)
  • tailscale/DOCS.md (2 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/finish (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/run (1 hunks)
🧰 Additional context used
🪛 LanguageTool
tailscale/DOCS.md

[style] ~167-~167: Consider using “inaccessible” to avoid wordiness.
Context: ...stant (i.e. not on all interfaces), are not accessible directly from the tailnet when userspac...

(NOT_ABLE_PREMIUM)

🔇 Additional comments (3)
tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/finish (1)

32-38: LGTM! Error handling implemented as suggested.

The implementation correctly handles and logs failures when retrieving Tailscale IP addresses.

tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/run (2)

56-77: LGTM! Well-structured implementation.

The function correctly:

  • Validates input parameters
  • Checks for existing rules
  • Uses append (-A) for less intrusive rule addition

79-92: LGTM! Consistent implementation with finish script.

The main section properly handles both IPv4 and IPv6 address retrieval and forwarding setup.

@lmagyar lmagyar force-pushed the pr-forward-to-host branch from 4d48fec to 55f8f16 Compare February 2, 2025 22:19
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
tailscale/DOCS.md (1)

166-168: Style Improvement Suggestion

The note currently states that services “are not accessible directly” from the tailnet when userspace networking is disabled. For improved clarity and conciseness, consider rephrasing this to use “inaccessible.” For example:

- **Note:** Without forwarding, services running only on the interfaces managed by Home Assistant (i.e. not on all interfaces), are not accessible directly from the tailnet when userspace networking is disabled.
+ **Note:** Without forwarding, services running solely on the Home Assistant-managed interfaces are inaccessible from the tailnet when userspace networking is disabled.

This change will make the statement more direct and clear.

🧰 Tools
🪛 LanguageTool

[style] ~167-~167: Consider using “inaccessible” to avoid wordiness.
Context: ...stant (i.e. not on all interfaces), are not accessible directly from the tailnet when userspac...

(NOT_ABLE_PREMIUM)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4d48fec and 55f8f16.

📒 Files selected for processing (9)
  • tailscale/DOCS.md (2 hunks)
  • tailscale/config.yaml (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/down (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/finish (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/run (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/type (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/up (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/scripts/stage2_hook.sh (1 hunks)
  • tailscale/translations/en.yaml (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (8)
  • tailscale/config.yaml
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/type
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/down
  • tailscale/translations/en.yaml
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/up
  • tailscale/rootfs/etc/s6-overlay/scripts/stage2_hook.sh
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/finish
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/run
🧰 Additional context used
🪛 LanguageTool
tailscale/DOCS.md

[style] ~167-~167: Consider using “inaccessible” to avoid wordiness.
Context: ...stant (i.e. not on all interfaces), are not accessible directly from the tailnet when userspac...

(NOT_ABLE_PREMIUM)

🔇 Additional comments (2)
tailscale/DOCS.md (2)

72-72: New YAML Config Option Addition

The new configuration option forward_to_host: true has been added correctly to the YAML configuration snippet. This clearly indicates that incoming tailnet connections should be forwarded to the host's primary interface when userspace networking is disabled. Please ensure that this option’s default value and behavior stay consistent with the running service logic.


151-175: Comprehensive Documentation for the forward_to_host Option

The documentation block for the forward_to_host option is detailed and clearly explains the feature’s behavior under different networking modes. It covers the default setting, the effect when userspace networking is enabled versus disabled, and includes important notes regarding Tailscale’s serve/funnel precedence and the unimplemented hairpinning feature. This thorough explanation helps users understand the implications of enabling or disabling the option.

🧰 Tools
🪛 LanguageTool

[style] ~167-~167: Consider using “inaccessible” to avoid wordiness.
Context: ...stant (i.e. not on all interfaces), are not accessible directly from the tailnet when userspac...

(NOT_ABLE_PREMIUM)

@lmagyar lmagyar force-pushed the pr-forward-to-host branch from 55f8f16 to bb48404 Compare February 3, 2025 13:01
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
tailscale/DOCS.md (1)

151-174: Documentation for forward_to_host: Clear and Detailed

The documentation block for the forward_to_host option clearly explains its behavior across different networking scenarios and includes important notes—this is in line with the PR objectives.

Nitpick: On line ~167, consider rephrasing “are not accessible directly” to “are inaccessible” for improved conciseness. For example:

-**Note:** Without forwarding, services running only on the interfaces managed by Home Assistant (i.e. not on all interfaces), are not accessible directly from the tailnet when userspace networking is disabled.
+**Note:** Without forwarding, services running only on the interfaces managed by Home Assistant (i.e. not on all interfaces), are inaccessible from the tailnet when userspace networking is disabled.

This suggestion would streamline the phrasing.

🧰 Tools
🪛 LanguageTool

[style] ~167-~167: Consider using “inaccessible” to avoid wordiness.
Context: ...stant (i.e. not on all interfaces), are not accessible directly from the tailnet when userspac...

(NOT_ABLE_PREMIUM)

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 55f8f16 and bb48404.

📒 Files selected for processing (9)
  • tailscale/DOCS.md (2 hunks)
  • tailscale/config.yaml (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/down (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/finish (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/run (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/type (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/up (1 hunks)
  • tailscale/rootfs/etc/s6-overlay/scripts/stage2_hook.sh (1 hunks)
  • tailscale/translations/en.yaml (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (8)
  • tailscale/translations/en.yaml
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/down
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/type
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/up
  • tailscale/config.yaml
  • tailscale/rootfs/etc/s6-overlay/scripts/stage2_hook.sh
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/finish
  • tailscale/rootfs/etc/s6-overlay/s6-rc.d/forwarding/run
🧰 Additional context used
🪛 LanguageTool
tailscale/DOCS.md

[style] ~167-~167: Consider using “inaccessible” to avoid wordiness.
Context: ...stant (i.e. not on all interfaces), are not accessible directly from the tailnet when userspac...

(NOT_ABLE_PREMIUM)

🔇 Additional comments (1)
tailscale/DOCS.md (1)

72-72: New Configuration Option: forward_to_host Added in YAML

The new option forward_to_host is correctly added with a default value of true in the configuration snippet. This aligns with the PR’s objective of forwarding incoming tailnet connections to the host when userspace networking is disabled.

@frenck frenck marked this pull request as draft February 20, 2025 21:06
@frenck
Copy link
Member

frenck commented Feb 20, 2025

TLDR: Without this, users have to enable subnet routing only to access the host

yes! Great, right? They decide?

eally different user experience compared to the general Tailscale client

Yup, tailscale was never designed to run from the container.

Without this, there would be no way to access anything on the host.

I'm not really sure if that is an disadvantage?

@lmagyar
Copy link
Contributor Author

lmagyar commented Feb 22, 2025

Removed the option and the docs, now this is always enabled when userspace_networking is disabled.

@lmagyar lmagyar marked this pull request as ready for review February 22, 2025 18:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants