Sillatud OpenVPN-kliendid ei saa internetti? Kontrollige NAT-reeglit

Sillatud server töötab, masquerade-reegel on olemas ja kliendi brauser keerleb endiselt. Kõik näeb välja nii, nagu peaks töötama, ja just seetõttu kulub esimene tund tunnelile ja volitustele. Siis loete NAT-reegli loenduri ja leiate nulli, mis ei ole liikunud. Reegel, mis ei ole kunagi ühtegi paketti lugenud, ei ole kunagi ühegagi kokku langenud, ja sillatud serveril on põhjus struktuurne: kliendi liiklus väljub virtuaalse tap-seadme kaudu, samal ajal kui reegel nimetab füüsilist kaarti, mille kopeerisite vanemast juhendist.

Tõend on loendur, mitte tabelirida

Reeglid, mis on olemas, ja reeglid, mis sobivad, on erinevad asjad, ja loendur eraldab neid. Loetlege NAT-tabel üksikasjalike loenduritega ja lugege iga reegli kõrval olevaid numbreid enne, kui midagi muudate. Nulli juures seisev loendur liikluse voolamise ajal tähendab, et reegel jäeti vahele, ükskõik kui mõistlikud selle aadressid ka välja näevad. Loendur, mis kasvab, kui ühendus ikka veel ebaõnnestub, suunab teid mujale: edasisaatmine, tagasitee või kaugem ots.

iptables -t nat -L POSTROUTING -v -n

Lugege esmalt liidese sobivuse kõrval olevat loendurit. Kui lähtevahemik on õige ja väljundpool vale, on parandus reeglis üks sõna, mitte täiesti uus reegel.

Leidke nimi, mille kernel tegelikult salvestab

Tehke tunneliseade kindlaks nime järgi enne reegli kirjutamist, kasutades liideste loendit, mitte mälu. Sillatud OpenVPN seadistuses on seadmeks tavaliselt serveri loodud tap-liides ja selle nimi on osa teie kohalikust konfiguratsioonist, mitte universaalne konstant. Kinnitage, et see on olemas tunneli töötamise ajal, sest seade, mis ilmub alles pärast kliendi ühendumist, paneb varasema testi näima reegli probleemina.

ip -brief link

Kirjutage nimi üles. Iga järgnev käsk selles diagnoosis viitab sellele ja trükiviga siin annab täpselt sama null-loenduri kui algne viga.

Kirjutage reegel tunneliseadme jaoks ümber

Suunake reegel tunneliseadmele ja jätke kliendi vahemik selle sobivustingimuseks, nii et see katab tunneli liiklust ja jätab hosti enda ühendused puutumata. Asendage oma vahemiku ja seadme nimega, sest mõlemad allolevad näited on näited ja kumbki ei ole installatsioonide vahel ülekantav.

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

Seejärel kontrollige kahte teist tingimust, mida sama sümptom varjab. Kontrollige, kas edasisaatmine on lubatud, ja kui ei ole, lubage see distributsiooni enda konfiguratsioonis, mitte echoga, mis taaskäivitusel kaob. Lugege ka forward-ahela loendureid ja kui see tunneliliikluse maha viskab, lubage just see liides ja jätke ahela poliitika puutumata.

Forward-ahela lugemine loenduritega võtab ühe käsu ja välistab poole ülejäänud võimalustest, enne kui puudutate veel üht reeglit.

Miks füüsiline kaart kunagi ei sobi

Sild on tarkvaraline kommutaator, mis on kokku pandud tap-seadmest ja ühest füüsilisest liidesest. Kliendi kaader siseneb sellesse kommutaatorisse ja väljub füüsilise võrgu poole silla liikmena, mitte kaardil oleva paketina. Seetõttu omistab kernel paketi sillale ja selle pordile, ja just seetõttu ei ilmugi kaart, millele te mõtlesite, sobivuses kunagi. Füüsilises liideses ei ole midagi katki; see lihtsalt ei ole seade, millele kernel selle paketi omistab.

Järgmine probleem, millega inimesed kokku puutuvad, tuleb samast struktuurist: kaadrite filtreerimine sillal on IP-filtreerimisest eraldi mehhanism. Kui nõue on kaadritasandi piirang, kuulub see silla filtreerimise juurde, mitte IP-tabeli reegli juurde.

Tõestage seda algusest lõpuni ja tehke see siis püsivaks

Tõstke üks klient üles ja pingige midagi serveri kohtvõrgus; see tee harjutab edasisaatmist ilma igasuguse tõlketa. Seejärel küsige midagi avalikku, et masquerade-reeglit tuleks kasutada, ja lugege loendurit veel kord: see peaks selle testi jaoks liikuma, mitte eelmise jaoks. Tunneliseadmel tehtud püüdmine näitab nii seda, kus kaader ilmub, kui ka seda, millist aadressi see kannab.

Viimane samm: pange töötavad reeglid konfiguratsiooni, mida taaskäivitus loeb, ja kirjutage üles seadme nimi, mida selle hosti sild tegelikult kasutab. Kõik käsitsi trükitu on pärast taaskäivitust kadunud ja sama rike tuleb tagasi ilma millegi seletuseta.

Kui loendur pärast ümberkirjutamist ikka ei liigu, võrrelge reeglis olevat lähtevahemikku aadressiga, mille klient tegelikult sai, sest sillatud server võib jagada aadresse vahemikust, mida te ei kavatsenud.