Router-VPN wurket, mar LAN-klanten hawwe gjin ynternet

De status seit dat de tunnel oan is, in browser op 'e router sels laden siden, en elk apparaat derachter rint noch altyd op in time-out. Dy kombinaasje ferhellet it probleem nei in laach dy't de measte VPN-gidsen nea neame: de router is net de iennige host waans pakketten de tunnel oerlibje moatte. Lokaal generearre ferkear en trochstjoerd ferkear nimme ferskate paden troch deselde doaze. Test fan in klant en it ferskil hâldt op teoretysk te wêzen.

Lês de flater fan in LAN-host

Begjin by it apparaat dat mislearret, want in diagnoaze op 'e router beantwurdet in oare fraach. Befêstigje dat de standertgateway fan 'e klant dizze router is, notearje syn boarneadres en subnet, en sjoch dan wat de tunnelinterface fan 'e router ferlit.

As it adres fan 'e klant oerset wurdt, sjocht de fiere kant it tunneladres, en fan dêrwei liket alles sûn wylst de klant noch mislearret. As it net oerset wurdt, moat de fiere kant in rûte werom nei it subnet fan 'e klant kenne, en in protte gateways hawwe sa'n rûte standert net. Yn beide gefallen is it eigen sukses fan 'e router net relevant, want syn pakketten binne lokaal generearre en hawwe nea it trochstjoerpaad trochkrúst.

Lokaal ferkear en trochstjoerd ferkear binne ferskillend

Linux en de measte router-firmware behannelje pakketten dy't troch de doaze sels ûntsteane oars as pakketten dy't der trochhinne geane. De output-keten sjocht it earste soart, de forward-keten sjocht it twadde, en in belied dat op it eigen ferkear fan 'e router rjochte is, kin it trochstjoeren ûnoantaast litte.

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'

Kontrolearje oft trochstjoeren hielendal oan is, en lês dan de forward-keten yn stee fan 'e output-keten. In regel dy't de fersifere bûtenferbining tastiet, is net in regel dy't tastiet dat ûntsifere pakketten trochstjoerd wurde, en it ferwikseljen fan dy twa produsearret krekt dit symptoom. Dat de tunnel oan is, bewiist allinnich it earste.

It werompaad moat ek bestean

Boarne-oersetting beslút oft in werompaad nedich is. Mei masquerading op 'e tunnelinterface komme antwurden werom nei it tunneladres en makket de router de oersetting ûngedien. Sûnder dat hat de fiere gateway in eksplisite rûte nei it subnet fan 'e klant nedich, en syn eigen belied moat dy rjochting tastiede.

Notearje hokker fan 'e twa ûntwerpen de ymplemintaasje brûkt foardat jo wat feroarje, want de reparaasjes wize yn tsjinoerstelde rjochtingen. It tafoegjen fan oersetting ferberget in ûntbrekkende weromrûte en brekt applikaasjes dy't it oarspronklike boarneadres nedich hawwe. It tafoegjen fan in weromrûte sûnder oersetting mislearret stil as de fiere firewall de ûnbekende boarne weilûkt. Kies ien, dokumintearje it, en meitsje de oare kant lyk.

Klant-DNS heart by deselde resinsje. De resolver fan 'e router kin antwurdzje wylst in klant dy't nei in oare server wiist hielendal neat krijt.

Ferifiearje ien tastiene en ien wegere stream

Test nei de korreksje in nije ferbining fan in klant yn stee fan in besteande routersesje. Befêstigje dan dat in segmint dat de tunnel net brûke moat, dat noch altyd net docht.

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

Kontrolearje it waarnommen boarneadres oan 'e fiere kant, want dat fertelt jo hokker ûntwerp eins rint. Ferifiearje ek in nammesyking njonken in adres, want it gedrach fan 'e resolver is in apart paad troch deselde doaze.

Hâld regels beheind ta de klantnetwurken dy't de tunnel nedich hawwe, en wjerstean de ferlieding om it trochstjoerfilter út te setten om ien test te slagjen. Dy feroaring reparearret de test en ferwideret de grins dy't de tunnel biede moast. Skriuw it boarneadres, it oersettingsbeslút en de weromrûte yn ien notysje, mei in datum.