I am attempting to connect to Redshift using the RPostgres package.
Normally this works fine, however I am using VPN to connect to my companies network.
Running the following, with placeholders for sensitive info obviously:
library(RPostgres)
con <- dbConnect(RPostgres::Postgres(),
dbname = "db",
host = "host.redshift.amazonaws.com",
port = 5439,
user = 'me',
password = 'password',
sslmode = 'require')
Getting the following error:
Error in connection_create(names(opts), as.vector(opts)) :
could not connect to server: Operation timed out
Is the server running on host "host.redshift.amazonaws.com" (IP Address) and accepting
TCP/IP connections on port 5439?
I am not familiar with VPN or how it may effect connections.
Apologies for the generality of this question, however hoping there are some ideas to at least get me started on finding a solution.
Go to your Redshift console, and see the security group which is used for your Redshift cluster, in the security group settings, view Inbound settings, those should have enabled connections from your IP. But as you're using a VPN, IP being allotted to you by the VPN might not have been allowed to connect as an inbound connection.
So either you can permit a range of IPs to connect via the security group inbound permissions, or permit all IPs to connect.
Related
I'm trying to use nmcli to configure a VPN in a remote machine.
The issue is that networking interfaces are google managed.
I've created a VPN connection with
sudo nmcli connection add type vpn vpn-type openvpn ifname test-vpn vpn.data "ca = /home/myuser/ca.vpn.cer, connection-type = password, password-flags = 2, port = 443, proto-tcp = yes, remote = vpn.mycompany.com, username = myuser#company.com"
But when I try echo "vpn.secrets.password:mypass" > pass.txt; sudo nmcli connection up vpn-mangel-vpnt passwd-file pass.txt it raise Error: Connection activation failed: Could not find source connection.
I've tried to change /etc/NetworkManager/NetworkManager.conf to set ifupdown manage to true:
And adding those lines in /etc/network/interfaces
With that, the VPN connects (Wrong pass fails) but the VPN is not connected to machine network
After many attemps and error, deleting new interfaces that are dynamically created I finally got the vpn connected, and removing folders from run/interfaces I successfully connected to vpn and could check it with a ping. Some minutes later o lost the ssh connection.
I've restarted the machine, but if I connect to the VPN lose the ssh connection.
And I can't replicate in a new instance.
I don't have much idea about VPNs and Interfaces so could someone guide me in what look for?
Google Cloud Virtual Private Cloud (VPC) networks are by default isolated private networking domains. Networks have a global scope and contain regional subnets. VM instances within a VPC network can communicate among themselves using internal IP addresses as long as firewall rules permit. However, no internal IP address communication is allowed between networks, unless you set up mechanisms such as VPC Network Peering or Cloud VPN.
My company has an on-premise network which is opened by OpenVPN server.
In the ordinary scenarios, I used to connect to that server very easily.
However, when I tried to that server from the OCI compute instance which I connected by SSH from my laptop, there exist some problems. As soon as I try to connect VPN server, my SSH connection is closed.
IMHO, this may occurred because VPN connection changes network information and so my SSH connection might be lost.
I tried to look around to find out how to connect to VPN from OCI, but almost everything was using IPSec protocol which Oracle provided, others were about builting OpenVPN Server on the OCI instance.
I'm very novice for the network structure. So, please give me some hint to resolve this problem.
Thanks,
I get the following:
You have Ubuntu 18.04 VM on a Public Subnet in OCI
You have OpenVPN Server running on On-Prem.
You would like to access your On-Prem from Ubuntu VM on OCI.
If I understood it correctly, the best way is to set up IPSec VPN. It isn't that hard if you hit right steps. At the high level, you will be doing the following steps. I have used IKEv1 in my attempts in the past.
OCI:
Create a DRG
Attach/Associate it to your VCN
Create a CPE (Customer Premise Equipment) and mark the IP Address of OpenVPN server to it.
Create an IPSec Connection on the DRG. It will create two Tunnels with its own Security Information.
Set up Routing on associated subnet (i.e., one that hosts Ubuntu VM) so traffic associated to On-Prem CIDR are routed to DRG.
On-Prem:
Create necessary configuration to create the Tunnels upto OCI (Using the configuration information from previous steps such as VPN Server IP Addresses and Shared Secrets)
Set up Routing so that the Traffic destined for OCI CIDR ranges are sent to associated Tunnel Interface
This ensures that you can create multiple VMs on the OCI Subnet all of which can connect to your On-Prem infrastructure. OCI Documentation has sufficient information in setting up this VPN Connection.
Alternatively if your only requirement is to establish connectivity between Ubuntu VM on OCI to OpenVPN server On-Prem, you might use any VPN Client software and set it up. This doesn't need any of the configuration steps mentioned above.
Worker nodes in private subnets have private IP addresses only (they do not have public IP addresses). They can only be accessed by other resources inside the VCN. Oracle recommends using bastion hosts to control external access (such as SSH) to worker nodes in private subnets. You can learn more on using SSH to connect through a bastion host here - https://docs.cloud.oracle.com/en-us/iaas/Content/Resources/Assets/whitepapers/bastion-hosts.pdf
I recently migrated a site to a new server and am now trying to replace the old domain by the new one using this tool suggested in the wordpress codex.
The SQL instance and the VM are both in the same region and are connected using a cloud sql proxy, however when I try and connect to the database via the searc-replace tool, I get connection refused:
EDIT:
The command used to start the sql proxy is the following:
localhost:/cloudsql/project-name:region:sql-instance-name
It is the same I use in the config file to connect the site to the db.
"Connection Refused" error occurs when an application attempts a TCP connection but there is either no service listening on the target address and port or a firewall rejecting the connection.
First, lets make sure you are connecting on the right port. Run sudo netstat -lntp and look for cloud_sql_proxy. For example you might see
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 71313/cloud_sql_pro
indicating cloud sql is listening on port 3306. If you saw this, you should change the port in your tool to 3306.
If netstat does not show any cloud_sql_proxy line, then it isn't listening on TCP. While TCP isn't always needed for MySQL, it looks like the tool your are using does need it. Make sure you start cloud_sql_proxy with -instances=<INSTANCE_CONNECTION_NAME>=tcp:3306
Second, lets make sure you are connecting on the right address. This should be localhost without :/cloudsql/project-name:region:sql-instance-name after.
If it still doesn't work after those two, use sudo iptables -L to look for firewall rules blocking the traffic. I believe it's unlikely that you have a firewall stopping local traffic, however.
An alternative to using the Cloud SQL Proxy is to connect directly to your instance. To do this:
Find the external IP address of the VM you are running the PHP tool on.
Grant access for that IP address to your SQL instance, with the instructions here
Because MySQL can have different username/password depending on where you connect from, ensure there is a username/password combo for host %. instructions here.
Use the tool, with the username/password from (3), port=3306 and host=the IP address of your SQL instance
When you are done, remove access from the IP address to your Cloud SQL instance.
I can't access remotely my postgre database. My fellow is making a QT project that access the database from my web-server. It's very close to the problem from this guy: Is the server running on host "localhost" (::1) and accepting TCP/IP connections on port 5432?
And with some research in google, all solutions point to set the listen_addresses property in postgresql.conf like this:
listen_addresses = '*'
and in pg_hba.conf add this line in the IPV4 connections
host all all 0.0.0.0/0 trust
I've already done it, and also have created an exception in ufw
5432/tcp ALLOW x.x.x.x.x
when x.x.x.x is the ip I want to give access.
I've also tried some variants to the configuration above ,like
listen_addresses = 'localhost, x.x.x.x'
and
host all all x.x.x.x/32 md5
The error message of the linked question happens only when trying to connect locally. That's what ...running on host localhost... means.
When connecting to a remote host, the client doesn't set localhost in the host field, but the IP address or name of the remote machine (well, unless using a SSH tunnel but it's not mentioned here).
Otherwise please indicate the exact connection parameters of the client and the exact error message.
When some network connection isn't working right, one thing in my bag of tricks is to try opening a telnet connection to it. I don't expect to be able to do anything useful with this connection, but knowing if I can or can't connect is helpful in diagnosing the problem.
So today we had a problem where our app server couldn't open the JDBC connection to our database. However, it works fine when the app server is on the same physical box as the database. Aha, I thought, there must be a firewall blocking that port. So I tried to telnet to that port, and couldn't connect. As a control though, I also telnetted to a database on a box we could connect to and that failed as well. So, the situation is, somehow whatever is listening on that port accepts a JDBC connection from JBoss, but rejects a connect from telnet. How does it distinguish these two connections? Different protocol? Password embedded in the connection request?
Sounds like the database is only accepting connections on the local interface. Is your app server configured to connect to the database via its IP or via either localhost or 127.0.0.1?