Finder MacOS (и Xcode) доступ к iDevice, когда сеть отключена

Я пытаюсь разобраться, что не так с моим Mac.

Вот мои устройства:

iPad (7-го поколения, MW752LL/A) с iOS 14.01 (18A393),
iPad Air (MD788LL/A) с iOS 12.4.8 (16G201),
iPhone 6 Plus (MGCW2LL/A) с iOS 12.4.8 (16G201)

Mac mini (середина 2011 года) с macOS Catalina 10.15.7 (использую macOS Catalina Patcher от dosdude1.com)

Все устройства подключены к сети / Интернет через один и тот же WiFi-роутер. Но соединение Mac проводное (Ethernet кабель Cat5).

Проблема:

Мое первое наблюдение: после отключения Ethernet на Mac (см. pic1), я все равно могу получить доступ ко всем своим трем iDevice через Finder. Я могу передавать файлы и копировать их с всех трех iDevice. Если я физически отключу кабель Cat5, то не смогу получить доступ к трем iDevice. Но как только я снова подключаю кабель Cat5, я вновь могу получить доступ к этим трем iDevice через Finder. Все это время сеть моего Mac была отключена. Я могу подтвердить, что пока сеть моего Mac была отключена, ни одно из моих приложений (Safari, App Store или любые сторонние приложения) не могло получить доступ к Интернету.

Итак, я отправил электронное письмо в службу безопасности продуктов Apple. На следующий день я получил ответ с сообщением: «Что касается проблемы, о которой вы сообщили, мы изучили ее и определили, что лучше всего решить ее с помощью ресурсов поддержки Apple, которые можно найти по адресу https://www.apple.com/support/.» А также ссылку на сайт AppleCare.

Я предположил, что они говорят мне, что эта проблема уникальна для моей системы.

Я решил разобраться. Мое первое интуитивное подозрение – это Xcode, который может демонстрировать ту же явление, так как, вероятно, использует тот же механизм для доступа к iDevices. Я провел тестирование с Xcode, и действительно, он проявил то же самое поведение.

Далее я хотел устранить эту неопределенность: используя macOS Catalina Patcher от dosdude1. Я установил High Sierra (последняя версия 10.13.6) на внешний USB-накопитель. С этой настройкой моя система Mac должна соответствовать требованиям Apple для Mac mini середины 2011 года с правильной версией MacOS на момент, когда она все еще поддерживалась. Finder в High Sierra пока не поддерживает доступ к iDevices через WiFi. Но Xcode поддерживает. И я обнаружил, что у Xcode также наблюдается это явление, как описано ранее. Чтобы минимизировать любые возможности перекрестного загрязнения или воздействия Интернета, находясь в High Sierra, я не устанавливал никакого программного обеспечения, кроме последнего обновления безопасности от Apple. Но я зашел на сайт разработчиков Apple, чтобы скачать Xcode версии 10. И я снова загрузил Catalina, чтобы экспортировать свой сертификат Xcode и импортировать его в новый Xcode под High Sierra.

Вот мои выводы: Вы согласны?

1. Это явление не может и не должно быть нормой.
2. Это явление не вызвано использованием macOS Catalina Patcher от dosdude1.
3. Допустим, что аппаратное обеспечение моего Mac (Ethernet) устарело для Catalina. Но под High Sierra Xcode имеет те же симптомы.
4. Какова вероятность того, что прошивка моего Mac была скомпрометирована?

Поскольку я не планирую приобретать новый Mac, я не смогу определить, испытывает ли какое-либо современное оборудование Mac это явление.

Есть комментарии?

Отредактировано 1: показываю ifconfig по запросу. Примечание: я изменил MAC-адреса.

Отредактировано 2: Похоже, если я отключаю IPv6 на Mac, то это явление исчезает. Я получил подсказку из вывода ifconfig, что адрес IPv6 все еще доступен, в то время как адрес IPv4 исчез, когда сеть отключена.

Отредактировано 3: После дальнейшего исследования с подсказками из комментариев я обнаружил, что IPv6 все еще активен, даже после отключения Ethernet в настройках сети. Потому что IPv6 находился в другом меню: «Дополнительно…». Если кто-то зайдет в это меню «Дополнительно…», то IPv6 находится в отдельном выпадающем списке (pic2). Единственный способ полностью отключить сеть – это зайти в меню «Дополнительно…», чтобы выбрать Настроить IPv6 как «Вручную» (pic3) и оставить все поля пустыми.

Итак, мой вывод в том, что это было сделано намеренно. Это нормально. Но это вводит в заблуждение. В окне сети (pic1) индикатор Ethernet красный, когда вы отключили Настроить IPv4, в то время как IPv6 все еще активен. На мой взгляд, это не должно быть так. Просто этот индикатор предназначен для Ethernet-соединения: как для IPv4, так и для IPv6. Если только Apple не решила, что IPv6 не является частью Ethernet. В этом случае нужно создать другой индикатор.

И Finder, и Xcode используют IPv6.

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
    inet 127.0.0.1 netmask 0xff000000 
    inet6 ::1 prefixlen 128 
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
    nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
EHC250: flags=0<> mtu 0
EHC253: flags=0<> mtu 0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=50b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV,CHANNEL_IO>
    ether xx:xx:xx:xx:xx:xx  
    inet6 fe80::1469:5fff:c541:b802%en0 prefixlen 64 secured scopeid 0x6 
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect (1000baseT <full-duplex,flow-control,energy-efficient-ethernet>)
    status: active
en1: flags=8823<UP,BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
    options=400<CHANNEL_IO>
    ether zz:zz:zz:zz:zz:zz 
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect (<unknown type>)
    status: inactive
en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
    options=460<TSO4,TSO6,CHANNEL_IO>
    ether yy:yy:yy:yy:yy:yy  
    media: autoselect <full-duplex>
    status: inactive
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
    lladdr ww:ww:ww:ww:ww:ww:ww:ww 
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect <full-duplex>
    status: inactive
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=63<RXCSUM,TXCSUM,TSO4,TSO6>
    ether yy:yy:yy:yy:yy:yy  
    Configuration:
        id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
        maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
        root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
        ipfilter disabled flags 0x0
    member: en2 flags=3<LEARNING,DISCOVER>
            ifmaxaddr 0 port 8 priority 0 path cost 0
    nd6 options=201<PERFORMNUD,DAD>
    media: <unknown type>
    status: inactive
p2p0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 2304
    options=400<CHANNEL_IO>
    ether qq:qq:qq:qq:qq:qq  
    media: autoselect
    status: inactive
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet6 fe80::97b1:8eb0:7f61:8f08%utun0 prefixlen 64 scopeid 0xc 
    nd6 options=201<PERFORMNUD,DAD>
utun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
    inet6 fe80::eedc:91d7:6a3f:2623%utun1 prefixlen 64 scopeid 0xd 
    nd6 options=201<PERFORMNUD,DAD>

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=50b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV,CHANNEL_IO>
ether xx:xx:xx:xx:xx:xx  
inet6 fe80::1469:5fff:c541:b802%en0 prefixlen 64 secured scopeid 0x6 

Итак, интерфейс en0, который, предположительно, является вашим подключением Ethernet, активен с действительным (link local) адресом IPv6. Если у других iDevice также установлены адреса Link Local, они смогут взаимодействовать через IPv6 с вашим Mac.

Вы можете утверждать, что оставлять компьютер в состоянии прослушивания сети, когда вы отключили его, может быть уязвимостью, но это, вероятно, сделано намеренно, и не является чем-то, что Apple бы считала проблемой безопасности.