gitlab-ee w GCE okresowo przestaje przyjmować ruch, ale działa ponownie po ponownym uruchomieniu

TL; DR; Mam gitlab działający na maszynie wirtualnej GCE. Czasami maszyna wirtualna przestaje przyjmować ruch, tak jak w przypadku zewnętrznej zapory. zresetowanie maszyny wirtualnej naprawia wszystko. Mogę używać narzędzi Google ssh. Od środka wszystko wygląda dobrze.
Moje pytanie brzmi, jak mam to zatrzymać?

dłuższa wersja
>
Mam instancję GCE, na której uruchamiam 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

Łączę się z instancją przez ssh i:

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

dostęp do mojej instancji przez mojego brokera działa dobrze i loguje się w zwykły sposób. Łączenie się z maszyną wirtualną i uruchamianie curl również działa zgodnie z oczekiwaniami.
A teraz dziwna część. Walczyłem o to od dawna.
Czasami instancja gitlab po prostu przestaje działać. Nie mogę ciągnąć/pchać. Nie mogę uzyskać dostępu do aplikacji internetowej w mojej przeglądarce. kiedy śledzę dziennik dostępu tak jak wcześniej, nie otrzymuję żadnych nowych informacji, gdy próbuję uzyskać dostęp do instancji z zewnątrz (przez przeglądarkę lub cokolwiek innego), ale robienie loków z wnętrza maszyny wirtualnej działa w ten sam sposób.
Jakby na drodze była zapora ogniowa. Naprawdę nie powinno.
Następnie zresetowałem maszynę wirtualną i przez chwilę wszystko działa dobrze. A potem znowu się psuje.
Wygląda to na problem ze strukturą Google, ale nie mogę znaleźć niczego w dziennikach.
Każda pomoc byłaby bardzo mile widziana.

AKTUALIZACJA
>
Zawsze mogę pingować moją domenę gitlab z wnętrza maszyny wirtualnej i nie mogę jej pingować, gdy jest uruchomiona. To zdecydowanie nie jest DNS.
Pomyślałem, że mogę zobaczyć, gdzie ruch się zatrzymuje, wykonując traceroute i działa prawie tak samo, niezależnie od tego, czy idzie w górę, czy w dół. Na przykład:

 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   *  *  *  

Nie widzę tutaj żadnego użytecznego wzoru.
Zaczęło się też przypadkowo w zeszłym tygodniu. Nikt nie dotknął maszyny wirtualnej. Uruchomiłem kilka aktualizacji po tym, jak zaczęło się dziać funky i niczego nie naprawiłem.
O ile wiem, coś jest nie tak z infrastrukturą obsługującą moją maszynę wirtualną. Wygląda na to, że istnieje zapora ogniowa, która czasami pojawia się tylko dla zabawy, a następnie znika po ponownym uruchomieniu.
Poważnie zaskoczony. jakaś pomoc byłaby miła

aktualizacja 2
>

       ufw status

     

mówi mi, że zapora jest wyłączona. Jest zawsze. Więc nie wygląda na to, że wewnętrzna zapora maszyny wirtualnej w magiczny sposób włącza się i wyłącza. O ile wiem, ruch w ogóle nie dociera do maszyny wirtualnej.

aktualizacja 3
>
Używanie nmap z mojego lokalnego komputera, gdy gitlab nie odpowiada:

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 filteredNmap done: 1 IP address (1 host up) scanned in 201.62 seconds

A kiedy gitlab odpowie:

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

Z maszyny wirtualnej wynik nmap będzie taki sam, niezależnie od tego, czy gitlab odpowie, czy nie:

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