Router-VPN werk, maar LAN-kliënte het geen internet

Die status sê die tonnel is op, 'n blaaier op die router self laai bladsye, en elke toestel agter dit wys steeds 'n tydverstreke fout. Daardie kombinasie vernou die probleem tot 'n laag wat die meeste VPN-gidse nooit noem nie: die router is nie die enigste gasheer wie se pakkette deur die tonnel moet oorleef nie. Plaaslik gegenereerde verkeer en deurgevoerde verkeer volg verskillende paaie deur dieselfde boks. Toets vanaf 'n kliënt en die verskil hou op om teoreties te wees.

Lees die fout vanaf 'n LAN-gasheer

Begin by die toestel wat misluk, want 'n diagnostiese lopie op die router beantwoord 'n ander vraag. Bevestig dat die kliënt se verstekpoort hierdie router is, let op sy bronadres en subnet, en kyk dan wat die router se tonnelkoppelvlak verlaat.

As die kliënt se adres vertaal word, sien die afgeleë kant die tonneladres, en alles lyk gesond van daar af terwyl die kliënt steeds misluk. As dit nie vertaal word nie, moet die afgeleë kant 'n roete terug na die kliënt-subnet ken, en baie poorte het nie so 'n roete by verstek nie. In beide gevalle is die router se eie sukses irrelevant, want sy pakkette is plaaslik gegenereer en het nooit die deurvoerpad betree nie.

Plaaslike verkeer en deurgevoerde verkeer is verskillend

Linux en die meeste router-firmware behandel pakkette wat deur die boks self ontstaan anders as pakkette wat daardeur beweeg. Die output-ketting sien die eerste soort, die forward-ketting sien die tweede, en 'n beleid wat vir die router se eie verkeer ingestel is, kan deurvoer onaangeraak laat.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Kontroleer of deurvoer hoegenaamd geaktiveer is, en lees dan die forward-ketting eerder as die output-ketting. 'n Reël wat die geënkripteerde buitenste verbinding toelaat, is nie 'n reël wat toelaat dat gedekripteerde pakkette deurgevoer word nie, en om die twee te verwar lewer presies hierdie simptoom. Die tonnel wat op is, bewys slegs die eerste.

Die terugpad moet ook bestaan

Bronvertaling bepaal of 'n terugpad nodig is. Met masquerading op die tonnelkoppelvlak kom antwoorde terug na die tonneladres en die router onttaal dit. Sonder dit het die afgeleë poort 'n eksplisiete roete na die kliënt-subnet nodig, en sy eie beleid moet daardie rigting toelaat.

Teken aan watter van die twee ontwerpe die ontplooiing gebruik voordat jy iets verander, want die herstellings wys in teenoorgestelde rigtings. Om vertaling by te voeg verberg 'n ontbrekende terugroete en breek toepassings wat die oorspronklike bronadres nodig het. Om 'n terugroete sonder vertaling by te voeg, misluk stil wanneer die afgeleë vuurmuur die onbekende bron laat val. Kies een, dokumenteer dit, en maak die ander kant ooreenstem.

Kliënt-DNS hoort by dieselfde oorsig. Die router se resolver kan antwoord terwyl 'n kliënt wat na 'n ander bediener wys, glad niks kry nie.

Verifieer een toegelate vloei en een geweierde vloei

Na die regstelling, toets 'n nuwe verbinding vanaf 'n kliënt eerder as 'n bestaande router-sessie. Bevestig dan dat 'n segment wat nie die tonnel moet gebruik nie, dit steeds nie doen nie.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Kontroleer die waargenome bronadres aan die verre kant, want dit vertel jou watter ontwerp werklik loop. Verifieer 'n naamsoektog sowel as 'n adres, want resolver-gedrag is 'n afsonderlike pad deur dieselfde boks.

Hou reëls beperk tot die kliëntnetwerke wat die tonnel nodig het, en weerstaan die versoeking om die deurvoerfilter te deaktiveer om een toets te laat slaag. Daardie verandering herstel die toets en verwyder die grens wat die tonnel moes bied. Skryf die bronadres, die vertaalbesluit en die terugroete in een nota, met 'n datum.