TL; DR; У меня есть gitlab, работающий на виртуальной машине GCE. Иногда виртуальная машина перестает принимать трафик, как будто задействован внешний брандмауэр. сброс виртуальной машины все исправляет. Я могу использовать инструменты Google для ssh. Изнутри все выглядит нормально.
Мой вопрос: как мне это остановить?
У меня есть экземпляр GCE, на котором я запускаю 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
Я подключаюсь к экземпляру по ssh и:
sudo tail -f /var/log/gitlab/nginx/gitlab_access.log
доступ к моему экземпляру через мой брокер работает нормально и регистрируется обычным способом. Ssh'ing в виртуальную машину и выполнение curl также работают должным образом.
Теперь о странной части. Я уже давно бьюсь об этом.
Иногда экземпляр gitlab просто перестает работать. Я не могу git pull / push. Я не могу получить доступ к веб-приложению в моем браузере. когда я отслеживаю журнал доступа, как раньше, я не получаю никакой новой информации при попытке доступа к экземпляру извне (через браузер или что-то еще), но выполнение завитков изнутри виртуальной машины работает так же.
Как будто на пути стоит брандмауэр. На самом деле не должно быть.
Затем я сбрасываю виртуальную машину, и какое-то время все работает нормально. А потом снова ломается.
Это похоже на проблему с инфраструктурой Google, но я ничего не могу найти в журналах.
Любая помощь будет принята с благодарностью.
Я всегда могу пинговать свой домен gitlab изнутри виртуальной машины, и я не могу пинговать его, когда он работает. Это определенно не DNS.
Я решил, что могу увидеть, где останавливается трафик, выполнив traceroute, и он действует практически одинаково, идет ли он вверх или вниз. Например:
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 * * *
Я не вижу здесь полезного паттерна.
Кроме того, это началось случайно на прошлой неделе. Никто не трогал ВМ. Я запустил несколько обновлений после того, как начал происходить фанк, и ничего не исправил.
Насколько я могу судить, что-то не так с инфраструктурой, поддерживающей мой vm. Это похоже на то, что есть брандмауэр, который иногда появляется просто для развлечения, а затем исчезает, когда я перезагружаюсь.
Серьезно в тупике. некоторая помощь была бы хороша
ufw status сообщает мне, что брандмауэр отключен. Всегда. Так что не похоже, что внутренний брандмауэр виртуальной машины волшебным образом включается и выключается. Насколько я могу судить, трафик вообще не достигает виртуальной машины.
Использование nmap с моей локальной машины, когда gitlab не отвечает:
nmap -Pn x.x.x.x
Starting Nmap 7.01 ( https://nmap.org ) 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
И когда gitlab отвечает:
Starting Nmap 7.01 ( https://nmap.org ) 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
И от виртуальной машины вывод nmap будет одинаковым независимо от того, отвечает gitlab или нет:
Starting Nmap 7.40 ( https://nmap.org ) 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 https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 24.30 seconds
Это был SshGuard. Не уверен, почему он решил, что мой IP-адрес локальной сети был злым, но все равно. Это просто вопрос переконфигурирования.