Good morning,
I recently moved to the universities dormitory and they have a specific way how to enable the internet connection. They require me to connect to the network via Cable, set up a specific static IP and then enable the Internet connectivity by ssh'ing to a special IP with my own account and password. As long as this ssh session is open, the internet connection is active. If closed, then it is lost.
My setup right now is like this: I connected an OpenWRT-based TP-Link router (TP-Link TL-WR841N/ND v9) to the dormitory's network. My devices are connected to the router's wifi.
To get an internet connection, right now I am doing this:
connect to the router via ssh
connect to the internet via ssh on the router
So basically I am having two running ssh sessions. This is quite annoying as my laptop has to be on and running if I want to have an internet connection. My idea would be to keep the ssh session on the router running all the time. For this, however, I would need to keep the ssh session running in the background of the router.
Starting the second SSH with & skips the password entry. So I have to get it back to fg, enter the password and the process is back in the foreground. CTRL+Z appears to be not working on OpenWRT.
The only thing which could skip the password entry would be connecting with a key, but the server I am connecting to is not allowing that.
Anybody having other ideas?
You can do multiple things to solve this
Create a script(which will connect to internet) in router and schedule it in a cron job
If nohup/tmux is available in the router, execute the commands with them so that they keep alive when the ssh session is terminated.
So, looks like I solved the problem.
As nohup/tmux is not available on the router, I had to find an equivalent. Fortunately, screen is available for my router. With screen, you can start the ssh for the internet in a separate screen. When it's running, you can simply detach the screen and close the ssh to the router.
The ssh-connection for the internet will continue running in the background of the router.
The only drawback is that I have to reconnect manually, as soon as the router restarts.
Related
I've set up tailscale and connected to an exit node on my VPS on vultr.com. Predictably, I was kicked out and couldn't reconnect, as the VPS's public IP address has changed.
I can reboot the VPS and try again. What steps will I need to take? Does my VPS running behind an exit node even have a unique public address (which?), or does it need to be set up for something like port forwarding?
From looking at tailscale documentation, it looks like they came up with their own ssh, why? Why is the standard ssh inadequate for the purpose? I am not the admin of my tailscale network, and the admin is swamped right now. What can I do?
SSH uses TCP as transport and therefore requires the (srcaddr, srcport, dstaddr, dstport) tuple to be constant over the connection's lifetime.
I believe that since tailscale rotates connections dynamically, it is more suitable for use by clients than servers in a traditional client-server model, unless it provides an 'internal' virtual network over the distributed transport (which would kind of defeat the purpose of covering your tracks).
If you want to connect to your VPS over tailscale, you need to use their tools probably because of that. You can still connect directly to your VPS, though, through plain Internet, if it has any address of its own, and is not firewalled away (or similarly, NATed away). Your provider should either show you the address, or even better, provide access to out-of-band (like serial-port) command line access, where you can query the current addresses using commands like ip addr show.
In your Tailscale Admin console you should be able to see the machine's IP. Just use normal ssh and login that way.
So instead of ssh user#8.8.8.8 you'd do ssh user#100.64.0.1. Tailscale's own ssh client is useful if you want to hook deeper into their MagicDNS stuff, but it's not meant to be the only way to ssh into your machine.
If you run into errors, ping the machine you want to connect to (tailscale ping vps-machine-name). That should help you debug any tailscale client connection problems.
Today I found out I can not connect to my VM instance via SSH anymore.
I have checked and even re-added firewall rule to open port 22, yet I see the port is closed. I have done nothing that I can recollect that could have ended up closing that port.
I have also tried logging in via serial port, but I have no login password for that (I always let google just log me in with key).
Can anyone help me?
I have spun up a Google Cloud Compute virtual machine. It's a vanilla Windows Server 2016 image, and I can log in and see the desktop. I do that by downloading the RDP file and running it.
Due to a license manager for software I'm installing, I need to VPN to my own network. In "Settings -> Network", I add a new VPN connection (using the same creds I use on my machine) and click Connect. It makes an initial connection, verifies my credentials, but during the final stage, my RDP connection to the GCP VM ends.
What is really strange is that, sometimes, I can reconnect successfully after a few minutes and the VPN connection was successful. Sometimes I can't reconnect.
Any ideas?
The VPN connection added as such will be a force tunneled VPN which then adds a default route over the VPN interface on the VM disrupting your connection. The easiest way for maintaining the connection would be to do either of 2 things
Make the VPN split tunneled and add a route for the licensing box. You can do this by using the Set-VPNConnection Powershell commandlet and then adding a route using the route add command in an administrative command prompt
Add a more specific route for the IP Address by which u access the VM using the route add command
UPDATE: Simply setting the VPN to use split tunneling in PowerShell solved the problem.
Use: (Replace "VPNsName" with your VPNs Name)
Set-VpnConnection -Name "VPNsName" -SplitTunneling 1
We have a Win Server 2008 box being hosted (dedicated) for us.
I need to connect to one of it's DB's from a server in our LAN.
What started out as a "sure, I'll just throw that together for you real quick" project has turned into a week-long hair-pulling pile of WTF :)
I am able to RDP into that server without fail or issue.
When I tried to connect to the DB, I got a generic "could not connect" error, so I went hunting.
Telnet attemtps and pings time out.
Since then, we have tried endless variations of firewall settings (including wide open), and still ... no go.
In addition to our firewall, the hosting provider also has a firewall layer.
We turned on all logging, and we don't even see any connection attempts at our FW.
We then had the hosting provider turn on all logging, and they don't see any connection attempts either!
Hrmmmph
I'm at a complete loss.
Any suggestions?
BTW, while I'm comfortable enough with all this to explore and make changes, my experience with firewalls and stuff is fairly limited, so don't hesitate to dumb it down ;)
It is hard to give just one answer to this question, because the interim results of the problem analysis lead to different steps that you need to do next. It will more likely be a step by step help with tracing down the problem.
Do not trust any firewall setting (esp. not any that someone else did, and again esp. not if you don't know him), unless you tested it. Firewall settings are tricky and even experienced professionals get them wrong now and then.
In the guide below, I will write <win2008server> in commands where you have to put the name or IP of the windows 2008 server to which you want to connect. On the other side, I will use the expression "office PC" when I mean your workstation PC in the office from where you are trying to connect to the win2008server.
STEP 1: Checking the Endpoints
1.) Can you telnet to the RDP port?
On your office PC, try this on a command prompt:
telnet <win2008server> 3389
This is to make sure that DNS name resulution works for telnet, as well as network hardware and routing. It should, because you can use RDP to establish this connection. However, anything can get in between, like the telnet command being in any way configured nonstandard or being replaced for whatever reason on a company pc (sysadmins have strange ideas at times...).
2.) Can you telnet locally on the win2008server to the database?
When logged in using RDP on the win2008server, open a command prompt on the server and issue the command
telnet <win2008server> <database port>
That means you are trying to connect from the server to itself. This is to make sure the database port is open on the server.
STEP 2: Checking the Firewalls of the Endpoints
If for 1.) and 2.), your answer is yes it works, you have to test if either the remote side can not be reached or your location can not connect to the internet on the port you are testing (database port). You do this by replacing the respective other side with any other host on the internet for which you know it's reachable or can reach other servers. Typically, you google for a port checker ;)
3.) Check if the win2008server can be reached from another location than yours:
3.1.) Check if the RDP port of the win2008server can be reached from a third party location:
Google for port checker and take the first result (e.g. http://www.yougetsignal.com/tools/open-ports/ ). Type in the name or IP address of the win2008server and the RDP port, usually 3389 . Click on "check" and wait for the success or the timeout.
3.2.) Check if the database port of the win2008server can be reached from a third party location:
Do the same as in 3.1.), just with the database port instead of the RDP port.
4.) Check if you can connect to an outside server on the database port:
For this to work, you need to know a server or create one, which is somewhere outside on the internet, and which listens on the database port. You typically do this by keeping your private PC at home run and accessible through RDP or SSH, and there you open a server and configure your private internet router to forward the connection correctly.
Another way to do this test is webspace with SSH access. Many webspace providers nowadays allow for an SSH login (usually any webspace at $4/month and above).
Let's assume you have SSH access to any such third party place. You can use nc (netcat) there to open a server socket on the database port with this command:
nc -l <database port>
If it's your private PC at home, you usually have to also configure your private router and set up a dynamic DNS name for your internet access for the whole story to work out. You do not have this extra work with a webspace based SSH login. However, there you can not test ports below 1024 because you do not have the privileges. Good luck with this ;)
After you got this, try connecting to the port that you opened:
4.1.) From your office PC with
telnet <third party location> <database port>
4.2.) If 4.1.) does not work, also try with the port checker, because you might have gotten something wrong with setting up the server. Look at 3.) for this, and use the <third party location> and <database port> with the port checker (fourth party check).
STEP 3: Blaming ;)
At least one of the things should have failed by now and you can start calling people and letting them know about your tests and the results. You should be able to combine the results logically, but never start with that. Think about how to convey the information. Start out with your findings and then let them have a moment for their own conclusion. It can be difficult to tell someone in another company or department that their firewall isn't configured correctly. They might deny this even in the presence of proof. Be patient. Explain your findings again. Hint at the conclusion. This can be the trickiest part of the whole problem solution.
I have to say that today I had the same problem.
My solution was just to edit secpol.msc and disable all the FW profiles; then, run services.msc and also disable Windows Firewall service.
After this server was pingable for me.
I'm running automated testing procedures that emulates keystrokes and mouseclicks 24/7.
Although it runs fine locally, on an RDP session it stops running once minimized or disconnected. Apparently, the GUI doesn't exist if you can't physically see it on the screen.
There is a registry work-around for keeping the GUI active for minimizing the window, but I know of no way to keep it alive after disconnect.
Ideally, I would have this run on the server Windows console session which would not care about being disconnected but in a hosted environment (I tried Amazon and Go Daddy) there is no way to access the console session.
Does anyone know how I can get around this? Basically any solution that allows me to run my application on a VPS. I need the reliability of a host but the flexibility to run it as if I was sitting right in front.
Yes, you can.
There are two types of sessions in Windows: The "console" session which is always active, and there can only be a max of one of, and "terminal" sessions, a la RDP. Using "rdpwrap" on Github, you can have an unlimited number of terminal sessions.
RDP sessions will become "deactivated" when there is not a connection to them. Programs will still run, but anything that depends on GUI interaction will break badly.
Luckily, we may "convert" a terminal session into a console session instead of disconnecting from Remote Desktop normally by running the following command from inside the terminal session:
for /f "skip=1 tokens=3" %%s in ('query user %USERNAME%') do (tscon.exe %%s /dest:console)
This will disconnect you from the session, but it will still run with full graphical context. This answers your question. You can reconnect to it and it will become a terminal session again, and you can do this infinitely. And, of course, autohotkey works perfectly.
But, what if you need more than one persistent, graphics-enabled session?
To get an unlimited amount of graphics-persistent sessions, you can run Remote Desktop and start terminal sessions from within the "main" session described above. Normally Remote Desktop prevents this "loopback" behavior, but if you specify "127.0.0.2" for the destination, you will be able to start a terminal session with any number of the users on the remote machine.
The graphics-persistentness will only be present on terminal servers if they are not minimized, unless you create and set RemoteDesktop_SuppressWhenMinimized to 2 at the following registry location:
HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client
With this you can get an unlimited number of completely independent graphics-persistent remote sessions from a single machine.
This could be a workaround, altough I have not tried it myself and it involves having another machine
Let's assume that at the moment you are creating a session to myserver.com
Local Client ----> myserver.com
Instead of doing that, you could try having a separate server (let's call it myslave.com) and use that to establish a session
Local Client ----> myslave.com ----> myserver.com
Then if you disconnect the Local Client ---> myslave.com session the GUI of the session between myslave.com ----> myserver.com should remain active.
It will work only if you are connected to the console session of myslave.com.
I found a similar way. I had same problem, i downloaded rdp wraper which allows you configure multiple session rpd server and one tool which is included (rdpchecker.exe) allows you connect to localhost so you can connect to your server from your server and you dont need that middle client.
This could be a workaround, altough I have not tried it myself and it involves having >another machine
Let's assume that at the moment you are creating a session to myserver.com
Local Client ----> myserver.com
Instead of doing that, you could try having a separate server (let's call it myslave.com) and use that to establish a session
Local Client ----> myslave.com ----> myserver.com
Then if you disconnect the Local Client ---> myslave.com session the GUI of the session
between myslave.com ----> myserver.com should remain active
If you are using a windows server you don't even need another machine.
1) Connect to the server with the remote desktop connection (#con1).
2) Create a new alias for your server system like "127.0.0.2" in Windows\System32\drivers\etc\hosts .
3) Now establish a new remote desktop connection from your windows server (in #con1) to itself (#con2).
4) Finally start your GUI needing application e.g. UI-Path in #con2 and then close #con1.
I ran into the same problem and noticed that using VNC (TightVNC) to take over the remote machine seems to solve the issue. I guess VNC uses the console screen. Once activated and logged-in it stays logged-in, also after a VNC disconnect. Make sure that the screen never turns off in the power options.
Take note that keeping the console logged-in on a VPS is in general not recommended.