Wi-Fi-aksespunkt bak en VPN-gateway: behold ett LAN

Trådløse klienter kan sitte bak en VPN uten at aksesspunktet vet noe om tunnelen. Bro radioen over på gatewayens LAN, la gatewayen eie adressering og tunnel, og hver enhet på Wi-Fi-en arver samme policy. Alternativet, et andre rutet segment med sin egen gateway, er et annet design med en annen feilmodus.

De to forveksles fordi begge setter en boks mellom internett og enhetene dine. Å sammenligne hva hver av dem eier er den raskeste måten å velge.

To måter å sette VPN-en foran Wi-Fi-en

I et broet oppsett bærer aksesspunktet rammer mellom radioen og det kablede segmentet og ingenting annet: ett subnett, én adressemyndighet, én ruter som utfører policyen. I et rutet oppsett har den andre boksen egne adresser, eget DHCP-område og egen standardrute, så trafikken krysser nok en grense før den når tunnelen. Det broede designet får hver trådløs enhet til å se lokal ut for gatewayen, og derfor dekker ett regelsett dem alle. Det rutede designet gir deg et segment å tenke over og et andre sted hvor policyen kan gå galt.

internet
  -> vpn-capable gateway: routing, tunnel, dns, failure policy
  -> bridged access point: radio onto the same lan
  -> wifi clients

Velg broet når kravet er at trådløse enheter bruker samme tunnel som kablede. Velg rutet når du vil ha et segment som kan isoleres, eller når den andre boksen allerede finnes som ruter.

Hva det broede oppsettet faktisk endrer

Broing fjerner et oversettelseslag og en konkurrerende standardgateway, og legger til et administrasjonsproblem. Aksesspunktet trenger fortsatt en adresse du kan nå, som leverandørens arbeidsflyt vanligvis ordner via hoved-LAN-et. DHCP-tjenesten må være av, ellers vil to myndigheter dele ut motstridende leier. Gatewayen beholder tunnelen, innstillingene for resolveren og beslutningen om hva som skjer når tunnelen faller, så policyen bor på nøyaktig ett sted.

Radioen arver ingenting av dette automatisk fra tunnelen. Den slutter bare å legge til lag som ville sløre det.

Hvor et andre rutet segment passer

Et rutet segment fortjener kompleksiteten sin når enhetene bak det trenger en annen behandling enn resten av LAN-et. Et gjestenettverk, et laboratorium eller en gruppe klienter som alltid må ut gjennom et bestemt land er alle grunner til å sette en ruter i veien. Prisen er en andre adressemyndighet, en andre brannmur som må holdes konsistent, og en returrute fra hoved-LAN-et hvis noen der trenger å nå segmentet. Det er forpliktelser, ikke konfigurasjonsdetaljer.

Den vanlige feilen er å bygge den rutede versjonen ved et uhell, ved å gjenbruke en ruter som fortsatt kjører sin egen DHCP og oversettelse. Det gir dobbel oversettelse og en policy ingen kan spore.

Test fra en Wi-Fi-klient, ikke fra gatewayen

En vellykket forespørsel på gatewayen beviser at tunnelen virker for gatewayen. Det egentlige spørsmålet er om en trådløs klients videresendte trafikk bruker den, og det må observeres fra klienten. Kommandoene nedenfor sjekker klientens adresse, ruten og adressen en ekstern tjeneste ser.

ip -4 addr show wlan0
ip route get 1.1.1.1
curl -sS https://api.ipify.org; echo
traceroute -n -m 4 1.1.1.1

En adresse inne i gatewayens LAN bekrefter at broen slipper rammer gjennom i stedet for å oversette dem. En rute der første hopp er gatewayen bekrefter at klienten ikke har fått en andre standardrute fra et annet sted. Sjekken av utgangsadressen svarer på det egentlige spørsmålet, og den korte sporingen viser om de første hoppene er de forventede. Hvis klientens adresse kommer fra et annet område, er en villfaren DHCP-server den første mistenkte.

Skriv ned rollen til hver boks, adressen og DHCP-myndigheten. Et diagram med tre linjer er nok, og det avgjør de fleste diskusjoner om hvor en regel hører hjemme.