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