Czy lokalny asystent AI zdiagnozuje sieć bez dostępu do całej infrastruktury?
Otwarte wydanie Transit pozwala wybrać model lokalny albo hostowany. O bezpiecznym zakresie diagnozy nadal decydują polecenia, poświadczenia i dane przekraczające tę granicę.
Oddział zgłasza, że telefony mogą dzwonić, ale nie zawsze odbierają połączenia. Zespół sieciowy widzi zmianę interfejsu, zdarzenie routingu i serię przekroczeń czasu. Asystent mógłby uporządkować obserwacje i zaproponować następne polecenie odczytu. Wybór modelu to tylko część zadania. Operator musi wiedzieć, z jakich poświadczeń narzędzie korzysta, jaki tekst wychodzi poza komputer i czy model może doprowadzić do zmiany.
Transit to narzędzie do diagnozowania sieci, które 21 października 2026 roku włączyło swojego klienta do projektu open source na licencji Apache 2.0. Strona przejścia wyznaczyła 5 listopada jako koniec dostępu rocznego i 17 listopada jako planowany termin zmiany dotyczącej hostowanej AI. Daty opisują zmianę modelu biznesowego produktu. Dostępność oprogramowania i status określonego konta usługi hostowanej to osobne kwestie. Wydania projektu, README i dokumentacja funkcji są najlepszymi odnośnikami dla wersji, którą zespół chce wypróbować.
Co oznacza lokalność w diagnostyce
Wybór punktu dostępu do modelu. Autorska ilustracja Telli.sh.
Klient może użyć Ollama lub innego punktu dostępu zgodnego z OpenAI. Dokumentacja opisuje też użycie własnego klucza OpenAI lub Anthropic i testowe logowanie dla uprawnionych kont ChatGPT Plus lub Pro. Wskazanie serwera Ollama na tym samym komputerze pozwala utrzymać inferencję na nim. Wskazanie firmowego punktu dostępu wysyła dane na ten adres. Wybór dostawcy chmurowego przekazuje mu żądanie po zastosowaniu opisanego w projekcie maskowania.
Klient nadal musi połączyć się ze sprzętem sieciowym, aby zebrać dowody. Diagnoza może obejmować host pośredniczący, konto operatora tylko do odczytu i kilka urządzeń. Lokalny punkt dostępu do modelu nie ogranicza urządzeń, z którymi klient może się połączyć. Decydują o tym osiągalność sieciowa i zakres poświadczeń.
Repozytorium opisuje ograniczony zestaw narzędzi oraz listę dozwolonych poleceń dla wspieranych producentów. Opisuje też zasady zatwierdzania, w tym automatyczną akceptację zgodnych poleceń na obsługiwanych systemach po ustawieniu odpowiedniej reguły przez operatora. Maskowanie i filtrowanie poleceń to warstwy, których działanie można sprawdzić. Traktuj banery urządzeń i logi jak niezaufany tekst, szczególnie gdy zawierają polecenia. Asystent może je streścić bez uznawania ich za źródło uprawnień.
| Granica | Pytanie operatora | Przydatny test |
|---|---|---|
| Punkt dostępu modelu | Dokąd trafia złożone polecenie? | Sprawdź adresy docelowe na fikcyjnym przykładzie |
| Dostęp do sprzętu | Do jakiego urządzenia i konta dotrze narzędzie? | Użyj w laboratorium hosta poza dozwolonym zakresem |
| Zatwierdzanie poleceń | Kto może zatwierdzić proponowane działanie? | Odrzuć polecenie i potwierdź, że urządzenie go nie wykonało |
| Dowody i logi | Które dane pozostają lub wychodzą z komputera? | Wstaw nieszkodliwe znaczniki i sprawdź eksport |

