OpenVPN:n LAN-käyttö rikki? Tarkista vyöhykkeet, reitit ja paluureitti

Tunneli ilmoittaa onnistuneesta yhteydestä, reitittimen oma sivu latautuu, ja sen takana olevaan koneeseen tehty levyasemayhteys vanhenee silti. Mikään tuossa yhdistelmässä ei ole ristiriitaista: reititin vastaa omana itsenään, ja jonkin sen takana olevan saavuttaminen on toinen päätös, joka tehdään toisessa paikassa. Käy alla olevat tarkistukset järjestyksessä ja pysähdy ensimmäiseen epäonnistumiseen, sillä jokainen nojaa edelliseen. Kun kaikki neljä menevät läpi, vika on tunnelin yläpuolella eikä sen sisällä.

Mikä suodatin näkee LAN-verkkoon menevän paketin

Reitittimelle osoitettu paketti kulutetaan paikallisesti; sen takana olevalle isännälle osoitettu paketti on välitettävä, ja palomuurit arvioivat nämä kaksi tapausta erikseen. Lupa päästä reitittimelle ei siis kerro mitään luvasta kulkea sen läpi. Laiteohjelmisto, joka piilottaa sääntöjoukkonsa, toteuttaa silti molemmat, yleensä valitsimena, joka tarjoaa LAN-verkon, internetin tai molemmat. Jos valitsin jättää LAN-verkon pois, mikään myöhempi tarkistus ei auta.

OpenWrt tekee jaosta tarkasteltavan, ja ero kannattaa lukea kerran. Tunnelin päättävä vyöhyke tarvitsee LAN-vyöhykkeeseen osoittavan välityssäännön, kun taas syötesääntö hallitsee vain reitittimellä itsellään ajettavia palveluja. Toimiva hallintasivu kuolleen LAN-verkon vieressä on tuon puuttuvan välityssäännön tavallinen seuraus.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Katso tunnelia kantavan vyöhykkeen välityskohdetta: accept on se, mitä tikapuu tarvitsee, ja reject selittää jokaisen alla olevan aikakatkaisun. Kaksi vierekkäistä asetusta tuottaa saman oireen, joten sulje ne pois täällä ollessasi. Langaton eristys piilottaa langalliset isännät langattomilta asiakkailta, ja reititin, joka pitää joutilaita LAN-isäntiä offline-tilassa, voi pudottaa vastaukset vielä senkin jälkeen, kun välitys toimii.

Miksi jaettu tunneli tarvitsee työnnetyn etuliitteen

Asiakas, joka lähettää kaiken liikenteen tunnelin kautta, pitää LAN-etuliitteen jo oletusreittinsä kautta, joten lisättävää ei ole. Jaettu tunneli on tapaus, joka vaatii etuliitteen nimenomaista mainintaa, koska mikään muu kokoonpanossa ei mainitse sitä. Lisää direktiivi palvelimen kokoonpanoon ja lataa palvelu uudelleen.

push "route 192.168.50.0 255.255.255.0"

Profiilit, jotka sisältävät route-nopull jättävät työnnetyt reitit huomiotta, joten sama etuliite kuuluu asiakastiedostoon. Varmista joka tapauksessa, että merkintä saapui, sen sijaan että olettaisit niin, sillä hiljainen ohitus näyttää täsmälleen palomuuriongelmalta.

ip route show | grep 192.168.50

Sivusto-sivusto-kumppani vaatii enemmän kuin työnnön. Palvelimen on opittava, mitkä etuliitteet ovat kyseisen kumppanin takana, minkä tekee rivi iroute sen client-config-dir-tiedostossa, ja sen oma taulu tarvitsee vastaavan reitin tunneliin.

Vastaus tarvitsee osoitteen, johon se pääsee

Pyynnön välittäminen on vain puolet vaihdosta, koska LAN-isännän on vastattava tunnelialtaan osoitteeseen. Pienet reitittimet hoitavat sen yleensä kääntämällä lähteen tunnelivyöhykkeellä, jolloin vastaus osoitetaan reitittimelle eikä vaadi kokoonpanoa muualla. Poista käännös, ja isäntä tarvitsee oman reittinsä altaaseen, jonka se saa ilmaiseksi, kun reititin on sen oletusyhdyskäytävä. Isäntä, jolla on käsin asetettu osoite ja eri yhdyskäytävä, vastaa sen yhdyskäytävän kautta, ja asiakas näkee istunnon avautuvan ja sitten jumittuvan.

tcpdump -ni tun0 host 192.168.50.20

Aja tämä reitittimellä, kun asiakas toistaa pyyntöään, ja lue vastauksen kohdeosoite pyynnön sijaan. Altaaseen osoitettu vastaus tarkoittaa, että paluureitti toimii ja vika on syvemmällä. Täysi vastauksen puute tarkoittaa, että isäntä ei koskaan hyväksynyt pakettia, mikä palauttaa sinut sääntöjoukkoon.

Tikapuu, joka päättyy oikeaan paikkaan

Neljä tarkistusta paikantaa kerroksen, ja jokainen on yksi komento eikä arvio. Aja ne järjestyksessä ja pysähdy ensimmäiseen epäonnistumiseen. Järjestys on tärkeämpi kuin komennot, sillä myöhemmin läpäisty vaihe kätkee syyn siihen, miksi aiempi epäonnistui.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Nimet kuuluvat tikapuun loppuun, eivät koskaan alkuun. Jako, joka vastaa osoitteena 192.168.50.20 mutta ei osoitteena nas.local, viittaa nimien selvitykseen tai hakuliitteeseen, eivätkä palomuurin muutokset voi muuttaa kumpaakaan.

Kirjaa ensimmäinen epäonnistunut vaihe ja anna sitten palveluporteille oma kierroksensa, koska kuuntelija ja isännän lupa ovat erillisiä vaatimuksia. Tiedostojen jakaminen, etätyöpöytä ja kameravirrat tarvitsevat molemmat, ja isännän palomuuri, joka luottaa LAN-aliverkkoon mutta ei tunnelialtaaseen, pudottaa asiakkaan pingin vielä onnistuessa. Kun kaikki tarkistukset menevät läpi ja sovellus epäonnistuu silti, vika on tunnelin yläpuolella: yhteen liitäntään sidottu palvelu tai asiakkaalle määritetty välityspalvelin.