I am currently running consul agent as a service in the VM and it works well with http or unix:/// option, but I have a requirement where I need both http and unix socket has to be enabled... Is it possible? please let me know your thoughts. Thanks!
The addresses key supports specifying a space-separated list of addresses to bind to. You can use the following configuration to have Consul listen on an IP address as well as a Unix socket.
# config.hcl
addresses {
http = "0.0.0.0 unix:///tmp/consul-stackoverflow-example.socket"
}
Related
In MDN's proxy example, I have seen that they use 127.0.0.1:65535 as an invalid url
(link to the source):
const allow = "DIRECT";
const deny = "PROXY 127.0.0.1:65535";
...
function FindProxyForURL(url, host) {
if (blockedHosts.indexOf(host) != -1) {
browser.runtime.sendMessage(`Proxy-blocker: blocked ${url}`);
return deny;
}
return allow;
}
Is there anything special about port 65535? Is it safe to assume that no process will ever listen to that port?
In the documentation of Proxy Auto-Configuration (PAC) files, I did not see a straightforward way to block requests otherwise. For instance, there is DIRECT, PROXY, SOCKS but no REJECT or DENY. I assume that PROXY 127.0.0.1:65535 is the official way to deny requests.
Is it safe to assume that sending requests to 127.0.0.1:65535 will reject them?
Is it safe to assume that sending requests to 127.0.0.1:65535 will reject them?
No, it's not safe.
It's just the very last port on the local machine. I'm perfectly able to open it without any special privileges and send data to it.
They are simply using it as a valid address but a port that's unlikely to be used. Not the best solution, but probably good enough for example code.
There's no special stipulation and 65535 a valid port for a proxy. If you just happen to run a valid proxy there the example will fail to block.
Normally "9" is used as the default port for "discard service". 65535 is nothing special but the biggest possible port number. I assume they use it because they believe no one will listen to the port.
However, this approach is not safe because 1) anyone can write a server socket listening to port 65535; and 2) the port number might be randomly allocated to a client as ephemeral port.
In addition to the other answers, the Discard Protocol (port 9) is the closest equivalent to /dev/null. To quote from the Wikipedia article:
The Discard Protocol is the TCP/UDP equivalent of the Unix filesystem node /dev/null. Such a service is guaranteed to receive what is sent to it and can be used for debugging TCP and/or UDP code requiring a guaranteed reception of payload sent.
On various routers, this TCP or UDP port 9 for the Discard Protocol (or port 7 for the Echo Protocol relaying ICMP datagrams) is also used by default as a proxy to relay Wake-on-LAN (WOL) magic packets from the Internet to hosts on the local network in order to wake up them remotely (these hosts must also have their network adapter configured to accept WOL datagrams and the router must have this proxy setting enabled, and possibly also a configuration of forwarding rules in its embedded firewall to open these ports on the Internet side).
Also blocking requests via the proxy API is not the typical usage. Instead the webRequest API is better suited for blocking requests. There are discussions to change the example.
I assume that explains why there is no explicit support for denying requests in the PAC de facto standard, and why the workarounds of redirecting traffic to unused ports or domains are used.
Say I have a list of proxies - I pull out of one of these proxies. It's nothing but ip and port. From a programming level, you need to know the protocol to use such as socks5, socks5h, http, https... etc etc. Is there a way to retrieve what kind of protocol a proxy uses from the information given?
If you are using Node.js you can try check-proxy library, though it does much more than just checking protocol.
Your proxy server identify the port number for example 6080,9180,etc so you can easily identify the proxy server.
Your id address also private or public you can use 'proxy server ip address' that automatically create a virtual proxy network.
Example: Your private ip address is 172.16.10.158 you can use proxy server, your ip address will be 136.56.89.210. You can use public ip ex 125.124.85.69 change in to 179.68.36.49.
I have a ruby server based on TCPSocket (non-HTTP).
I have 2 different domains, both pointing with an A-Record to my servers IP Address (the same one). So, there are clients connecting to one of those domains.
Is it possible to tell which domain a client was connecting to?
I saw that this is possible in other protocols, but I'm not sure if this is based on manually added headers or really extracted from the basic tcp/ip connection. E.g. in PHP there is $_SERVER["HTTP_HOST"] which shows to which domain a client was connecting.
At the TCP socket level, the only things that are known are the source and destination IP addresses (and ports) of the connection. How the IP address was resolved via DNS is not possible to know at this layer. Even though HTTP works on top of TCP, HTTP servers have to look at the HTTP headers from the client to know which domain they are making a request to. (That's how the HTTP_HOST value gets filled in.)
One possible solution is to configure your server to have an additional IP address. This can be by assigning an additional IP address to the NIC or adding an additional NIC. Then have each domain use a different IP address. Otherwise, this is not possible and you may want to consider your application protocol on top of TCP to convey this information.
I'm running into some deployment issues using Akka remoting to implement a small search application.
I want to deploy my ActorSystem on a set of local cluster machines to use them as workers, but I'm a bit confused for what to put into my application.conf to make this happen. For example, I can use:
akka.remote {
transport = "akka.remote.netty.NettyRemoteTransport"
netty {
hostname = "0.0.0.0"
port = 2552
}
}
Each worker just runs the ActorSystem at startup.
This allows my worker machines to bind to their address when they start up, but then they refuse to listen to messages:
beaker-24: [ERROR] ... dropping message DaemonMsgWatch for non-local recipient akka://SearchService#beaker-24:2552/remote at akka://SearchService#0.0.0.0:2552
The documentation I've found for this so far only discusses deployment on my localhost, which is not so useful :). I'm hoping there is a way to do this without generating a separate configuration for each host.
Update:
Using an empty string as the hostname allows for contacting the host via the normal IP address. Addressing using the hostname itself doesn't work at the moment.
Setting “0.0.0.0” as host name will currently basically disable remoting, because that is not a legal IP to send to. Background: actor references get the configured IP (or host name) inserted in their address part when they leave the local system, and that is exactly their “pointer home” for other systems to send messages back.
There has been an effort by Scott which would enable a system to receive replies to a different address here, but that is not included yet—and we may well chose a different solution to this problem.
How can I set the manual proxy configuration on firefox, so that let proxy for all ipv4, but no proxy for all ipv6?
There is limited support for IPv6 addresses in browser proxy configuration rules, some support IPv6 address network/masks in this format [ff08::0/64].
There's additional limited support in proxy auto configuration files.
One answer with more references here: Serverfault "Using IPv6 Addresses in Proxy PAC"
This question may be more appropriate for SuperUser - but since this is programming - the javascript-based Proxy PAC is the way to go. IsInNet() or shExpMatch() can select IPv6 addresses.
function FindProxyForURLEx(url, host) {
if (shExpMatch(dnsResolveEx(host), "*:*"))
{
return "DIRECT";
} else {
return "PROXY myproxy:8123";
}
}
That doesn't make sense. Web browsers decide whether or not they are going to use a proxy server before finding out which address family is going to be used. If a proxy server is to be used, it's the proxy server that will resolve the hostname and choose which address family to use. The user agent will never even know which one was used. If no proxy server is used, then the user agent will be responsible for making the connection instead, using whatever address family is available.