Sillatut OpenVPN-asiakkaat ilman internetiä? Tarkista NAT-sääntö

Sillattu palvelin on käynnissä, masquerade-sääntö on olemassa, ja asiakkaan selain pyörii yhä. Kaikki näyttää siltä kuin sen pitäisi toimia, ja juuri siksi ensimmäinen tunti menee tunnelin ja tunnistetietojen tarkistamiseen. Sitten luet NAT-säännön laskurin ja löydät nollan, joka ei ole liikkunut. Sääntö, joka ei koskaan laskenut yhtään pakettia, ei koskaan osunut mihinkään, ja sillatulla palvelimella syy on rakenteellinen: asiakkaan liikenne poistuu virtuaalisen tap-laitteen kautta, kun taas sääntö nimeää fyysisen kortin, jonka kopioit vanhemmasta oppaasta.

Laskuri on todiste, ei taulukon rivi

Olemassa olevat säännöt ja täsmäävät säännöt ovat eri asioita, ja laskuri erottaa ne. Listaa NAT-taulukko yksityiskohtaisin laskurein ja lue jokaisen säännön vieressä olevat luvut ennen kuin muutat mitään. Nollassa seisova laskuri liikenteen virratessa tarkoittaa, että sääntö ohitettiin, niin järkeviltä sen osoitteet näyttävätkään. Laskuri, joka kasvaa yhteyden yhä epäonnistuessa, lähettää sinut muualle: edelleenlähetys, paluureitti tai kaukainen pää.

iptables -t nat -L POSTROUTING -v -n

Lue ensin rajapinnan osuman vieressä oleva laskuri. Jos lähdealue on oikein ja lähtöpuoli väärin, korjaus on yksi sana säännössä eikä täysin uusi sääntö.

Etsi nimi, jonka ydin todella tallentaa

Tunnista tunnelilaite nimeltä ennen säännön kirjoittamista käyttämällä rajapintaluetteloa muistin sijaan. Sillatussa OpenVPN asennuksessa laite on yleensä palvelimen luoma tap-rajapinta, ja sen nimi on osa paikallista kokoonpanoasi, ei yleinen vakio. Varmista, että se on olemassa tunnelin ollessa käynnissä, sillä laite, joka ilmestyy vasta asiakkaan yhdistettyä, saa aiemman testin näyttämään sääntöongelmalta.

ip -brief link

Kirjoita nimi muistiin. Jokainen myöhempi komento tässä diagnoosissa viittaa siihen, ja kirjoitusvirhe tässä antaa täsmälleen saman nollalaskurin kuin alkuperäinen virhe.

Kirjoita sääntö uudelleen tunnelilaitteelle

Kohdista sääntö tunnelilaitteeseen ja pidä asiakasalue sen osumaehtona, jotta se kattaa tunneliliikenteen ja jättää isännän omat yhteydet rauhaan. Korvaa omalla alueellasi ja laitenimelläsi, sillä molemmat alla olevat esimerkit ovat esimerkkejä eikä kumpikaan siirry asennusten välillä.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

Tarkista sitten kaksi muuta ehtoa, jotka sama oire kätkee. Tarkista, onko edelleenlähetys käytössä, ja jos ei ole, ota se käyttöön jakelun omassa kokoonpanossa sen sijaan, että käyttäisit echota, joka katoaa uudelleenkäynnistyksessä. Lue myös forward-ketjun laskurit, ja jos se pudottaa tunneliliikenteen, salli juuri se rajapinta ja jätä ketjun käytäntö koskemattomaksi.

Forward-ketjun lukeminen laskureineen vie yhden komennon ja sulkee pois puolet jäljellä olevista mahdollisuuksista ennen kuin kosket toiseen sääntöön.

Miksi fyysinen kortti ei koskaan täsmää

Silta on ohjelmistokytkin, joka on koottu tap-laitteesta ja yhdestä fyysisestä rajapinnasta. Asiakkaan kehys tulee tähän kytkimeen ja poistuu fyysiseen verkkoon sillan jäsenenä eikä kortilla olevana pakettina. Siksi ydin kohdistaa paketin sillalle ja sen portille, ja juuri siksi kortti, jota ajattelit, ei koskaan näy osumassa. Fyysisessä rajapinnassa ei ole mitään rikki; se ei vain ole laite, jolle ydin tämän paketin kohdistaa.

Seuraava ongelma, johon ihmiset törmäävät, tulee samasta rakenteesta: kehysten suodatus sillalla on erillinen mekanismi IP-suodatuksesta. Jos vaatimuksena on kehystason rajoitus, se kuuluu sillan suodatukseen, ei IP-taulukon sääntöön.

Todista se päästä päähän ja tee siitä sitten pysyvä

Nosta yksi asiakas ja pingaa jotain palvelimen lähiverkossa; tämä polku harjoittaa edelleenlähetystä ilman mitään käännöstä. Pyydä sen jälkeen jotain julkista, jotta masquerade-sääntöä on pakko käyttää, ja lue laskuri vielä kerran: sen pitäisi liikkua tätä testiä varten eikä edellistä. Tunnelilaitteella otettu kaappaus näyttää sekä sen, missä kehys näkyy, että sen, mitä osoitetta se kantaa.

Viimeinen vaihe: laita toimivat säännöt kokoonpanoon, jonka uudelleenkäynnistys lukee, ja kirjoita muistiin laitenimi, jota tämän isännän silta todella käyttää. Kaikki käsin kirjoitettu katoaa uudelleenkäynnistyksen jälkeen, ja sama vika palaa ilman mitään selitystä.

Jos laskuri ei vieläkään liiku uudelleenkirjoituksen jälkeen, vertaa säännön lähdealuetta osoitteeseen, jonka asiakas todella sai, sillä sillattu palvelin voi jakaa osoitteita alueelta, jota et tarkoittanut.