Wi-Fi verkar gjennom VPN-en på rutaren. Kva med dei kabelbundne portane?

Wi-Fi-berbare viser utgangsadressa til VPN-en, og den kabelbundne stasjonære maskina i naborommet viser leverandøra si. Begge er kopla til same rutar, så skilnaden er ikkje VPN-konfigurasjonen. Skilnaden er kva grensesnitt, VLAN eller policy trafikken faktisk gjekk gjennom. Dekning er ein eigenskap per veg, ikkje ein eigenskap ved boksen.

Å samanlikne dei to klientane side om side finn skilnaden raskare enn å lese reglane til rutaren.

To vegan inn til same rutar

Ein rutar med VPN-klient kan styre trafikk frå éi bru, eitt VLAN eller éi portliste og la resten bli på WAN. Det er eit normalt design, og difor beviser ein vellukka trådlaus test berre den trådlause vegen. Ein administrert svitsj kan òg setje ein veggport på eit anna segment enn det tilgangspunktet brukar, utan at nokon rører rutaren. Portbaserte policyar er dei lettaste å oversjå, fordi porten ser ut som ein del av same LAN.

Same maskinvare, annan policy. Den fysiske boksen er ikkje grensa du trur.

Samanlikn gatewayen kvar klient faktisk brukar

På den kabelbundne eininga les du det aktive grensesnittet, adressa og standardgatewayen. På ei maskin med både Wi-Fi og Ethernet oppe avgjer rutingsmetrikken kven som vinn, og det er ofte ikkje den du ventar. Samanlikn den gatewayen med den den trådlause klienten brukte, og sjekk kva rutarnett svitsjporten høyrer til. Oppskrifta for WireGuard-klient i pfSense viser korleis éin rutar kan eige ein tunnel og la andre grensesnitt vere i fred.

Viss dei to gatewayane er ulike, har du svaret før du rører ein einaste brannmurregel.

Samanlikn DNS og IPv6 kvar for seg

Ein kabelbunden klient med manuelt konfigurert resolver kan omgå DNS-policyen til rutaren heilt, sjølv når trafikken blir styrt rett. IPv6 er den andre halvdelen: ein tunnel som berre handterer IPv4, kan la IPv6-trafikk bli på den opphavlege vegen. Test eit namneoppslag og ein IPv6-destinasjon frå den kabelbundne eininga, ikkje berre ein IPv4-adressekontroll. Bruk ei spørjing som berre resolvaren til rutaren kunne svare på, som eit internt vertsnamn.

Kvar av desse er ei eiga samanlikning, og kvar av dei kan feile på eiga hand.

Samanlikn kva som skjer når tunnelen er nede

Viss designet krev tilgang berre via VPN, stopp tunnelen og test den kabelbundne klienten med ufarleg trafikk. Ei kabelbunden eining som fell tilbake på vanleg WAN, blir verande på nett men bommar på den tiltenkte ruta, noko som ser ut som suksess for alle som berre sjekkar tilkoplinga. Den trådlause klienten kan oppføre seg annleis, og nettopp den skilnaden er samanlikninga verd.

Feilåtferd er ein del av dekninga, ikkje eit særtilfelle etterpå.

Tilskriv resultatet rett lag

Ein VPN-klient på einingsnivå eller ein nettlesarproxy på den kabelbundne maskina kan endre den målte utgangsadressa uavhengig av rutaren. Noter kva lag som var aktive under testen, elles blir ei vellukka adresseendring kreditert feil gateway. Same varsemd gjeld for eit bufra resultat frå før endringa.

Test fersk trafikk, noter laga, og skriv ned segmentet og grensesnittet. Den registreringa er det som gjer neste samanlikning meiningsfull i staden for enno ei gissing.