Question 1

tailcat perf가 중계 DERP 경로에 대해 정수 초 단위의 --timeout을 사용할 때 "no reply to pings"를 반환하는 문제를 어떻게 해결하나요?

Accepted Answer

이것은 `waitForDirectPath`의 타임아웃 경계 버그입니다: `--timeout=5s` 또는 기본값인 `10s`처럼 정수 초 단위의 타임아웃을 사용하면, 마지막 ping이 데드라인까지 약 1초를 남겨두게 되어, 코드가 1초를 더 기다린 뒤 데드라인이 지난 후에 다음 프로브를 시작하므로 이미 응답한 릴레이 경로가 버려집니다.

임시 해결 방법: 다음과 같이 소수점이 포함된 타임아웃을 사용하세요:

```bash
tailcat --json perf --via-derp --timeout=5.5s <tc-addr>
```

영구 수정: `perf-relayed-path` 브랜치에 있는 수정 사항이 포함된 빌드로 `tailcat`을 업데이트하세요. 이 수정은 마지막으로 측정된 경로를 유지하며, 최소 하나의 pong을 받은 후 데드라인이 만료되면 해당 경로를 반환합니다; `no reply to pings`는 pong을 하나도 받지 못한 경우에만 보고됩니다. `--via-derp` 없이 실행하면 tailcat은 ping 타임아웃 대신 의도된 거부 응답을 보고합니다.

Question 2

Nix tailcat 빌드 오류 "go.mod requires go >= 1.27.1 (running go 1.27.0; GOTOOLCHAIN=local)"를 수정하는 방법은?

Accepted Answer

빌드가 실패하는 이유는 tailcat 커밋 `9148b22`에는 Go 1.27.1이 필요한 반면, flake의 nixpkgs 리비전은 `go_1_27` 1.27.0을 제공하기 때문입니다. `GOTOOLCHAIN=local`이 설정된 상태에서는 Nix가 다른 Go 툴체인을 자동으로 다운로드할 수 없습니다. "Fix, test nix flake" PR이 포함된 tailcat 리비전으로 업데이트하세요. 이 리비전은 Go 1.27.1을 소스에서 빌드하고, 오래된 vendor 해시를 갱신하며, Nix 샌드박스에서 불안정한 테스트를 건너뜁니다. `nix build github:tailscale/tailcat --refresh`로 다시 빌드하세요. tailcat이 자체 flake의 입력인 경우 `nix flake lock --update-input tailcat`을 실행한 후 다시 빌드하세요. 이전 리비전의 경우, `pkgs.go_1_27`이 1.27.1인 nixpkgs 리비전을 가리키도록 flake를 일시적으로 변경하거나 `pkgs.go_1_27`을 1.27.1로 오버라이드하세요.

Question 3

Tailcat `no-auth-ssh` 프로세스는 인증된 피어 노드 키를 어떻게 식별할 수 있습니까?

Accepted Answer

PR #89가 포함된 Tailcat 릴리스로 업그레이드하세요. `--allow`로 수락된 연결의 경우, Tailcat은 실행되는 서브프로세스의 환경에 `TAILCAT_PEER_KEY`를 설정합니다. 예를 들어 Go에서는 `os.Getenv("TAILCAT_PEER_KEY")`를 사용하여 직접 읽을 수 있습니다. 이를 통해 피어를 식별하기 위해 별도의 SSH 데몬을 실행하거나 두 번째 SSH 키를 요구할 필요가 없어집니다. 임베디드 Go 프로그램에서도 `Server.PeerKey`를 사용할 수 있으며, PR #88은 사용자 수준 SSH 키가 필요한 경우를 위해 별도의 SSH 공개 키 지원을 추가합니다.

Question 4

Server.Status()가 빈 Peer 맵을 반환할 때 tailcat 클라이언트 연결이 직접 연결인지 DERP를 통해 릴레이되는지 어떻게 확인할 수 있나요?

Accepted Answer

이 문제는 `locoBackend.Status()`가 피어 데이터를 요청하도록 하여 해결됩니다. `ipnstate.StatusBuilder`의 제로 값은 `WantPeers`를 false로 두기 때문에, magicsock과 wgengine 모두 피어 루프를 건너뜁니다. #116 수정이 포함된 tailcat 빌드로 업데이트하거나, 다음 한 줄 패치를 적용하세요:

```go
func (b *locoBackend) Status() *ipnstate.Status {
	mc := b.sys.MagicSock.Get()
	eng := b.sys.Engine.Get()

var sb ipnstate.StatusBuilder
	sb.WantPeers = true // required to populate Status.Peer

mc.UpdateStatus(&sb)
	eng.UpdateStatus(&sb)
	return sb.Status()
}
```

그런 다음 연결된 노드의 피어 상태를 확인하세요:

```go
st := s.Status()
p := st.Peer[peerKey]

switch {
case p.CurAddr != "":
	// Direct UDP path; p.CurAddr is the active endpoint address.
case p.Relay != "":
	// Relayed through DERP; p.Relay identifies the relay.
default:
	// No active path information yet.
}
```

수락된 연결을 해당 `key.NodePublic`에 매핑하려면, `RemoteAddr()`에 의존하는 대신 새로 추가된 `Server.PeerKey` 접근자를 사용하세요. `RemoteAddr()`만 추적해서는 직접 경로와 DERP 릴레이를 구분할 수 없습니다.

Question 5

주소가 공개 DNS TXT 레코드에 게시된 tailcat SSH 서버를 보호하려면 어떻게 해야 하나요?

Accepted Answer

공개 DNS에 게시된 tailcat 주소는 유출된 것으로 간주하세요. 이 주소에는 터널의 pre-shared key가 포함되어 있으므로 TXT 레코드를 조회하는 사람은 누구나 연결할 수 있습니다. 공개 DNS 레코드와 함께 `tailcat serve no-auth-ssh`를 사용하지 마세요. `--allow `로 서버를 시작하여 터널 액세스를 제한하도록 클라이언트 인증을 요구하거나, `tailcat serve ssh --ssh-authorized-keys `를 사용하여 SSH 키 인증을 강제하세요. 인증되지 않은 주소가 이미 게시된 경우, DNS TXT 레코드를 제거하거나 교체하고, tailcat 주소 또는 pre-shared key를 교체/재발급하며, 승인되지 않은 노드 또는 SSH 키의 연결이 거부되는지 확인하세요.

tailcat

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트