Dlaczego nazwa adaptera VPN może ukrywać inny protokół
Etykieta obok adaptera opisuje oprogramowanie, które go utworzyło, a nie pakiety w sieci. Przed wyborem rozwiązania sprawdź klienta, profil i partnera.
Etykieta obok adaptera VPN opisuje oprogramowanie, które utworzyło interfejs, a to jest o jedną warstwę wyżej niż pakiety faktycznie przechodzące przez sieć. Wtyczka może ujawnić adapter, którego nazwa odzwierciedla własną klasyfikację wtyczki, a nie enkapsulację w sieci. Odczytanie klienta, profilu i partnera odpowiada na to, na co nazwa nie potrafi odpowiedzieć. Dwa połączenia, które w menu ustawień wyglądają identycznie, mogą zachowywać się zupełnie różnie w zapisie.
Nazwa pochodzi od dostawcy, a nie z sieci
Windows definiuje krótką listę typów połączeń dla swoich wbudowanych klientów VPN, a produkty firm trzecich instalują obok nich własny stos. Adapter widoczny na liście sieci jest tworzony przez sterownik, do którego należy połączenie, więc jego nazwa jest dowodem dotyczącym sterownika, a nie gwarancją dotyczącą zewnętrznego protokołu. Dlatego odinstalowanie jednego klienta może pozostawić nazwę adaptera.
Dokumentacja Microsoftu dotycząca typów połączeń VPN wyraźnie stwierdza, że typ opisuje konfigurację klienta dla tego połączenia. Gdy uczestniczy wtyczka, wyświetlany typ podąża za tym, co rejestruje wtyczka, a rzeczywista enkapsulacja może być czymś zupełnie innym.
To samo warstwowanie pojawia się gdzie indziej. Wirtualny adapter na hoście Linux, urządzenie TAP lub rozszerzenie usługi mobilnego VPN to interfejsy tworzone przez oprogramowanie, a nazwę interfejsu wybiera to oprogramowanie, a nie negocjuje jej z serwerem.
Co porty i adresy mogą, a czego nie mogą ci powiedzieć
Każda warstwa pozostawia inne dowody. Czytaj je osobno, a etykieta przestaje być wyrokiem:
| Evidence | What it establishes | Where it misleads |
|---|---|---|
| Adapter name | Which driver bound the interface | Plugins choose their own labels |
| Profile file | Which client consumes the configuration | Abstraction layers hide the transport |
| Outer port | Which port the peer accepts | 443 carries several protocols plus HTTPS |
| Tunnel address | The inner interface's network | Says nothing about encapsulation |
TCP 443 to najjaśniejszy przykład. Może przenosić SSTP, tunel OpenVPN TCP, sesję SoftEther SSL-VPN lub zwykły ruch internetowy, a sam numer portu nie potrafi ich rozróżnić. Dlatego reguła zapory, która zezwala na 443, nie jest dowodem na to, który klient jest używany. Zapis na interfejsie zewnętrznym rozstrzyga to i rozstrzyga w kilka sekund.
Przeczytaj format profilu i partnera
Plik konfiguracji jest mocniejszą wskazówką niż adapter. Profil OpenVPN zawiera dyrektywy takie jak remote, proto i ca; konfiguracja WireGuard zawiera sekcję [Interface] z kluczem prywatnym i sekcje [Peer] z dozwolonymi adresami IP; wpis w książce telefonicznej Windows przechowuje typ połączenia we własnym formacie. Każda składnia należy do jednej implementacji.
Następnie spójrz na dokumentację i dzienniki partnera. Serwer wie, który obsługujący protokół przyjął sesję, a jego dziennik nazywa ukończony etap. Ten dowód bije każdą etykietę na pulpicie, ponieważ jest zapisywany tam, gdzie pakiety zostały naprawdę zinterpretowane.
Wybierz instrukcję według protokołu, a nie według etykiety
Dyrektywa OpenVPN należy do OpenVPN, klucze i dozwolone adresy IP WireGuard należą do WireGuard, a profil SSTP nie jest ani jednym, ani drugim. Wklejenie opcji jednego klienta do drugiego, bo nazwa adaptera brzmiała zgodnie, to sposób na zepsucie działającej konfiguracji.
Po zidentyfikowaniu protokołu wybierz odpowiednią ścieżkę rozwiązywania problemów: dziennik samego klienta, dziennik serwera specyficzny dla protokołu i zapis pokazujący wymianę zewnętrzną. Od tego momentu awaria ma nazwę zamiast etykiety.