Reitittimen VPN toimii, mutta LAN-asiakkailla ei ole internetyhteyttä

Tila kertoo, että tunneli on pystyssä, reitittimen omassa selaimessa sivut latautuvat ja jokainen sen takana oleva laite saa silti aikakatkaisun. Yhdistelmä rajaa ongelman kerrokseen, jota useimmat VPN-oppaat eivät koskaan mainitse: reititin ei ole ainoa isäntä, jonka pakettien on selvittävä tunnelista. Paikallisesti syntynyt liikenne ja edelleenlähetetty liikenne kulkevat saman laatikon läpi eri reittejä. Testaa asiakkaalta, niin ero lakkaa olemasta teoreettinen.

Lue vika LAN-isännältä

Aloita laitteesta, joka epäonnistuu, sillä reitittimellä tehty diagnostiikka vastaa eri kysymykseen. Varmista, että asiakkaan oletusyhdyskäytävä on tämä reititin, kirjaa sen lähdeosoite ja aliverkko ja katso sitten, mitä reitittimen tunneliliitännästä lähtee.

Jos asiakkaan osoite muunnetaan, etäpuoli näkee tunnelin osoitteen, ja sieltä kaikki näyttää terveeltä, vaikka asiakas edelleen epäonnistuu. Jos sitä ei muunneta, etäpuolen on tunnettava reitti takaisin asiakkaan aliverkkoon, eikä monella yhdyskäytävällä ole sellaista reittiä oletuksena. Kummassakin tapauksessa reitittimen oma menestys on merkityksetön, koska sen paketit syntyivät paikallisesti eivätkä koskaan kulkeneet edelleenlähetyksen polkua.

Paikallinen ja edelleenlähetetty liikenne ovat erilaisia

Linux ja useimmat reitittimien laiteohjelmistot kohtelevat laatikon itse tuottamia paketteja eri tavalla kuin sen läpi kulkevia paketteja. Output-ketju näkee ensimmäiset, forward-ketju näkee toiset, ja reitittimen omaan liikenteeseen sovitettu käytäntö voi jättää edelleenlähetyksen koskemattomaksi.

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'

Tarkista, onko edelleenlähetys ylipäätään käytössä, ja lue sitten forward-ketjua output-ketjun sijaan. Sääntö, joka sallii salatun ulkoyhteyden, ei ole sääntö, joka sallii salauksen purkaneiden pakettien edelleenlähetyksen, ja näiden sekoittaminen tuottaa juuri tämän oireen. Tunnelin pystyssä oleminen todistaa vain ensimmäisen.

Myös paluureitin on oltava olemassa

Lähteen muunnos ratkaisee, tarvitaanko paluureitti. Kun tunneliliitännässä on masquerading, vastaukset palaavat tunnelin osoitteeseen ja reititin kumoaa muunnoksen. Ilman sitä etäyhdyskäytävä tarvitsee nimenomaisen reitin asiakkaan aliverkkoon, ja sen oman käytännön on sallittava tämä suunta.

Kirjaa ennen mitään muutosta, kumpaa kahdesta mallista käyttöönotto käyttää, koska korjaukset osoittavat vastakkaisiin suuntiin. Muunnoksen lisääminen kätkee puuttuvan paluureitin ja rikkoo sovellukset, jotka tarvitsevat alkuperäisen lähdeosoitteen. Paluureitin lisääminen ilman muunnosta epäonnistuu hiljaa, kun etäpalomuuri hylkää tuntemattoman lähteen. Valitse yksi, dokumentoi se ja sovita toinen puoli siihen.

Asiakkaan DNS kuuluu samaan tarkasteluun. Reitittimen resolveri voi vastata, kun taas toiseen palvelimeen osoitettu asiakas ei saa mitään.

Vahvista yksi sallittu ja yksi estetty virta

Testaa korjauksen jälkeen uutta yhteyttä asiakkaalta, älä olemassa olevaa reitittimen istuntoa. Vahvista sitten, että segmentti, jonka ei pitäisi käyttää tunnelia, ei edelleenkään käytä sitä.

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

Tarkista etäpäässä havaittu lähdeosoite, sillä se kertoo, mikä malli todella on käynnissä. Vahvista myös nimikysely eikä vain osoite, sillä resolverin toiminta on erillinen polku saman laatikon läpi.

Pidä säännöt rajattuina niihin asiakasverkkoihin, jotka tunnelia tarvitsevat, ja vastusta kiusausta kytkeä edelleenlähetyksen suodatin pois, jotta yksi testi menisi läpi. Muutos korjaa testin ja poistaa rajan, jonka tunneli oli tarkoitus tarjota. Kirjoita lähdeosoite, muunnospäätös ja paluureitti yhteen muistiinpanoon, päivämäärän kanssa.