Przełączniki i panele krosowe podobne do tych, które operatorzy diagnozują. Zdjęcie kontekstowe Dsimic, wykadrowane i przeskalowane, CC BY-SA 4.0. Źródło zdjęcia · Licencja.
Oprzyj pilotaż na znanej usterce
Diagnoza sieci. Autorska ilustracja Telli.sh.
Przygotuj małe laboratorium ze znanym problemem interfejsu lub routingu. Daj narzędziu konto z minimalnymi uprawnieniami na przewidzianym urządzeniu i dodaj niepowiązany host, który ma pozostać niedostępny. Poproś o hipotezę i krótką listę obserwacji, które mogłyby ją obalić. Po sprawdzeniu uruchom jedno proponowane polecenie wyświetlające stan. Porównaj wynik z tą samą obserwacją zebraną ręcznie.
W drugim przebiegu podaj niejednoznaczny objaw. Wolniejsze działanie usługi może pasować do kilku ścieżek sieciowych, a polecenie urządzenia w prawdziwym środowisku może ujawnić identyfikatory klientów. Fikcyjne znaczniki pozwalają sprawdzić, dokąd dane są wysyłane, zapisywane lub przechowywane. Trzymaj łączność laboratoryjną oddzielnie od produkcyjnego hosta pośredniczącego, aż operatorzy zrozumieją, jakie dane ujawnia każdy tryb.
Przy eksporcie wyniku połącz polecenie, czas, tożsamość urządzenia i właściwy wynik z hipotezą, którą wspiera. Operator może wtedy przejrzeć ciąg dowodów bez przypominania sobie, które zdanie pochodziło z routera, a które z modelu.
Sprawdź integralność wydania i ograniczenia lokalnego modelu
Transit podaje, że wydania nie są podpisane. Plik SHA256SUMS dołączony do wydania pomaga sprawdzić zgodność pobranego pliku z opublikowanym skrótem. Samo porównanie nie uwierzytelnia wydawcy. Zespoły wymagające podpisanych artefaktów mogą rozważyć kompilację ze zweryfikowanego tagu według własnego procesu dystrybucji. Dokumentacja instalatora Windows wymienia także PowerShell 7.
Lokalna inferencja może ograniczyć zależność od chmury i pasować do środowiska z restrykcjami dotyczącymi udostępniania danych. Mniejszy model może pominąć kontekst, źle odczytać dane od różnych producentów albo działać wolniej na dostępnym sprzęcie. Sprawdź ten sam znany przypadek lokalnie i w zatwierdzonej usłudze hostowanej, jeśli obie opcje są dopuszczalne. Policz trafne hipotezy, zbędne polecenia, błędne przypisania do urządzeń i całkowity czas operatora.
Na początek warto traktować system jako narzędzie do zbierania dowodów w ustalonych granicach. Wyłącz automatyczne zatwierdzanie i pozwól operatorowi sprawdzać każdą propozycję. Jeśli próby dają spójne dowody i rzetelny raport, kolejne pytanie dotyczy klas diagnostyki tylko do odczytu, które mogą skorzystać z tego procesu w produkcji. To bardziej konkretna decyzja niż przyznanie modelowi ogólnego dostępu do sieci.
Zainstaluj jedną znaną wersję i zapisz jej ograniczenia
Wydanie v6.5.11 usuwa niezgodność nazw w wykazie sum kontrolnych, dopasowując wpisy do nazw normalizowanych przez GitHub. Wybierz świadomie wydanie i platformę, a przed uruchomieniem instalatora sprawdź opublikowaną sumę. Przeczytaj opis wydania i pobierz pliki z oficjalnego repozytorium. Jeśli organizacja instaluje zatwierdzone oprogramowanie przez zarządzany katalog, użyj tej procedury. Zgodny skrót nie stanowi zgody na instalację.
README opisuje sześć narzędzi diagnostycznych. Mała liczba pomaga, gdy operator wie, dokąd każde z nich może dotrzeć. Przed udostępnieniem poświadczeń zapisz adres modelu, host pośredniczący i pojedynczy przełącznik testowy. Zanotuj, które konto otworzyło każde połączenie. Jeśli programista konfiguruje osobny serwer Ollama, sprawdź faktyczny adres połączenia. Z punktu widzenia laptopa usługa w sieci biurowej nadal jest zewnętrznym celem.
- Utwórz przypadek laboratoryjny ze znanym objawem i kontem ograniczonym do przewidzianego sprzętu.
- Zweryfikuj wybraną kompilację i sprawdź ustawienia punktu dostępu, poświadczeń i retencji.
- Poproś asystenta o następną obserwację i hipotezę, którą ta obserwacja może obalić.
- Przy wyłączonej automatycznej akceptacji odrzuć jedną propozycję i sprawdź log urządzenia, zanim zgodzisz się na osobne bezpieczne polecenie.
- Dodaj nieszkodliwe znaczniki do przykładowych logów. Ustal, czy klient je maskuje i gdzie pojawiają się w lokalnych zapisach lub w skonfigurowanym punkcie dostępu.
- Wyeksportuj wyniki i pozwól innemu operatorowi odtworzyć diagnozę z zachowanych dowodów.
Użytkownik zmieniający dostawców powinien powtórzyć test po zmianie konfiguracji. Ten sam przycisk może prowadzić do nowej ścieżki przepływu danych po zmianie adresu. Osoba monitorująca sieć w autoryzowanym laboratorium może sprawdzić cele połączeń. Sam zrzut ustawień nie dowodzi, który adres odebrał żądanie.
Rozróżnij obsługiwany przełącznik i ogólną powłokę
Model zagrożeń oznaczony tagiem Transit opisuje politykę poleceń dla obsługiwanych producentów, w tym opcjonalną automatyczną akceptację zgodną z wcześniej włączoną regułą. W pilotażu można ją wyłączyć i sprawdzać każdą propozycję ręcznie. Narzędzie wciąż potrzebuje konta o ograniczonych uprawnieniach na urządzeniu. Okno zatwierdzenia nie zmniejszy uprawnień konta serwisowego.
Ten sam model zagrożeń opisuje inną politykę dla ogólnych systemów Linux i Unix. Ścieżka ostrzega operatora, wymaga akceptacji każdego polecenia i nie ma opcji „zawsze zezwalaj”. Bazowa polityka nie ogranicza w tym trybie poleceń. Pozostaw go poza pierwszym pilotażem tylko do odczytu, jeśli organizacja nie może niezależnie egzekwować zakresu. Typ urządzenia i konto są częścią zabezpieczenia.
Drugi przypadek może sprawdzić reakcję narzędzia na nieznany wynik. Polecenie może zwrócić licznik, którego model nie rozpoznaje, albo oczekiwany interfejs może mieć inne nazwy u dwóch producentów. Użyteczna odpowiedź cytuje obserwację i prosi o sprawdzenie pozwalające rozstrzygnąć sprawę. Słabsza przedstawia prawdopodobną interpretację jako fakt. Operatorzy mogą ocenić obie reakcje bez udostępniania sprzętu produkcyjnego.
Przygotuj wynik przydatny dla kolejnej zmiany
Jednozdaniowa diagnoza jest wygodna dla osoby, która prowadziła sprawę. Przekazanie zmiany wymaga ostatniej potwierdzonej obserwacji, informacji o wykluczonych i otwartych hipotezach oraz sprawdzalnego następnego kroku bez otwierania wszystkich sesji. Przy ważnych stwierdzeniach umieść odsyłacze do dowodów. Jeśli model zmieni diagnozę po nowym wpisie, zapisz dlaczego.
Najlepsze porównanie uwzględnia ręczny proces zespołu. Zmierz czas znalezienia pierwszej użytecznej obserwacji, liczbę nieistotnych poleceń i czas przygotowania przekazania. Lokalny model może dać istotną korzyść dla prywatności, jeśli radzi sobie z zadaniem w dopuszczalnym czasie. Zatwierdzony model hostowany może być praktyczniejszy dla trudniejszego przypadku, gdy zezwala na to polityka danych. W obu trybach jasno opisz połączenia i dowody.
Śledź osobno każdy kierunek przepływu danych
Użyteczny zapis konfiguracji pokazuje, co wysyła interfejs, co trafia do inferencji i co jest pobierane z urządzeń. Ułatwia to ocenę zmiany dostawcy. Traktuj zasady retencji u każdego odbiorcy osobno. Wyczyszczenie lokalnej historii nie dowodzi, że punkt dostępu usunął wcześniejsze żądanie.
| Tryb | Cel inferencji | Przydatna kontrola |
|---|---|---|
| Ollama na tej samej stacji | Adres pętli zwrotnej | Potwierdź połączenie procesu z właściwą usługą lokalną |
| Firmowy serwer inferencji | Adres wewnętrzny | Sprawdź uwierzytelnianie usługi i retencję poleceń |
| Dostawca hostowany | Zatwierdzony punkt dostawcy | Sprawdź maskowanie i zasady z użyciem fikcyjnych dowodów |
| Testowe logowanie do konta | Uprawnione konto dostawcy | Zweryfikuj konto i dostępne opcje administracyjne |
Tabela przedstawia częste konfiguracje. Zespół powinien obserwować faktycznie wybrane adresy i ustawienia usług. W panelu administrator może zobaczyć tę samą markę przy usłudze hostowanej i prywatnej bramie. Ustalenie rzeczywistej nazwy hosta i jego operatora umożliwia audyt przepływu danych.
Sprawdź maskowanie na fikcyjnych danych
Zbuduj log laboratoryjny z przykładowym adresem IP, wymyśloną nazwą urządzenia i znacznikiem przypominającym identyfikator klienta. Wskaż, które elementy polityka ma zachować, zamaskować lub usunąć. Użyj tych samych danych w dwóch operacjach, na przykład podsumowaniu w czacie i eksporcie. System może tworzyć je różnymi drogami. Sprawdź każdą przed dopuszczeniem prawdziwych danych.
W drugim teście umieść znacznik w długim opisie lub sformatowanym wyniku. Reguła maskowania może poprawnie obsłużyć rozpoznane pole, lecz pominąć tę samą wartość w tekście. Jeśli wynik nadal ujawnia znacznik niedozwolonemu odbiorcy, zamknij tę drogę przed podłączeniem produkcji. Operator może zmniejszyć pierwotny zestaw danych i powtórzyć próbę, by sprawdzić, które zabezpieczenie faktycznie działa.
Ponów ocenę po aktualizacji
Po aktualizacji klienta zapisz wybranego dostawcę i powtórz te same przypadki laboratoryjne. Zmiany listy poleceń lub dopasowywania reguł akceptacji mogą wpłynąć na propozycje narzędzia. Zmiany domyślnych punktów dostępu mogą zmienić miejsce wysyłania dowodów. Razem sprawdź odrzucone polecenie, maskowanie i pomyślną znaną diagnozę. Mały zestaw regresyjny ułatwia utrzymanie narzędzia w miarę zmian środowiska zespołu.
Sprawdzaj osobno narzędzia i konto urządzenia
Narzędzie odczytu może zwrócić metadane urządzenia lub już dostępny dowód. Narzędzie wykonywania poleceń może pozyskać nowy dowód przez połączone konto. Podsumowanie powinno nadal działać, kiedy wykonywanie jest niedostępne. Sprawdź to, odłączając urządzenie przy nadal aktywnym punkcie dostępu modelu. Odpowiedź powinna rozróżniać dane z wcześniejszej obserwacji od nowej obserwacji, której nie udało się zebrać.
Potem połącz się kontem, które może sprawdzić jeden przełącznik, ale nie może wejść w tryb konfiguracji ani dotrzeć do innego segmentu. Zespół może przetestować odmowę na własnej infrastrukturze laboratoryjnej bez zlecania asystentowi rzeczywistej zmiany. Porównaj zapis proponowanych działań w aplikacji z rejestrem logowań i poleceń urządzenia. Próba rozdziela decyzję polityki narzędzia od faktycznych uprawnień konta.
Źródła
Jeśli chcesz przechowywać rozmowy i decyzje związane z pracą w formie, którą można przeszukiwać, załóż konto Telli.sh.