From 529a0b6e137cb54dc32f563973b5523f2a63f898 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Franti=C5=A1ek=20=C5=98ezn=C3=AD=C4=8Dek?= <246254@mail.muni.cz> Date: Wed, 1 Feb 2023 19:14:41 +0100 Subject: [PATCH] refactor: cloud blockage --- content/cloud/faq/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/cloud/faq/index.md b/content/cloud/faq/index.md index 4098e55..41dee49 100644 --- a/content/cloud/faq/index.md +++ b/content/cloud/faq/index.md @@ -133,7 +133,7 @@ The key practices helping to avoid source IP address blockage are: * connect to cloud infrastructure via single public facing jump / bastion node (using [sshuttle](https://github.com/sshuttle/sshuttle#readme) or [ssh ProxyJump](https://www.jeffgeerling.com/blog/2022/using-ansible-playbook-ssh-bastion-jump-host) or eventually [ssh ProxyCommand](https://blog.ruanbekker.com/blog/2020/10/26/use-a-ssh-jump-host-with-ansible/)) * use OpenStack API to watch whether VM is ACTIVE * relax public IP try-connect loop timing - * configure SSH client to [reuse connection for instance with `-o ControlMaster=auto -o ControlPersist=60s`]() + * configure SSH client to [reuse connection for instance with `-o ControlMaster=auto -o ControlPersist=60s`](https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing) 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). -- GitLab