Roeteerder in VPN-kliëntmodus: waarom LAN-toestelle verdwyn
LAN-toestelle verdwyn nadat 'n roeteerder in VPN-kliëntmodus oorgaan: toets eers die inspeksiefunksie in die aanstuurpad en dan die LAN-reeks wat die firmware onder jou verander het.
As jy glo dat die kliëntmodus self LAN-toegang doodmaak, beland jy in die verkeerde instellingskieslys, en die werklike oorsake is gewoonlik twee. Die tonnel verwyder nie die LAN-brug nie en keer ook nie dat bedrade en draadlose kliënte mekaar bereik nie. Wat plaaslike toegang breek, is óf 'n inspeksiefunksie in die roeteerder se aanstuurpad óf 'n LAN-adresreeks wat verskuif het toe die firmware dit gedoen het. Albei lewer dieselfde klag, en nie een word reggemaak deur die VPN-profiel weer te installeer nie.
Die mite, en wat kliëntmodus werklik verander
Kliëntmodus voeg 'n tonnelkoppelvlak en 'n verstekroete by wat daardeur wys, en stuur dan LAN-verkeer in daardie tonnel in. Die brug tussen die bedrade poorte en die draadlose radios bly ongeraak, en plaaslike skakeling ook. Wat verander, is beleid: watter verkeer aangestuur word, waar dit vertaal word en watter resolver die kliënte ontvang.
Daardie onderskeid maak saak, want 'n gebreekte LAN beteken gewoonlik dat een van daardie drie beleide verander het, nie dat die roeteerder opgehou het om 'n skakelaar te wees nie. 'n Roeteerder wat nog sy eie administrasiebladsy antwoord, is bewys dat die LAN-koppelvlak leef. 'n Roeteerder wat glad nie antwoord nie, het 'n ander probleem, soos 'n veranderde LAN-adres of 'n kliënt op die verkeerde subnet.
Die nuttige eerste stap is dus om te vind watter laag gebreek het, nie om die laag te verander wat jy vermoed nie.
Toets drie teikens voordat jy aan 'n instelling raak
Vanaf 'n bedrade kliënt, toets drie teikens afsonderlik en skryf elke resultaat neer: die roeteerder se eie LAN-adres, een ander toestel op dieselfde skakelaar per IP, en iets wat net deur die tonnel bereikbaar is. Doen hulle in daardie volgorde, want elke resultaat sluit 'n ander laag uit. Gebruik adresse eerder as name vir die eerste rondte, want 'n naamfout meng DNS in 'n verbindingsvraag in.
Die patroon van antwoorde is die diagnose. 'n Roeteerder wat antwoord terwyl plaaslike toestelle dit nie doen nie, wys na plaaslike skakeling of 'n filterfunksie eerder as na roetebeheer. Plaaslike toestelle wat antwoord terwyl die tonnelkant dit nie doen nie, wys na die tonnelroete of die afgeleë firewall. Alles wat per adres antwoord terwyl name misluk, is 'n resolver-vraag, en geen hoeveelheid roetebewerking sal dit regmaak nie.
| What answers | What it points at |
|---|---|
| Router only | LAN-side filtering or a broken bridge |
| Router and local hosts, not remote | Tunnel route, NAT or remote firewall |
| Addresses yes, names no | DNS handed to clients by the router |
| Nothing at all | Client subnet or router LAN address changed |
Hou die tabel by die toetsresultate. Dit verander 'n vae klag in een reël waarvolgens jy kan optree.
Die sekuriteitslaag binne die aanstuurpad
Verbruikersroeteerders word al hoe meer met 'n inspeksiefunksie verskaf wat aangestuurde verkeer dop, en dit loop in dieselfde pad wat LAN-na-tonnel-pakkette dra. Wanneer daardie inspeksie die tonnelverkeer nie kan klassifiseer nie, kan aansturing vasval terwyl die tonnel self aan bly en die roeteerder 'n gesonde verbinding rapporteer. Niks in die VPN-log wys dit nie, want die VPN het wel verbind.
Die diagnose is 'n beheerde eksperiment, nie 'n permanente verandering nie. Let op die huidige instelling, skakel die funksie vir die duur van een toets af, bring die tonnel weer op en toets 'n enkele plaaslike gasheer per adres. Aansturing wat terugkom, is die bewys wat jy nodig gehad het, en die afweging word dan 'n besluit eerder as 'n raaiskoot. As niks verander nie, skakel dit dadelik weer aan en beweeg na die adresseringsoorsaak.
Om 'n betaalde sekuriteitsfunksie gedeaktiveer te laat sodat 'n tonnel bly werk, is 'n afweging wat jy doelbewus maak en neerskryf. Dit is ook die moeite werd om te vra of die tonnel op 'n ander toestel hoort, want 'n roeteerder wat alles moet inspekteer en 'n roeteerder wat alles moet aanstuur, is twee verskillende take.
Die tweede oorsaak: die LAN-reeks het verskuif
Firmware-opdaterings stel die LAN-adres gereeld terug na die verskaffer se verstek, en sommige roeteerders het 'n eksplisiete modusskakelaar wat besluit of die LAN 'n private reeks hou of een van die opstroomtoestel erf. 'n Kliënt wat 192.168.8.x verwag, kan op 10.64.0.x beland, en dan verstryk 'n SSH-sessie na 'n gasheer terwyl die tonnel heeltemal gesond is.
ipconfig /all
ip addr show
ip route get 192.168.8.20Lees die voorvoegsel en die poort in die huurkontrak voordat jy die roeteerderblad oopmaak. Die eerste twee opdragte wys wat die kliënt werklik ontvang het, en die derde wys watter koppelvlak die kliënt vir 'n plaaslike adres sou gebruik, wat is hoe 'n oorblywende roete of 'n verouderde subnet homself verraai. Vergelyk dit dan met die LAN-blad en die modus waarin die roeteerder is.
As die reeks nie kan terugkeer nie, werk elke objek by wat dit noem: DHCP-reserverings, enige statiese roete wat na die ou subnet wys, en elke firewallreël wat die vorige voorvoegsel dra. 'n Reeks wat met die tonnel se afgeleë subnet bots, is die nare variant, want plaaslike toestelle bly bereikbaar terwyl afgeleë bestemmings stilweg in die LAN verkeerd gestuur word.
Verbind weer en toets weer in pakketorde
Nadat een van die twee veranderinge gemaak is, verbind die tonnel weer en herhaal die toetse in pakketorde: roeteerder, plaaslike gasheer, afgeleë gasheer, dan name, dan die toepassing. Om die toepassing eerste te toets, verberg watter laag nog gebreek is, en 'n blaaier se herprobeer teen 'n gekasde naam kan soos 'n roetefout lyk.
Teken die firmwareweergawe, die LAN-voorvoegsel en die toestand van die inspeksiefunksie langs die VPN-profiel aan. Al drie is konfigurasie wat die volgende opdatering kan oorskryf, en twee reëls notas spaar die uur wat jy pas deurgebring het.