SoftEther lokal bro kontra SecureNAT: hvad du skal slå til

Åbn SoftEther Manager, og den første rigtige beslutning om en hub er ikke en afkrydsningsboks, det er et topologispørgsmål. En lokal bro knytter hubben til en fysisk adapter og lader det eksisterende segment levere adresseringen, mens SecureNAT giver hubben sin egen virtuelle router, NAT og DHCP. Valget mellem dem ændrer, hvor adresserne kommer fra, og hvilken enhed der svarer på dem. At slå begge til og håbe på, at én vinder, er måden et fungerende laboratorium bliver til en supporttråd.

Begynd med den hub, du faktisk redigerer

Manager viser et træ af servere og hubs, og det er nemt at konfigurere standardhubben, mens klienterne forbinder til en anden med et andet navn. Klik på hubben, læs dens navn, og bekræft at sessionerne nedenunder er de klienter, du prøver at betjene. Den ene kontrol forhindrer det meste af den forvirring, der bagefter får skylden for protokollen.

Beslut derefter, hvad klienten har brug for fra den fjerne ende. Delt Ethernet-adfærd med broadcast og LAN-tjenester peger på en bro, rutet privat adgang til et lille adresseområde peger på SecureNAT, og en internetudgang er en routingbeslutning, som begge arrangementer kan bære dårligt.

Skriv svaret ned, før du klikker på noget, for de to indstillinger kan ikke udskiftes, og fortrydelse tager længere tid end beslutningen. To minutters skrivning sparer en times genopkobling.

Hvad en lokal bro gør ved adresseringen

En lokal bro forbinder hubben til en fysisk adapter, så hubben bliver en del af det Ethernet-segment. Klienterne får adresser fra det, der allerede betjener segmentet, og deres gateway er segmentets router. Fra klientens synspunkt er den trådt ind i kontorets LAN med al den nåbarhed og al den eksponering, det indebærer.

Det betyder også, at broen kræver en rigtig adapter med den rette driverunderstøttelse, og at administratoren skal være autoriseret til at udvide segmentet. Et VPN-login beviser autentificering, ikke retten til at placere en vært på et produktions-VLAN. Kontrollér, at drivernavnet passer til den adapter, du har tænkt dig, for at bro den forkerte port tager et segment ned hurtigt. Hvis adapterlisten er tom, eller broen rapporterer en fejl, er svaret normalt relateret til driver eller rettigheder frem for kryptografi.

Læs brotabellen fra kommandolinjen, når det grafiske træ er tvetydigt. Outputtet navngiver adapteren, hvilket træet ikke altid gør.

vpncmd /SERVER localhost /HUB VPN /CMD BridgeList
vpncmd /SERVER localhost /HUB VPN /CMD SessionList

En tom broliste med tilsluttede sessioner er et nyttigt billede: klienterne er inde i den virtuelle hub, og intet udvider den til et segment endnu.

Hvad SecureNAT tilføjer, og hvad den skjuler

SecureNAT giver hubben en virtuel router, en NAT-funktion og en DHCP-tjeneste, alt sammen inde i SoftEther-processen. Klienterne får adresser fra det virtuelle DHCP-område, den virtuelle router svarer på standardgatewayen, og trafik, der skal ud, oversættes. Ingen fysisk adapter er involveret, og derfor virker det på en vært med ét netkort og ingen switchkonfiguration.

Prisen er, at de virtuelle adresser tilhører hubben og intet andet. En maskine på kontorets LAN kan ikke route til en klients SecureNAT-adresse uden hjælp, og alt, der logger kildeadresser, ser den oversatte adresse på SoftEther-værten. Hvis dine adgangsregler eller dit revisionsspor afhænger af klientens rigtige adresse, er det en designændring og ikke en detalje. Det afgør også, om en kildeadresseregel nogensinde vil se klienten.

Den er også en DHCP-server. At køre den på et segment, der allerede har en, eller at bro det segment samtidig, giver to svarere og uforudsigelige leases. Manualen behandler de to funktioner som separate valg netop af den grund.

Undersøg, hvad hubben betjener lige nu, før du aktiverer noget andet. Hver kommando udskriver den aktuelle tilstand frem for den tilsigtede.

vpncmd /SERVER localhost /HUB VPN /CMD SecureNatStatusGet
vpncmd /SERVER localhost /HUB VPN /CMD NatGet
vpncmd /SERVER localhost /HUB VPN /CMD DhcpGet

Slå den ene til uden at ødelægge den anden

Vælg arrangementet, aktivér det, og lad den anden være slået fra. En hub med både en bro og SecureNAT aktiv er en hub med to mulige svar på det samme spørgsmål, og klienten vil tro på det, der kommer først. Når du migrerer fra den ene til den anden, skal du deaktivere den gamle funktion og genopkoble klienten i stedet for at antage, at den nye indstilling virker på en eksisterende session.

Planlæg ændringen, så klientpuljen ikke overlapper LAN-området. Overlappende subnets er den næsthyppigste årsag til en tunnel, der forbinder og derefter ikke kan nå noget, og de er usynlige, indtil du sammenligner begge adresseplaner side om side.

Genopkobl derefter fra klienten, og læs hvad den fik, for hubbens syn på sessionen er ikke klientens syn på sit eget netværk. En genopkobling er den eneste pålidelige måde at fremtvinge en frisk lease.

Kontrollér gatewayen og resolveren på klienten

En vellykket autentificering fortæller, at legitimationsoplysningerne virker, og at hubben accepterede sessionen. Den siger intet om, hvorvidt klienten kan nå noget, for det afhænger af den adresse, maske, gateway og DNS-server, den fik. Læs de fire værdier på klienten, før du rører ved en serverindstilling igen.

På Windows viser adapterdetaljerne leasen og resolveren, og rutetabellen viser, om tunnelen faktisk er standardvejen.

ipconfig /all
route print -4
nslookup intranet.corp.internal

På en Linux-klient kommer de samme oplysninger fra filerne for adresse, ruter og resolver. Standardruten er den værdi, der afgør, om trafik overhovedet forlader tunnelen. Hvis gatewayen peger på kontorets router, mens tunnelen forventer at bære trafikken, er topologien broet i navnet og brudt i praksis. Ret adressekilden først, test applikationen igen, og overvej først derefter at ændre den anden tilstand.