Reading https://docs.traefik.io/routing/routers/#rule_1 it seems that the only way to route bare tcp requests through traefik is the HostSNI rule, is this it? I mean, fair, TCP doesn't have much else to demultiplex on except for ports and options - even SNI isn't bare TCP, right?
Are there any future plans to include any other rules for tcp routing in traefik?
Related
To keep things simple, I think its better to just check the TCP port for liveness and readiness in kubernetes as it doesn't require knowledge of health-check endpoint (HTTP path) but just the port number. Any guide on the disadvantages of just relying on the TCP port for service health-check is greatly appreciated, please assume that the pods are not proxy for some other service and all the business-logic is in the pods itself.
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
In my experience HTTP is chosen over TCP when you have a reverse-proxy sidecar in front of your app in the same pod, e.g. nginx. In this case, nginx will always accept TCP even when the app is not ready yet. Thus you'd want HTTP.
Otherwise:
if this is an app server listening directly on a port
you know it starts to listen only when fully loaded
you don't want any additional logic inside /health (like check db connection)
If all of the above is true - just use TCP.
TIP You don't even need to know the port number for TCP, you can use named port: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#use-a-named-port
I'm not sure if this is possible, I have looked around the web but couldn't find anything.
I running kubernetes and using NGINX ingress, I can do layer 7 routing, allowing me to use a single port for incoming requests, then based upon the request, route that request to different services.
My question is: Is there anything like that, that could do the same or a similar thing for TCP & UDP ports?
e.g: So I can route traffic arriving at, lets say, TCP 9071 then route that traffic to different services based on some sort of flag/or traffic content.
It would be good to know if this is not possible as well?
You are not going to be able to route based on a URL because that's layer 7 HTTP(S). However, you can do TCP/UDP load balancing which is supported by most open source proxies.
Nginx Ingress Controller TCP/UDP
Traefik Ingress TCP/UDP
HAproxy TCP
✌️
I enjoy hipache, a HTTP reverse-proxy that uses Redis, but cannot support (in my experience) TCP. I really like easily scripting my basic (e.g. HTTP) reverse proxy needs, but the lack of any UDP or TCP reverse proxy is causing problems--I constantly have to remember that foo.com:49182 is mysql, instead of just using mysql-test.foo.com.
The only 'solution' I can think of is to set up a TCP reverse proxy on a different port (maybe 8080) and use that for the applications that need direct TCP proxying e.g. mysql-test.foo.com:8080. Similarly for UDP.
Is there a better way?
The author of hipache has some ideas. See
https://github.com/samalba/hipache-nginx
and
http://blog.dotcloud.com/under-the-hood-dotcloud-http-routing-layer
Maybe you can have a combination of haproxy and nginx as others follows.
This is a network programming question. I need to block all HTTP traffic using a layer 4 firewall (i.e it can look headers only upto TCP/UDP layers ). Is this possible?
As I was searching for a more accurate answer , I got to know that even if we cannot access HTTP header, we can access HTTP message field using layer 4 firewall.
No.
You can drop all TCP port 80 and port 443 traffic, but this might include traffic that isn't HTTP. (80 and 443 are open almost everywhere, so people (ab)use them often.) It will also miss HTTP traffic that happens on non-standard ports. (People do HTTP to port 8000 or 8080 or 8088 or 8888 all the time, in part because you don't need CAP_NET_BIND to be able to use high ports, in part because the numbers are easy to remember if port 80 is already used for something else.)
You can use the incoming port (ie 80) to detect HTTP traffic.
However you can't be 100% sure that's HTTP. But since it's the common port fort HTTP, I don't think many other applications use the port 80 for their communication.
If another port is used with HTTP protocol, you won't be able to block it this way, but it's a start.
Which of the following ports is the best one to use for a program. I'm working on using a custom protocol still under development. I'm looking for one that will be accessible to virtually every host that is connected to the public Internet (that is, every host that can view websites can use this port). The three main options are:
port 53 UDP (DNS)
port 80 TCP (HTTP)
port 443 TCP (HTTPS)
Which of these is most widely accessible over the Internet, including all ISPs, corporate firewalls, etc.
All of those ports are used by well-known services, and you should use none of them (if your product is not a webserver or a DNS server.) DCCP Well Known ports SHOULD NOT be used without IANA registration. If your service is commercially viable or has benefits for the network as a whole, consider registering it for a lower port number: The registration procedure is defined in RFC4340, Section 19.9.
For experimental use, use a port between 1024 and 49151. Remember that even those ports should be registered with the IANA as soon as your service goes "live".
Regarding firewalls: You cannot predict if your service will be available to any network at all. Even if you use port 80, you probably will run against firewalls that do content checking.
Not port 53. Toss-up between 80 and 443. If you make your protocol look sufficiently like HTTPS that a proxy will forward it the same way, then maybe 443 is your best choice.
As all the ports you've nominated are used for particular well-specified protocols, it's a very bad idea to use these for a different protocol. There's a convention that for a well-known port, there's a corresponding protocol, and if you break this convention, then at the least you're going to cause confusion, and at worst be suspected of nefarious intentions and be blocked. Martin's answer points you in the right direction.