O computador que estou usando (Windows 7 Enterprise) tem duas conexões de rede, uma que fornece acesso à internet e à rede da universidade - esse adaptador é o que deve ser usado para a maioria das coisas. O segundo adaptador é uma rede local conectada a algum equipamento de laboratório através de um roteador e não tem acesso à Internet.
Estou tendo um problema em fazer com que o git trabalhe nessa situação. Com o segundo adaptador (local) desabilitado, tudo funciona conforme o esperado. No entanto, quando o adaptador está habilitado, o PowerShell não consegue acessar as solicitações do github - pull, por exemplo, apresentando falha no erro 443. No entanto, a Internet ainda funciona para todo o resto fora do powershell - por exemplo, IE / Firefox / cmd / etc. Portanto, parece que o PowerShell está tentando usar o segundo adaptador, mesmo que ele não tenha acesso à Internet.
Curiosamente, se eu executar ping github.com do powershell, a primeira resposta será perdida, mas todas as outras respostas serão recebidas. Se eu tentar executar git pull novamente, ele se conectará, mas apenas uma vez. Se eu tentar puxar novamente, ele falhará. Isso é repetitivo, se eu pingar o github antes de executar um comando git, ele funcionará para esse comando - mas se o comando demorar muito (como a sincronização de um grande repositório), ele falhará no meio.
Eu realmente não tenho certeza do que está causando isso. Eu tentei várias coisas, incluindo a configuração manual das métricas de interface no Windows, para que o primeiro adaptador seja um número muito baixo e o segundo, um número muito alto (por isso, é desfavorável). Mas isso não parece fazer nada para ajudar - resolveu o problema que eu estava tendo com o windows acessando a internet, mas não ajudou com o git. Eu também tentei configurar o segundo adaptador para ter um IP estático com nenhum gateway padrão (como sugerido neste pergunta de superusuário ).
Há algo que eu esteja sentindo falta?
Em resposta a @LazyBadger, executei tracert github.com e obtive o seguinte resultado:
Tracing route to github.com [192.30.252.131]
over a maximum of 30 hops:
1 ******** [192.168.*.*] reports: Destination host unreachable.
Se eu executar route print 0* , obtenho o seguinte:
===========================================================================
Interface List
14...** ** ** ** cd 5e ......Intel(R) I210 Gigabit Network Connection #2 <- This one is the primary adapter
13...** ** ** ** cd 5f ......Intel(R) I210 Gigabit Network Connection
1...........................Software Loopback Interface 1
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 129.*.*.* 129.*.*.* 2
===========================================================================
Persistent Routes:
None
IPv6 Route Table
===========================================================================
Active Routes:
None
Persistent Routes:
None
(*) Nota: Eu apaguei os endereços IP e MACs, mas o 192.168.*.* é o segundo adaptador que não tem acesso à Internet, e o 129.*.*.* é o primeiro adaptador que tem acesso à Internet.
Se eu executar ping github.com , obtenho o seguinte
Pinging github.com [192.30.252.128] with 32 bytes of data:
Reply from 192.168.*.*: Destination host unreachable.
Reply from 192.30.252.128: bytes=32 time=84ms TTL=52
E, em seguida, executando tracert github.com recebo
Tracing route to github.com [192.30.252.128]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms ********* [129.*.*.*]
..............
7 82 ms 82 ms 83 ms ae-4-90.edge3.Washington4.Level3.net [4.69.149.210]
8 83 ms 83 ms 83 ms GITHUB-INC.edge3.Washington4.Level3.net [4.53.116.102]
9 84 ms 84 ms 84 ms 192.30.252.201
10 84 ms 84 ms 84 ms github.com [192.30.252.128]
Depois disso, ele não funciona novamente - basicamente o primeiro comando depois que eu fizer um ping funcionará, mas qualquer comando adicional volta a usar o adaptador errado até que eu faça outro ping.
Interessante. tracert funciona bem para outros sites como o Google e outros. A diferença parece ser que qualquer um que comece com o IP 192. parece passar pelo adaptador errado.