Компьютер, который я использую (Windows 7 Enterprise), имеет два сетевых подключения, одно из которых обеспечивает доступ к Интернету и университетской сети - этот адаптер в том, который следует использовать для большинства вещей. Второй адаптер представляет собой локальную сеть, подключенную к некоторому лабораторному оборудованию через маршрутизатор и не имеющую доступа в Интернет.
У меня возникла проблема с получением мерзавца для работы в этой ситуации. При отключенном втором (локальном) адаптере все работает как положено. Однако, когда адаптер включен, PowerShell не может достичь github-pull запросов, например, с ошибкой 443. Тем не менее, Интернет по-прежнему работает для всего остального, кроме PowerShell - например, IE/Firefox/cmd/ и т.д. Таким образом, похоже, что powershell пытается использовать второй адаптер, хотя у него нет доступа к Интернету.
Интересно, что если я запускаю ping github.com из powershell, первый ответ теряется, но затем все остальные ответы принимаются. Если я попытаюсь запустить git pull снова, он подключится, но только один раз. Если я попытаюсь вытащить снова, это не получится Это повторяется, если я пингую github перед запуском команды git, тогда она работает для этой команды - но если команда занимает слишком много времени (например, синхронизация большого репозитория), она терпит неудачу на полпути.
Я действительно не уверен, что вызывает это. Я пробовал несколько вещей, включая ручную настройку метрик интерфейса в Windows, чтобы у первого адаптера было очень маленькое число, а у второго очень большое число (так что это неблагоприятно). Но это, похоже, не помогает git - это решило проблему, с которой я столкнулся при доступе к Интернету через Windows, но не помогло с git. Я также попытался настроить второй адаптер для статического IP-адреса без шлюза по умолчанию (как предложено в этом вопросе суперпользователя).
Есть что-то, чего мне не хватает?
В ответ на @LazyBadger я запустил tracert github.com и получил следующий результат:
Tracing route to github.com [192.30.252.131]
over a maximum of 30 hops:
1 ******** [192.168.*.*] reports: Destination host unreachable.
Если я запускаю route print 0* , я получаю следующее:
===========================================================================
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
(*) Примечание: я отключил IP-адреса и MAC-адреса, но 192.168.*.* это второй адаптер, который не имеет доступа к интернету, и 129.*.*.* - это первый адаптер, у которого есть доступ к интернету.
Если я затем запускаю ping github.com , я получаю следующее
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
А потом запускаю tracert github.com получаю
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]
После этого он не работает снова - в основном, первая команда после того, как я выполняю эхо-запрос, будет работать, но любые дальнейшие команды возвращаются к использованию неправильного адаптера, пока я не выполню другой эхо-запрос.
Интересно. tracert отлично работает для других сайтов, таких как Google и тому подобное. Разница, по-видимому, заключается в том, что любой, который начинается с IP 192. кажется, проходит через неправильный адаптер.