Here is what i have:
GCP instance without external IP (on VPC, and NAT), and it accepts HTTP HTTPS requests
firewall allows ingress TCP for 0.0.0.0 and also for IAP's IP 35.235.240.0/20 on all ports for all instances
I ssh to the instance via IAP and run the application in the terminal on port 5000 and 0.0.0.0 host and leave the terminal hanging, but when I connect in parallel through cloud shell and ssh to this instance through IAP, and then click on web preview on port 5000, I get "Couldn't connect to a server on port 5000".
I have said that it could be a firewall rule blocking IAP, so that's why I gave access to all ports for IAP (for testing)
P.S: the process has been done on a VM with external IP and it got validated ( but without the need to connect to cloud shell to do web preview, I checked the UI with IP:port in the browser )
What did I miss?
You may be following the guide on Building Internet Connectivity for private VMs and this part on Configuring IAP tunnels for interacting with instances and the use of TCP Forwarding in IAP. By Tunneling other TCP connections:
"The local port tunnels data traffic from the local machine to the remote machine in an HTTPS stream. IAP then receives the data, applies access controls, and forwards the unwrapped data to the remote port."
You can create an encrypted tunnel to a port of the VM instance by:
gcloud compute start-iap-tunnel INSTANCE_NAME INSTANCE_PORT \
--local-host-port=localhost:LOCAL_PORT \
--zone=ZONE
I guess you want to use INSTACE_PORT and LOCAL_PORT the same, 5000.
Be aware of it's known limitations.
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.
I have got chef-server installed on a centos machine.
Everything is working as expected except that I cannot access the chef-server web interface from another machine on my local network.
I can access the web interface from the centos machine itself:
telnet mychefserver.local 4000
Connected
If I do the same from my machine I have got:
telnet: Unable to connect to remote host: No route to host
I can successfully ping mychefserver.local from my machine
Any idea how to configure nginx with chef-server to access the chef-server from the network?
Since Chef Server 10, the web interface uses normal HTTPS (TCP 443), it only listens on the high ports locally, and nginx proxies as needed to the different backend services. I would try with a normal web browser as telnet isn't exactly great at error messages. Normally I would expect that to mean telnet is getting TCP transmission errors, but maybe it is just confused? If it is really a TCP transmit error then more likely the internal DNS is having issues. .local often means mDNS which has uneven support in some places, I would try an actual IP address to be sure.
My issue was iptables.
I stopped iptables and I can access the chef-server from my local network again.
I can access the app using localhost:3000 but I am trying to test from mobile devices locally, without having to deploy it. But I couldn't access the site.
I am allowing incoming request:
sudo ufw status verbose
Status: active
Logging: on (low)
Default: allow (incoming), allow (outgoing)
New profiles: skip
To Action From
-- ------ ----
3000/tcp ALLOW IN Anywhere
3000/tcp ALLOW IN Anywhere (v6)
I found that my ip address is 128.84.125.239 and so I visit 128.84.125.239:3000 and nothing happens.
This turned out to be an issue of using the right IP, or configuring the NAT of the router appropriately. Using a service such as cmyip.com will only provide you with your external IP address. This address can only reach your meteor app if your router is configured accordingly, i.e., the router will forward requests on port 3000 (or whichever port you are running your app on) to your server.
For testing on a mobile device during development you are most likely best off using your internal IP address, assuming your mobile device is on the same network as your app-serving machine.
On Linux you can use ifconfig to get your internal IPs. If you are connected via ethernet then you'll be looking for the device eth0 (in most cases). If you are connected over wifi, then the device you are looking for is typically called wlan0.
On Mac OSX you can use ifconfig as well, and look for devices called enX, where X is a number (often 0, or 2).
Your service is probably only running locally (on local ports, 127.0.0.0/8), To confirm this, run netstat -tulpn to see what services are running and on what ports/interfaces. If you don't see 0.0.0.0:3000 or 128.84.125.239:3000 then you won't be able to get ti it from the IP you are trying and you need to change the bind address of your app to be that IP (or all interaces).
I have a host laptop running Debian, and a client VM running Debian. On the client, I run NGINX, and it serves up a complex web application with several hostnames (e.g. www.host, api.host, blog.host). The laptop moves between several different networks, with a seemingly ever-changing IP address.
I'm trying to meet the following conditions with this VM:
The IP address of the client shouldn't change (e.g. always 192.168.10.10)
With a static IP, I could edit the host /etc/hosts file and keep complex hostnames
The client should have access to the Internet
No other machines need to access the client
What is the best way to set up the Attached to settings for this client?
To do this, simply add two network interfaces to the box.
The first interface will use Host-Only, and that is how your host can connect to the client. This will create an additional network adapter on the host.
The second interface will use NAT, and that is the gateway to the internet. This will create an additional network adapter on the client.
If you've already got a client running, you'll need to get the next network adapter up and running by executing sudo ifconfig eth1 up and to get an IP address, run sudo dhclient eth1.
I got access via SSH (root access) to a Machine that's inside a network at my client's office.
I'm programming in my computer a PHP application that needs to integrate to LDAP. The LDAP server is in another server at my client's network and not accesible from outside, however I can perfectly access it via the server I can connect to via SSH.
My question is: IS there anyway I can make a tunnel and setup a port in my computer to get the traffic forwarded to the LDAP server using my SSH connection to one of the computers on the network?
Thanks!!!!
Yes, ssh has a "-L" option to create a tunnel. That option takes 3 parameters, separated by colons (:). Local listen port, remote host, remote port.
ssh -L 9999:ldapserver:389 user#otherhost
Where 9999 is the local port that the tunnel will be created on. The ldapserver:389 bit tells it where to connect to on the other side.
Then, tell your application to connect to localhost:9999 (or whatever port you choose) and it will be tunneled across.