config ovpn to connect directly (not through server) to an ip range - vpn

As title reveals my problem, I have configured an OpenVPN server, and it works perfectly, except for a specific IP range (due to restrictions- not on my side).
Now I want to config my .ovpn file to connect directly (not through server) to that IP range to prevent issues like pinging time and ip location settings.
-Is it possible to edit .ovpn file and send it to clients to simplify/solve their connection to that range?
-Is it possible for any client to config any .ovpn file to bypass any IP/Domain, by themselves?
Thank you
I thought that it can be possible to #comment that ip range in ovpn file, but I don't know how to do that.

Related

Can I tell within application code, on what outermost port of my server the app is accessed?

I'm trying to open with the question that I really want answered. I want the URL at which outside users can access a particular part of my application.
In my server's setup, we're using Nginx as a reverse proxy, so my app is confugured to be at port 9000. But I can't point users at this, because they can't access that port. Users can access port 8080. But this is part of my system configuration and could (I think) change. Also it does change from development to staging to production. So, I would like to avoid hard-coding this if possible.
So then my question, can I somehow, dynamically, tell the "outermost" port that an incoming request is received at? Possibly through passing a header down from Nginx? I'm thinking of X-Forwarded-For, except I want to know what URL the client contacted to reach me (the server), not what IP address the client is contacting the server from. Is this possible?
$server_port variable holds the port the client connected to.

How do I channel all browsing traffic through encrypted sTunnel session?

I have sTunnel running on my client and server and can't seem to get my head round how I can have it running in a sort of "silent mode" whereby if I were abroad I could fire up the sTunnel connection on my client, connect to my server and then my browsing traffic connection would behave as if I were in the UK (an encrypted proxy).
On the client conf I have:
accept = localhost:xxx (I understand this means the local sTunnel installation listens on xxx port and grabs any traffic sent on that port).
connect = serverip:xxx (This is the instruction of where it needs to be forwarded, i.e the server).
On my server:
accept: clientIP:xxx (the source IP address of my client)
connect: localhost:xxx (the loopback address of the server)
What am I failing to see here? As I see it I can only use this tunnel if I explicitly target a port with my browser and even then wouldn't it only make it as far as the sTunnel server and not onward to the website intended? Do I need to setup proxy settings in the browser?
thanks a lot
I'm not sure stunnel is what you're looking for here.
What you describe would be best accomplished with OpenSSH, and its dynamic SOCKS5 proxy functionality, e.g. ssh -D1080 from the client.
This generally doesn't require any extra settings on the server-side (unless it was specifically disabled by your system administrator), and then on your roaming client-side, you simply establish an SSH connection to your server as per usual, but add an extra -D1080 parameter to your ssh invocation.
Or, if using PuTTY, set up dynamic port forwarding within Connection, SSH, Tunnels, Source port of 1080 and Destination of Dynamic, click Add.
Subsequently, change the settings of your browser to use SOCKS proxy at localhost, port 1080, and also make sure to specify SOCKS v5 and ensure that the checkbox for resolving hostnames remotely is set, too.

what is the difference between hosts file and nginx configure file?

if I have an entry in my hosts file ,and also the hostname is in the server block of the nginx configure file ,I wonder which file is applied first and does what specific,could someone tell me ?
The hosts file is used by your OS to resolve hostnames to IPs and is usually evaluated first (can be customized - at least on unix based OS). If you tell an application to look for some host, e.g. www.example.com, it looks up the name in the hosts file and uses the IP to connect to that host. In case the hostname can't be found in the file, it will usually ask the configured DNS servers for it.. See Hosts File and DNS for more info.
The hostname in the server block on the other side is used by nginx to determine the appropriate action to be taken. nginx evaluates the HOST header in the request and tries to match it against the values configured in the server_name variables in each block. See Server names and How nginx processes a request.

Intermittent 'the remote name could not be resolved'?

I have an ASP.NET application that I use to read the contents of a web page by a HttpWebRequest frequently. There's no problem with the remote address and my application is always working fine.
While I don't change anything, sometimes (about once a day) I get this error:
the remote name could not be resolved.
Why a previously resolved DNS name sometimes fails to be resolved?
The intermittent nature of this is going to be extremely difficult to resolve and it's going to take a configuration change instead of a code solution. (hint: read everything ;)
I would guess that the remote servers DNS is set to expire pretty often. Probably daily or maybe even every 12 hours or so. This is the TTL (time to live) setting. Admins sometimes set this to an artificially low level if they need the ability to quickly move the site to a new server.
You can determine how often it expires by going to a command prompt and running:
nslookup
set debug
www.theserverdomain.com
At the top of this will be a section that says "AUTHORITY RECORDS:" with an item under it that says "ttl".
Now, (and I'm making an educated guess here), what's probably happening when you query your DNS server to resolve that host name your server will have this value cached.
However, once it expires the your server will have to contact another server upstream to get the ip address resolution, called DNS forwarding. If there are a lot of hops between yours and the remote server OR if one of the DNS servers between the sites is overloaded then it could timeout and send back the message you are receiving.
If this is true then the ONLY thing you can do is hardcode the DNS and IP address combination in your web servers hosts file. This is usually at C:\Windows\System32\drivers\etc and is a file named "hosts". There is an example on how to properly edit this within the file itself.
Once you create the host mapping in that file, your web server will no longer have to contact the DNS server to perform name resolution and it won't matter what the TTL is set to.
The only danger here is if they move the web site to a new IP address. At which point you could simply update your hosts file again...
The first thing I would check is if DNS is no longer correctly configured or malfunctioning.
Try (from a Windows command line)
nslookup MyDnsNameHere
and see if you get the IP you would expect.

SSH Port forwarding causes local browser to lose port qualifier?

We've set up port forwarding so that our users can access the web server on server foo through a SSH tunnel.
The port forwarding causes requests to 999 on the local machine to be forwarded to port 80.
On their own machine they open the SSH tunnell and then enter into their local browser ...
http://localhost:999/d/a.html
... on their local browser and their local browser receives the equivalent output to :
http://foo/d/a.html
This is all fine. However within a.html is a relative link to b.html (the link is just plain "b.html" - no virtual directory, no host name). The browser inteprets that link as being ...
http://localhost/d/b.html
... that is the port qualifier has been lost and so when the link is used instead of it going down the SSH tunnel the client machine attempts to resolve the address itself and finds it can't.
I assume this must be a common problem but how is it resolved ?
I'm answering my own question here. Based upon the above comments I've reviewed what's happening and it is (almost certainly) something unrelated to the tunnelling. Please ignore the question and thanks for your time.

Resources