Ce conectează de fapt un hub virtual SoftEther

Hubul virtual SoftEther este o limită de apartenență în interiorul unui server, nu o locație. Sesiunile care se alătură hubului pot atinge ceea ce este conectat hubul, iar sesiunile de pe alt hub nu pot, chiar și când ambele se autentifică pe același server. De aceea o autentificare reușită poate totuși plasa un client în rețeaua greșită. Citirea hubului ca un comutator virtual clarifică ce face și ce lasă punții, rutării și configurației de cascadă.

Un hub este o limită de apartenență

Un server poate găzdui mai multe huburi, fiecare cu utilizatorii, sesiunile și politica sa. Autentificarea stabilește cine este sesiunea, în timp ce hubul decide în ce rețea virtuală se alătură acea sesiune. Două huburi pe același gazdă se comportă deci ca două comutatoare separate care împart din întâmplare hardware. Nimic într-o autentificare reușită nu implică faptul că sesiunea a aterizat acolo unde intenționați.

Folosiți numele hubului documentat de operator, nu un nume reținut dintr-o captură de ecran. Un client care se alătură hubului greșit ajunge în altă rețea cu o acreditare validă, ceea ce este o constatare de configurare și nu o breșă de securitate. Păstrați numele hubului și scopul său în notele profilului de conexiune.

Administrarea este delimitată în același mod. Un administrator de hub administrează acel hub, în timp ce administratorul serverului administrează procesul, ascultătorii și fiecare hub de pe gazdă.

Conexiunile decid ce se află dincolo

Un hub în sine conectează sesiunile între ele. Atingerea oricui altceva depinde de modul în care hubul este conectat: o punte locală către o interfață fizică, un router virtual sau o cascadă către alt server. Fiecare conexiune poartă propriile reguli de redirecționare și propriile moduri de eșec. A presupune că un hub oferă acces la internet este cea mai frecventă greșeală despre produs.

SecureNAT este opțiunea încorporată, implementată cu un router virtual și un serviciu DHCP virtual în interiorul serverului. Este comodă pentru un laborator și incomodă pentru orice are nevoie de adresare sau politică previzibilă. O punte locală pune hubul într-un segment real, care moștenește comutarea, DHCP și comportamentul de difuzare al acelui segment.

O cascadă leagă două servere astfel încât sesiunile de pe un hub să poată apărea pe celălalt. Este o relație hub-la-hub, așa că ambele capete au nevoie de politică compatibilă și de o cale funcțională între ele.

Citiți sesiunile și politica separat

Vizualizările sesiunilor, adreselor MAC și adreselor IP descriu cum arată rețeaua virtuală acum. Sunt observații, nu permisiuni. O sesiune vizibilă în listă nu este prin aceasta îndrituită la fiecare serviciu la care poate ajunge hubul, iar inversul este și el valabil.

Comparați lista sesiunilor cu politica ce ar trebui aplicată. Un dispozitiv cu o adresă în afara intervalului prevăzut înseamnă de obicei DHCP de altundeva sau un client configurat manual. O adresă MAC care se mută între sesiuni înseamnă un dispozitiv migrat sau două dispozitive care împart o identitate. Ambele merită o privire, și niciunul nu este dovedit doar de tabel.

Pe server, vpncmd raportează aceeași imagine din punctul de vedere al gazdei. Comparați acea ieșire cu vizualizarea clientului însuși ori de câte ori cele două nu sunt de acord.

vpncmd localhost /SERVER /CMD SessionList
vpncmd localhost /SERVER /CMD HubList

Tratați administrarea hubului ca un rol propriu, nu ca o permisiune de client. Delegarea unui hub nu ar trebui să predea ascultătorii sau procesul care găzduiește fiecare alt hub.

Verificați clientul după alăturare

Din partea clientului, o sesiune stabilită dovedește doar că autentificarea și numele hubului au fost acceptate. Confirmați adresa, ruta și rezolvarea numelor separat, deoarece fiecare poate eșua după ce hubul a acceptat sesiunea.

ip -brief address show
ip route get 10.20.30.41
resolvectl query host.internal

Lista adreselor arată dacă adaptorul a primit o închiriere de la sursa prevăzută. Interogarea rutei arată ce interfață ar transporta o destinație privată, iar interogarea resolverului arată dacă DNS a urmat sesiunea. Un hub care redirecționează pachete în timp ce DNS indică încă rețeaua locală produce clasica conexiune pe jumătate funcțională.

Testați aplicația, nu legătura. O pagină de intranet care se încarcă este o dovadă mai puternică decât un adaptor cu o adresă plauzibilă.