Merge branch 'refactor-cloud-blockage' into 'master'

refactor: cloud blockage III

See merge request !116

content/cloud/faq/index.md

@@ -135,23 +135,26 @@ The key practices helping to avoid source IP address blockage are:
  * relax public IP try-connect loop timing
  * configure SSH client to [reuse connection for instance with `-o ControlMaster=auto -o ControlPersist=60s`](https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing)
 
+#### Example
+
 As an example, consider a group of virtual machines, where at least one has access to the internet using an IPv4 or IPv6 public address, and they are connected by an internal network (e.g. 10.0.0.0/24).
 
-To access the VM with a public address:
-* Wait for the machine to enter ACTIVE state via Openstack API: `openstack server show <id> -f json | jq -r .status`
-* After VM is in ACTIVE state try to open connection to SSH (or other) port with timeout of approx 5 seconds and period of 30 seconds
+To access the first VM with a public address `<public-ip-jump>`:
+* Wait for the machine to enter ACTIVE state via Openstack API: `openstack server show <openstack-server-id> -f json | jq -r .status`.
+* After VM is in ACTIVE state try to open connection to SSH port with timeout of approx. 5 seconds and period of at least 30 seconds.
 
 To access other VMs on the same cloud internal network (once ssh connection to 1st is established):
-* The recommended method is to create an SSH VPN using sshuttle with `sshuttle -r user@<public-ip> 10.0.0.0/24`
-* Address all internal virtual servers with their internal address (CIDR 10.0.0.0/24) and use the machine with the public address as an entry point for traffic
-* Use the steps above to connect – wait for ACTIVE and try a port connection
+* The recommended method is to create an SSH VPN using sshuttle with `sshuttle -r user@<public-ip-jump> 10.0.0.0/24`
+* Address all internal virtual servers with their internal address (CIDR 10.0.0.0/24) and use the 1st (jump / bastion) machine with the public address as an SSH proxy.
+* Follow the same steps to connect – first wait for ACTIVE state and then try a port connection.
 
 ### How to check, whether you are blocked
 Run the following bash script from the machine, where you believe you got blocked (A), and also from another one located in another IP network segment (B, for instance VM in other cloud):
 
 ```sh
-# Test Cloud Accessibility
-#
+# Test Cloud Accessibility for a linux or Windows WSDL 2 environments
+# BASH function requires following tools to be installed:
+#   ip, host tracepath traceroute ping, curl, ncat, timeout, bash
 # Execution example: test_cloud_access 178.128.250.99 22
 
 function test_cloud_access() {