Wi-Fi virker gjennom VPN-en på ruteren. Hva med de kablede portene?
En vellykket Wi-Fi-test beviser ikke at en kablet port bruker samme policy. Sammenlign gateway, VLAN og DNS på den kablede enheten selv.
Wi-Fi-bærbaren viser utgangsadressen til VPN-en, og den kablede stasjonære maskinen i naborommet viser leverandørens. Begge er koblet til samme ruter, så forskjellen er ikke VPN-konfigurasjonen. Forskjellen er hvilket grensesnitt, VLAN eller policy trafikken faktisk gikk gjennom. Dekning er en egenskap per vei, ikke en egenskap ved boksen.
Å sammenligne de to klientene side om side finner forskjellen raskere enn å lese ruterens regler.
To veier inn til samme ruter
En ruter med VPN-klient kan styre trafikk fra én bro, ett VLAN eller én portliste og la resten bli på WAN. Det er et normalt design, og derfor beviser en vellykket trådløs test bare den trådløse veien. En administrert svitsj kan også sette en veggport på et annet segment enn det tilgangspunktet bruker, uten at noen rører ruteren. Portbaserte policyer er de letteste å overse, fordi porten ser ut som en del av samme LAN.
Samme maskinvare, annen policy. Den fysiske boksen er ikke grensen du tror.
Sammenlign gatewayen hver klient faktisk bruker
På den kablede enheten leser du det aktive grensesnittet, adressen og standardgatewayen. På en maskin med både Wi-Fi og Ethernet oppe avgjør rutingsmetrikken hvem som vinner, og det er ofte ikke den du forventer. Sammenlign den gatewayen med den den trådløse klienten brukte, og sjekk hvilket ruternett svitsjporten hører til. Oppskriften for WireGuard-klient i pfSense viser hvordan én ruter kan eie en tunnel og la andre grensesnitt være i fred.
Hvis de to gatewayene er forskjellige, har du svaret før du rører en eneste brannmurregel.
Sammenlign DNS og IPv6 hver for seg
En kablet klient med manuelt konfigurert resolver kan omgå ruterens DNS-policy helt, selv når trafikken styres riktig. IPv6 er den andre halvdelen: en tunnel som bare håndterer IPv4, kan la IPv6-trafikk bli på den opprinnelige veien. Test et navneoppslag og en IPv6-destinasjon fra den kablede enheten, ikke bare en IPv4-adressekontroll. Bruk en spørring som bare ruterens resolver kunne svare på, som et internt vertsnavn.
Hver av disse er en egen sammenligning, og hver av dem kan feile på egen hånd.
Sammenlign hva som skjer når tunnelen er nede
Hvis designet krever tilgang kun via VPN, stopp tunnelen og test den kablede klienten med ufarlig trafikk. En kablet enhet som faller tilbake på vanlig WAN, forblir online men bommer på den tiltenkte ruten, noe som ser ut som suksess for alle som bare sjekker tilkoblingen. Den trådløse klienten kan oppføre seg annerledes, og nettopp den forskjellen er sammenligningen verdt.
Feilatferd er en del av dekningen, ikke et særtilfelle etterpå.
Tilskriv resultatet riktig lag
En VPN-klient på enhetsnivå eller en nettleserproxy på den kablede maskinen kan endre den målte utgangsadressen uavhengig av ruteren. Noter hvilke lag som var aktive under testen, ellers blir en vellykket adresseendring kreditert feil gateway. Samme forsiktighet gjelder for et bufret resultat fra før endringen.
Test fersk trafikk, noter lagene, og skriv ned segmentet og grensesnittet. Den registreringen er det som gjør neste sammenligning meningsfull i stedet for enda en gjetning.