Hvad et virtuelt hub i SoftEther faktisk forbinder
Et virtuelt hub er en medlemskabsgrænse inde i én server, ikke et udgangsland. Dets vedhæftninger afgør, hvad en tilsluttet session kan nå, og DNS står separat.
SoftEthers virtuelle hub er en medlemskabsgrænse inde i én server, ikke en placering. Sessioner, der tilslutter sig hubben, kan nå det, hubben er vedhæftet, og sessioner på en anden hub kan ikke, selv når begge godkendes mod den samme server. Derfor kan et vellykket login stadig placere en klient på det forkerte netværk. At læse hubben som en virtuel switch tydeliggør, hvad den gør, og hvad den overlader til brokobling, routing og kaskadekonfiguration.
En hub er en medlemskabsgrænse
Én server kan hoste flere hubs, hver med sine egne brugere, sessioner og politik. Godkendelse fastslår, hvem sessionen er, mens hubben afgør, hvilket virtuelt netværk den session tilslutter sig. To hubs på én host opfører sig derfor som to separate switches, der tilfældigvis deler hardware. Intet ved et vellykket login indebærer, at sessionen landede, hvor du havde tænkt dig.
Brug operatørens dokumenterede hubnavn i stedet for et navn, der er husket fra et skærmbillede. En klient, der tilslutter sig den forkerte hub, når et andet netværk med en gyldig legitimationsoplysning, hvilket er en konfigurationserfaring og ikke et sikkerhedsbrud. Opbevar hubnavnet og dets formål i forbindelsesprofilens noter.
Administration er afgrænset på samme måde. En hubadministrator styrer den hub, mens serveradministratoren styrer processen, lytterne og hver hub på hosten.
Vedhæftninger afgør, hvad der ligger hinsides
En hub forbinder i sig selv sessioner med hinanden. At nå noget andet afhænger af, hvordan hubben er vedhæftet: en lokal bro til en fysisk grænseflade, en virtuel router eller en kaskade til en anden server. Hver vedhæftning bærer sine egne videresendelsesregler og sine egne fejltilstande. At antage, at en hub giver internetadgang, er den mest almindelige fejl om produktet.
SecureNAT er den indbyggede mulighed, implementeret med en virtuel router og en virtuel DHCP-tjeneste inde i serveren. Den er bekvem til et laboratorium og akavet til alt, der kræver forudsigelig adressering eller politik. En lokal bro sætter hubben på et rigtigt segment, som arver dette segments switching, DHCP og broadcast-adfærd.
En kaskade forbinder to servere, så sessioner på den ene hub kan fremstå på den anden. Det er et hub-til-hub-forhold, så begge ender har brug for kompatibel politik og en fungerende vej imellem sig.
Læs sessioner og politik separat
Visninger af sessioner, MAC-adresser og IP-adresser beskriver, hvordan det virtuelle netværk ser ud lige nu. Det er observationer, ikke tilladelser. En session, der er synlig i listen, er dermed ikke berettiget til hver tjeneste, hubben kan nå, og det omvendte gælder også.
Sammenlign sessionslisten med den politik, der bør gælde for den. En enhed med en adresse uden for det tilsigtede interval betyder normalt DHCP fra et andet sted eller en klient, der er konfigureret manuelt. En MAC-adresse, der flytter mellem sessioner, betyder en flyttet enhed eller to enheder, der deler en identitet. Begge er et kig værd, og ingen af dem bevises af tabellen alene.
På serveren rapporterer vpncmd det samme billede fra hostens synspunkt. Sammenlign det output med klientens eget syn, når de to er uenige.
vpncmd localhost /SERVER /CMD SessionList
vpncmd localhost /SERVER /CMD HubList
Behandl hubadministration som en egen rolle i stedet for en klienttilladelse. Delegation af en hub bør ikke overdrage lytterne eller den proces, der hoster hver anden hub.
Kontrollér klienten efter tilslutning
Fra klientsiden beviser en etableret session kun, at godkendelse og hubnavn blev accepteret. Bekræft adressen, ruten og navneopløsningen separat, fordi hver af dem kan fejle, efter at hubben har accepteret sessionen.
ip -brief address show
ip route get 10.20.30.41
resolvectl query host.internal
Adresselisten viser, om adapteren modtog en leje fra den tilsigtede kilde. Ruteanmodningen viser, hvilken grænseflade der ville bære en privat destination, og resolver-anmodningen viser, om DNS fulgte sessionen. En hub, der videresender pakker, mens DNS stadig peger på det lokale netværk, frembringer den klassiske halvt fungerende forbindelse.
Test applikationen i stedet for linket. En intranetside, der indlæses, er stærkere bevis end en adapter med en plausibel adresse.