I'm having a problem with getting memcached to work when accessing it from a server that is outside the internal network AND using a different domain name. I'm not sure if one, both, or neither of these things are the problem, but it seemed worth noting.
From an internal server (int.edu), I can telnet the memcached server (mem.edu) and everything works great:
a1)
telnet mem.edu 11211
connection occurs
get foo
server responds
quit
quit
Because the above example, I know that my memcached server is working.
From an external server (ext.org), I can telnet the memcached server (mem.edu) but strange things happen:
b1.0)
telnet mem.edu 11211
connection occurs
get foo
server hangs until I get kicked off (within a few min)
b2.0)
telnet mem.edu 11211
connection occurs
get version
server responds
get foo
server hangs until I get kicked off (within a few min)
b3.0)
telnet mem.edu 11211
connection occurs
stats
server responds
get foo
server responds
get foo2
server responds
quit
quit
So as long as I issue a "stats" request before I issue any "get foo" requests, then everything works like normal. I have no idea why this is?
I have tried using the super verbose memcached logging, but there weren't any differences in the logs between the internal vs external server.
I have talked to my IT department and confirmed that port 11211 is open for DMZ addresses to be able to connect to the memcached server (which makes sense, since I can telnet mem.edu)
I have (unsuccessfully) googled and searched SO, but nothing seems to work.
I have used iptraf (sudo apt-get install iptraf) to monitor what traffic is occurring. This is another interesting part of the puzzle... Using the same examples as before for the external server (ext.org):
b1.1)
telnet mem.edu 11211
connection occurs
ext.org makes an outgoing request
mem.edu receives the request and responds
get foo
server hangs
ext.org makes an outgoing request
mem.edu NEVER receives the request
ext.org keeps making more outgoing requests until the connection ends and I get kicked off
b3.1)
telnet mem.edu 11211
connection occurs
ext.org makes an outgoing request
mem.edu receives the request and responds
stats
server responds
ext.org makes an outgoing request
mem.edu receives the request and responds
get foo
server responds
ext.org makes an outgoing request
mem.edu receives the request and responds
get foo2
server responds
ext.org makes an outgoing request
mem.edu receives the request and responds
quit
quit
ext.org makes an outgoing request
mem.edu receives the request and responds
Here is some info about our system:
Memcached version 1.4.4
Memcached was started from an init script, but here is the command used:
/usr/bin/memcached -P /var/run/memcached/memcached_11211.pid -d -p 11211 -u memcached -c 1024 -m 64 -vvv
Memcached server: mem.edu (CentOS 6.4) -- location:internal (behind firewall rules, etc)
Requesting server1: ext.org (Ubuntu 12.04.2 LTS) -- location:DMZ
Requesting server2: int.edu (Ubuntu 12.04.2 LTS) -- location:internal
Related
I need to explore the traffic from one program.
The program makes something like a connection through the WebSockets.
Fiddler displays this:
Request Headers: CONNECT 144.***:443 HTTP/1.0
Response: HTTP/1.0 200 Connection Established
End empty body.
But the HTTP analyzer displays full information after that response, and that information continues flowing. Very likely like WebSockets (one connection and receive more answers).
And fiddler display zero traffic.
How can I explore such traffic through the fiddler?
A CONNECT call is always the first command a client sends if it uses a Proxy. Translated CONNECT just means: Please start a connection to the following server and that port. Through that connection the real HTP calls are then transmitted. Therefore CONNECT is not a real HTTP
request.
Fiddler does not show the content of CONNECT requests/responses to port 443 endpoints because those connections are HTTPS/TLS protected (hence the shown data would be useless). You need to enable HTTPS decryption and install the Fiddler root CA certificate into the client app/OS to see the decrypted content of those connections.
I'm new to RADIUS, servers, and the like. There doesn't seem to be that much documentation on FreeRadius, and I need to get FreeRadius server (3.0.8) running RADSEC for test purposes.
I moved etc/raddb/sites-available/tls to etc/raddb/sites-enabled/ in order to enable "RADSEC".
Questions:
I understand that I need to have a server certificate as well as a public key. I am wondering on if I could get a fake certificate/key just for testing.
Also I'm not sure how I can test the actual server, there's the radtest command (I've been trying to run radtest -P tcp -x testing password 127.0.0.1:2083 10 testing123 but it's returns:
... new connection request on TCP socket
Listening on auth+acct from client (127.0.0.1, 40542) -> (*, 2083, virtual-server=default)
Waking up in 0.4 seconds.
(0) Initiating new EAP-TLS session
(0) Setting verify mode to require certificate from client
(0) Non-TLS data sent to TLS socket: closing
Closing TLS socket from client port 40542
Client has closed connection
... shutting down socket auth+acct from client (127.0.0.1, 40542) -> (*, 2083, virtual-server=default)
Waking up in 2.9 seconds.
... cleaning up socket auth+acct from client (127.0.0.1, 40542) -> (*, 2083, virtual-server=default)
Ready to process requests
Do I need to set up another server as a client so that they can perform the TLS negotiation? And once I do that, how do I get that server to communicate with this RADSEC server?
radtest is attempting a non TLS connect to the server. And thats the reason you are seeing that the server disconnects the connection immediately.
You can explore radsecproxy. It supports TLS (RadSec), as well as RADIUS over TCP. So it can happen as intermediary for the non TLS client and TLS server.
The Preamble
I start up my local SSH terminal at work behind a firewall, and connect to a remote server all the time without any problem.
The way Xdebug works, correct me if I'm wrong, is that it sends an "unsolicited" request to my network's port 9000. I actually initiated that action by sending the remote server an HTTP request through my browser with a POST/GET/COOKIE variable instructing xdebug to start up. But my network doesn't know that. All it knows is that it is getting a request on port 9000 from the internet. It doesn't know which computer in its private network to forward it to (without setting up port forwarding on the router), and can only ignore the request.
So if you can't do port forwarding, another option (and a much better one from what I can tell), is SSH tunneling. My computer sends the SSH request, the server responds. My router knows which computer in its network to route these responses to. Piggybacking on that SSH connection allows those "unsolicited" port 9000 requests from the remote server to get to me.
I think I understand that much.
I finally got tunneling to work, thanks to stackoverflow, but how it works is still fuzzy to me.
On the remote server, I tell Xdebug to connect to localhost (not to my ip via xdebug.remote_host=173.123.45.56, and not to xdebug.remote_connect_back=1 which also would end up at my IP) on port 9000. Connecting to localhost seems a bit weird, since I picture that as the server sending messages to its own IP address, as if it is sending messages into itself (but I think that connecting to localhost is probably fundamentally different than connecting to any other IP... I don't think the message gets routed out and back in to localhost).
On my computer at work, I open up an SSH connection on port 22, specifying a tunnel to/on port 9000, and remote port 9000. I've seen some explanations of the various settings here but still don't understand them. Some even seem to involve three machines. What seems to be happening though, is I'm connected as usual via port 22, but I've told the remote machine that I want to receive its port 9000 communications. I've specified "localhost" in my tunnel, and I suppose that might need to match the localhost in my xdebug.remote_host value. I wonder if I specified my IP address in both places (i.e. xdebug.remote_host=173.123.45.56 on the remote server, and same IP in my SSH terminal), would that work too?
So Xdebug on the remote server sends me a request to initiate a debug session. It comes through my port 22, but my SSH tunnel somehow makes it seem that it is coming in on port 9000. So my IDE that is listening on port 9000 receives the request and sends a response (also on 9000), which my SSH tunnel intercepts somehow and sends back to the remote server on port 22, where it is similarly spoofed into looking like port 9000 to xdebug.
The Crux
So what I'm really not clear on is, what exactly is the localhost in my SSH tunnel configuration referring to? Does it relate directly to the xdebug.remote_host=localhost value? Can I change them both to my IP address?
Are all of the remote server's outgoing communications on port 9000 being forwarded to me, or just some of them? E.g., if someone in Chattanooga initiates a debug session in their browser, will I receive Xdebug's response?
Are all of my outgoing communications on port 9000 being forwarded to that server? I.e. can I debug two applications on two different servers at the same time, with some of my port 9000 communications going one way and some the other, or would I need one port per local application? (I can use Google Chrome and Firefox browsers at the same time, both on port 80, for example.)
The tunnel consists of an SSHD listening to port 9000 (as well as 22) at your end and an SSHD listening to port 22 at the other end. When you connect your XDebug to your local 9000, the SSHDs intercommunicate and the remote SSHD connects to port 9000 at the remote. Thereafter your local port 9000 behaves identically to the remote port 9000: all data written to either end appears at the other end.
I've got dedicated server to run all my sites from.
I created domain and updated all DNS records to this server, everything is fine and propagated however when i try and receive mail nothing happens but it can send.
I went to dnsstuff.com and this is the error i got...
All connections to Mailservers port 25 have failed. The standard port
for SMTP transactions is 25, so your servers should be operating on
that port. It is recommended that it be fixed in order for your mail
service to operate properly. The Mail Servers that failed are:
xx.xxx.xxx.xxx | failed message send with: failed cx open with: failed socket connect with: Operation now in progress
/*****************
UPDATE
*****************/
Running a linux box using centOS.
The mailserver being used is, I believe, Postfix.
How do i fix this problem?
Check your firewall configuration on your server. If you can send from localhost (that is, direclty from your server), but mail can't be delivered from remote servers to your box, your firewall is the best bet to look at. Basically port 25 should be open to any IP. It's hard to give you specific details on how to configure your firewall, as you do not specify your OS and dikstribution. Most Linux distro's run some flavour of iptables. If iptables is what you have, you could try this command from the command line:
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
Before you open up your firewall, you might want to dive into configuring postfix. It would not be nice to the rest of the world if you started running an open relay. That will get your server blacklisted in no time. This artice on the postfix website will give you a decent start.
I have chosen QuteCom SIP client for windows to chat.I have installed and configured the account with my public server. My SIP server is kamailio.The connection to the server is not established. The application is connecting to the server for a long time.
Any help is appreciated.
If looks like keep connecting, then I guess the SIP messages don't get to the server.
You can install Wireshark to monitor traffic on windows host on port 5060 (the SIP port) in order to see if SIP messages are sent to the server.
On server, you can install ngrep for the purpose of seeing if traffic from the phone comes there. The command would be like:
ngrep -d any -qt -W byline port 5060
If you don't see traffic coming to the SIP server, then might be a firewall or an ALG between the client and the server, or, a firewall even on client host or server itself.
If it is something in between (not on client host or server), then you should try to use TCP or better TLS.
Note that if you have the firewall on the server, you will see the SIP packets coming on the network, but they will be dropped by the kernel before getting to application layer. Typically on Linux you can see the firewall rules with:
iptables -L
If the SIP packets come to the server, then set debug=3 in kamailio.cfg, restart kamailio and watch the syslog file (e.g., /var/log/syslog or /var/log/messgaes) for kamailio-specific debug messages -- you should get hints of what happens during processing.