Komputer, którego używam (Windows 7 Enterprise) ma dwa połączenia sieciowe, jedno zapewniające dostęp do Internetu i sieci uniwersyteckiej - ten adapter w tym, który powinien być używany do większości rzeczy. Drugi adapter jest siecią lokalną podłączoną do niektórych urządzeń laboratoryjnych za pośrednictwem routera i nie ma dostępu do Internetu.
Mam problem z uruchomieniem gita w tej sytuacji. Po wyłączeniu drugiego (lokalnego) adaptera wszystko działa zgodnie z oczekiwaniami. Jednak gdy adapter jest włączony, PowerShell nie osiąga żądań github - na przykład nie informuje o błędzie 443. Jednak Internet nadal działa na wszystko poza PowerShell - np. IE / Firefox / cmd / etc. Wygląda więc na to, że PowerShell próbuje użyć drugiego adaptera, mimo że nie ma dostępu do Internetu.
Co ciekawe, jeśli uruchomię ping github.comz PowerShell, pierwsza odpowiedź zostanie utracona, ale wtedy otrzymane zostaną wszystkie pozostałe odpowiedzi. Jeśli następnie spróbuję uruchomić git pullponownie, łączy się, ale tylko raz. Jeśli spróbuję ponownie pociągnąć, nie powiedzie się. Jest to powtarzalne, jeśli pinguję github przed uruchomieniem polecenia git, to zadziała dla tego polecenia - ale jeśli polecenie trwa zbyt długo (jak synchronizacja dużego repozytorium), nie powiedzie się w połowie.
Naprawdę nie jestem pewien, co to powoduje. Próbowałem kilku rzeczy, w tym ręcznego ustawiania wskaźników interfejsu w systemie Windows, tak aby pierwszy adapter był bardzo niską liczbą, a drugi bardzo wysoką liczbą (więc jest to niekorzystne). Ale to nie wydaje się pomagać gitowi - rozwiązało problem, który miałem z oknami uzyskującymi dostęp do Internetu, ale nie pomogło z gitem. Próbowałem również ustawić drugi adapter tak, aby miał statyczny adres IP bez domyślnej bramy (jak zasugerowano w tym pytaniu administratora ).
Czy czegoś brakuje?
W odpowiedzi na @LazyBadger uruchomiłem tracert github.comi otrzymałem następujący wynik:
Tracing route to github.com [192.30.252.131]
over a maximum of 30 hops:
1 ******** [192.168.*.*] reports: Destination host unreachable.
Jeśli uruchomię route print 0*, otrzymam następujące informacje:
===========================================================================
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
(*) Uwaga: Wyczyściłem adresy IP i MAC, ale 192.168.*.*jest to drugi adapter, który nie ma dostępu do Internetu, i 129.*.*.*jest to pierwszy adapter, który ma dostęp do Internetu.
Jeśli następnie uruchomię ping github.com, otrzymam następujące informacje
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
A następnie uruchomić tracert github.comotrzymuję
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]
Po tym to nie działa ponownie - w zasadzie pierwsze polecenie po wykonaniu polecenia ping będzie działać, ale wszelkie dalsze polecenia powrócą do używania niewłaściwego adaptera, dopóki nie wykonam innego polecenia ping.
Ciekawy. tracertdziała dobrze w przypadku innych witryn, takich jak Google itp. Różnica wydaje się polegać na tym, że wszystkie, które zaczynają się od adresu IP, 192.wydają się przechodzić przez niewłaściwy adapter.
tracertzawsze. I pokaż przynajmniejroute print 0*
tracerti pokazuje, że próbuje przejść przez drugi adapter (ten bez dostępu do Internetu) i tak się nie udaje. Być może wcale nie jest to problem z gitem, ale z PowerShellem?
route printponownie bez dodatkowych argumentów i podaj dane wyjściowe. Git nie ma specjalnego związku z PowerShell. pingi nie tracertsą także poleceniami PowerShell.
route print 192*pokaże złą ścieżkę, IMNSHO). Oczywiście Tom musi dodać trwałą trasę do Github poprzez poprawny interfejs lub naprawić „zbyt szeroką” maskę sieci na interfejsie lokalnym 192.168