port forward ssh from traefik reverse proxy on docker to a k3s container



  • I'm running a k3s cluster (1 master + 2 workers) and a docker traefik container on the same host (master). The traefik docker container is actually doing the reverse proxy stuff for tls which is working already on ports 80 and 443 for my different subdomains. I'm trying to get ssh working (for only one subdomain) too but without success so far.

    • port 22 is open through ufw allow (on Ubuntu 22.04)
    • traefik rules are set as following:
        tcp:
          routers:
            giti-ssh:
              entrypoints:
                - "https" # tried also with a ssh entryoint
              rule: "HostSNI(`*`)"
              tls: {}
              service: giti-ssh
          services:
            giti-ssh:
              loadBalancer:
                servers:
                  - address: "10.42.0.232:22"
    
    • k3s is running flannel and metallb where the externalIP-range is at 10.42.0.230-250
    • ip a shows (the interesting parts):
    2: ens192:  mtu 1500 qdisc mq state UP group default qlen 1000
        link/ether 00:50:56:19:ea:c3 brd ff:ff:ff:ff:ff:ff
        altname enp11s0
        inet "private"/32 metric 100 scope global dynamic ens192
           valid_lft 36147sec preferred_lft 36147sec
        inet 10.42.0.200/32 scope global ens192
           valid_lft forever preferred_lft forever
        inet6 "private"/64 scope link
           valid_lft forever preferred_lft forever
    3: br-5014eb2ffdf2:  mtu 1500 qdisc noqueue state UP group default
        link/ether 02:42:7e:ab:72:98 brd ff:ff:ff:ff:ff:ff
        inet 172.18.0.1/16 brd 172.18.255.255 scope global br-5014eb2ffdf2
           valid_lft forever preferred_lft forever
        inet6 fe80::42:7eff:feab:7298/64 scope link
           valid_lft forever preferred_lft forever
    4: docker0:  mtu 1500 qdisc noqueue state DOWN group default
        link/ether 02:42:a5:03:77:2c brd ff:ff:ff:ff:ff:ff
        inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
           valid_lft forever preferred_lft forever
    7: flannel.1:  mtu 1450 qdisc noqueue state UNKNOWN group default
        link/ether 42:1b:d3:49:d3:6b brd ff:ff:ff:ff:ff:ff
        inet 10.42.0.0/32 scope global flannel.1
           valid_lft forever preferred_lft forever
        inet6 fe80::401b:d3ff:fe49:d36b/64 scope link
           valid_lft forever preferred_lft forever
    8: cni0:  mtu 1450 qdisc noqueue state UP group default qlen 1000
        link/ether e2:27:27:96:96:7e brd ff:ff:ff:ff:ff:ff
        inet 10.42.0.1/24 brd 10.42.0.255 scope global cni0
           valid_lft forever preferred_lft forever
        inet6 fe80::e027:27ff:fe96:967e/64 scope link
           valid_lft forever preferred_lft forever
    
    • the containers are set up and the service for the one for ssh is listening on port 22 as type: LoadBalancer
    • I can connect to that container through another service and IP on port 443 from the traefik reverse proxy but am missing something for port 22 and I think it has something to do with the traefik HostSNI or maybe the iptables....
    • versions: docker traefic: latest (just for testing, am going for a tagged version..) k3s: v1.24.6+k3s1

    I can't connect also through 1932/udp (minecraft), so I suppose running traefik on s.th. else then http(s) is harder....

    Can s.o. give me a hint on how to achieve this.

    Thanks in advance! jim



  • Your ip show does mention 10.42.0.0/32, 10.42.0.200/32. No traces of 10.42.0.232, though.

    From LAN/outside SDN: can you connect any TCP port, or ping that address? anything that answers? I suspect nothing would.

    In addition to that Traefik rule, you mentioned creating a Service ... Are you sure you did it right? Look at kubectl get svc -A | grep 10.42.0.200, that would give you a working example -- something with an externalIP/externalIPs set, or some status.loadbalancer.ingress array ... configuration may vary, depending on how external IPs were implemented and kube version, ..

    And by the way, creating such Services: are you pointing to your application directly, or is it sent to Traefik instead? Assuming the latter: are you sure Traefik actually listens on such port.

    Also, while Traefik should be able to process TCP or UDP trafic, unless you can easily have several Services & backends accessible through the same proto/port combination: involving your ingress controller here might not be necessary.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2