Wi-Fi-aksespunkt bak ein VPN-gateway: hald på eitt LAN

Brutta aksesspunkt eller eit andre ruta segment? Skilnaden er kven som eig adressering, DNS og tunnelen, og det avgjer kvar policyen bur.

Trådlause klientar kan sitje bak ein VPN utan at aksesspunktet veit noko om tunnelen. Brøyt radioen over på LAN-et til gatewayen, lat gatewayen eige adressering og tunnel, og kvar eining på Wi-Fi-en arvar same policy. Alternativet, eit andre ruta segment med sin eigen gateway, er eit anna design med ein annan feilmodus.

Dei to vert forveksla fordi begge set ei boks mellom internett og einingane dine. Å samanlikne kva kvar av dei eig er den snøggaste måten å velje.

To måtar å setje VPN-en framfor Wi-Fi-en

I eit brutto oppsett ber aksesspunktet rammer mellom radioen og det kabelbundne segmentet og ingenting anna: eitt subnett, éin adressestyresmakt, éin ruter som utfører policyen. I eit ruta oppsett har den andre boksa eigne adresser, eige DHCP-område og eigen standardrute, så trafikken kryssar nok ei grense før han når tunnelen. Det brutto designet får kvar trådlaus eining til å sjå lokal ut for gatewayen, og difor dekkjer eitt regelsett dei alle. Det ruta designet gjev deg eit segment å tenkje over og ein annan stad der policyen kan gå gale.

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

Vel brutto når kravet er at trådlause einingar brukar same tunnel som kabelbundne. Vel ruta når du vil ha eit segment som kan isolerast, eller når den andre boksa alt finst som ruter.

Kva det brutto oppsettet faktisk endrar

Brøyting fjernar eit omsetjingslag og ein konkurrerande standardgateway, og legg til eit administrasjonsproblem. Aksesspunktet treng framleis ei adresse du kan nå, som arbeidsflyten til leverandøren vanlegvis ordnar via hovud-LAN-et. DHCP-tenesta må vere av, elles vil to styresmakter dela ut motstridande leiger. Gatewayen held på tunnelen, innstillingane for resolveren og avgjerda om kva som skjer når tunnelen fell, så policyen bur på nøyaktig éin stad.

Radioen arvar ingenting av dette automatisk frå tunnelen. Han sluttar berre å leggje til lag som ville sløre det.

Kvar eit andre ruta segment passar

Eit ruta segment fortener kompleksiteten sin når einingane bak det treng ei anna handsaming enn resten av LAN-et. Eit gjestenettverk, eit laboratorium eller ei gruppe klientar som alltid må ut gjennom eit bestemt land er alle grunnar til å setje ein ruter i vegen. Prisen er ei andre adressestyresmakt, ein andre brannmur som må haldast konsistent, og ei returrute frå hovud-LAN-et om nokon der treng å nå segmentet. Det er plikter, ikkje konfigurasjonsdetaljar.

Den vanlege feilen er å byggje den ruta versjonen ved eit uhell, ved å bruke om att ein ruter som framleis køyrer sin eigen DHCP og omsetjing. Det gjev dobbel omsetjing og ein policy ingen kan spore.

Test frå ein Wi-Fi-klient, ikkje frå gatewayen

Ein vellukka førespurnad på gatewayen provar at tunnelen verkar for gatewayen. Det eigentlege spørsmålet er om vidaresend trafikk frå ein trådlaus klient brukar han, og det må observerast frå klienten. Kommandoane nedanfor sjekkar adressa til klienten, ruta hans og adressa ein ekstern teneste 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

Ei adresse inne i LAN-et til gatewayen stadfestar at brua slepp rammer gjennom i staden for å omsetje dei. Ei rute der fyrste hopp er gatewayen stadfestar at klienten ikkje har fått ei andre standardrute frå ein annan stad. Sjekken av utgangsadressa svarar på det eigentlege spørsmålet, og den korte sporinga viser om dei fyrste hoppa er dei venta. Om adressa til klienten kjem frå eit anna område, er ein villfaren DHCP-tenar den fyrste mistenkte.

Skriv ned rolla til kvar boks, adressa og DHCP-styresmakta. Eit diagram med tre linjer er nok, og det avgjer dei fleste diskusjonane om kvar ei regel høyrer heime.

Relaterte artiklar