gitlab-ee sur GCE Cesse périodiquement de prendre la circulation, mais cela fonctionne à nouveau après le redémarrage

TL; DR; j'ai gitlab, machine virtuelle GCE. Parfois, une machine virtuelle cesse de prendre du trafic, comme si un pare-feu externe est impliqué. Réinitialiser la machine virtuelle toutes correctes. Je peux utiliser des outils Google pour ssh. De l'intérieur tout va bien.

Ma question: comment puis-je l'arrêter?

version plus longue

J'ai une instance GCE, sur lequel je cours gitlab (9.5.1-ee).

lsb_release -a
=>
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 17.04
Release: 17.04
Codename: zesty

Je me connecte à l'instance par ssh et:

sudo tail -f /var/log/gitlab/nginx/gitlab_access.log

L'accès à ma copie via mon courtier fonctionne normalement et enregistré de la manière habituelle. Ssh'ing Dans une machine virtuelle et une exécution curl Fonctionne également correctement.

Maintenant sur la partie étrange. J'ai été confus depuis longtemps.

Parfois instance gitlab Arrête juste de travailler. je ne peux git pull / push. Je ne peux pas accéder à l'application Web dans mon navigateur. Lorsque je suivez le journal d'accès, je ne reçois aucune nouvelle information lorsque vous essayez d'accéder à une instance de l'extérieur. (à travers un navigateur ou autre chose), Mais effectuer des boucles de l'intérieur de la machine virtuelle fonctionne également.

Comme si le pare-feu est sur le chemin. En fait, ne devrait pas être.

Ensuite, je dépose une machine virtuelle et, pendant quelque temps, tout fonctionne bien. Puis casse à nouveau.

Cela ressemble à un problème d'infrastructure Google, Mais je ne trouve rien dans des magazines.

Toute aide sera acceptée avec gratitude.

Rafraîchir

Je peux toujours ping mon domaine gitlab De l'intérieur de la machine virtuelle, et je ne peux pas le ping quand ça marche. Ceci est définitivement ne. DNS.

J'ai décidé que je pouvais voir où le trafic s'arrête, après traceroute, Et cela agit presque le même, qu'il monte ou non. Par exemple:

  1   192.168.12.1  10.350ms  2.163ms  4.095ms 
2 196.41.120.41 51.029ms 14.084ms 5.177ms
3 196.41.120.37 34.846ms 38.931ms 3.306ms
4 196.41.97.74 11.717ms 7.113ms 5.196ms
5 74.125.146.178 7.322ms 18.239ms 8.329ms
6 66.249.95.8 209.010ms 203.518ms 176.016ms
7 64.233.175.113 174.606ms 167.839ms 166.019ms
8 209.85.252.120 174.138ms 169.820ms 173.657ms
9 108.170.234.139 196.385ms 169.107ms 168.493ms
10 * * *

Je ne vois pas ici un modèle utile.

En outre, cela a commencé par hasard la semaine dernière. Personne n'a touché le vm. J'ai lancé plusieurs mises à jour après que Funk a commencé à se produire et n'a rien réparer.

Autant que je puisse juger, quelque chose ne va pas avec l'infrastructure qui soutient mon vm. Il semble qu'il y ait un pare-feu, qui apparaît parfois juste pour le divertissement, puis disparaît lorsque je redémarre.

Sérieusement dans une impasse. Une aide serait bonne

Mettre à jour 2


ufw status

Il me dit que le pare-feu est désactivé. Est toujours. Il ne semble donc pas que le pare-feu interne de la machine virtuelle s'allume et s'éteint par magie. Pour autant que je puisse juger, la circulation n'atteint pas du tout la machine virtuelle.

Mettre à jour 3

Utilisant nmap avec ma voiture locale quand gitlab Ne répond pas:

nmap -Pn x.x.x.x                                                                  
Starting Nmap 7.01 ( [url=https://nmap.org]https://nmap.org[/url] ) at 2017-08-30 12:40 SAST
...
Stats: 0:02:48 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 83.50% done; ETC: 12:44 (0:00:33 remaining)
Nmap scan report for x.x.x.x.bc.googleusercontent.com (35.187.189.117)
Host is up.
All 1000 scanned ports on x.x.x.x.bc.googleusercontent.com (x.x.x.x) are filtered

Nmap done: 1 IP address (1 host up) scanned in 201.62 seconds

Et quand gitlab Réponses:

Starting Nmap 7.01 ( [url=https://nmap.org]https://nmap.org[/url] ) at 2017-08-30 12:47 SAST
Nmap scan report for x.x.x.x.bc.googleusercontent.com (x.x.x.x)
Host is up (0.26s latency).
Not shown: 994 filtered ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
3389/tcp closed ms-wbt-server
4567/tcp open tram
8080/tcp closed http-proxy

Et de la sortie de la machine virtuelle nmap sera la même chose quelles que soient les réponses gitlab ou non:

Starting Nmap 7.40 ( [url=https://nmap.org]https://nmap.org[/url] ) at 2017-08-30 10:48 UTC
Nmap scan report for x.x.x.x.bc.googleusercontent.com (x.x.x.x)
Host is up (0.00069s latency).
Not shown: 994 filtered ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open https
3389/tcp closed ms-wbt-server
4567/tcp open tram
8080/tcp closed http-proxy
Device type: general purpose|specialized|WAP|PBX|phone|media device
Running (JUST GUESSING): Linux 3.X|4.X (89%), Crestron 2-Series (88%), Asus embedded (88%), Vodavi embedded (88%), Google Android 5.X (86%)
OS CPE: cpe:/o:linux:linux_kernel:3.2 cpe:/o:linux:linux_kernel:4.2 cpe:/o:crestron:2_series cpe:/h:asus:rt-n56u cpe:/o:linux:linux_kernel:3.4 cpe:/h:vodavi:xts-ip cpe:/o:google:android:5 cpe:/o:linux:linux_kernel:3.x
Aggressive OS guesses: Linux 3.2 (89%), Linux 4.2 (89%), Crestron XPanel control system (88%), ASUS RT-N56U WAP (Linux 3.4) (88%), Linux 3.16 (88%), Vodavi XTS-IP PBX (88%), Android 5.0 - 5.1 (86%), Android 5.1 (86%), Linux 3.13 (86%), Linux 3.2 - 3.10 (86%)
No exact OS matches for host (test conditions non-ideal).

OS detection performed. Please report any incorrect results at [url=https://nmap.org/submit/]https://nmap.org/submit/[/url] .
Nmap done: 1 IP address (1 host up) scanned in 24.30 seconds
Invité:

Christine

Confirmation de:

C'était SshGuard. Je ne sais pas pourquoi il a décidé que mon adresse IP du réseau local était mal, mais toujours. C'est juste une question de reconfiguration.

Pour répondre aux questions, connectez-vous ou registre