Gebrugde OpenVPN-kliënte het geen internet? Kontroleer die NAT-reël

Die gebrugde bediener is op, die masquerade-reël is daar, en die blaaier op die kliënt draai steeds. Alles lyk of dit behoort te werk, en juis daarom gaan die eerste uur in die ondersoek van die tonnel en die geloofsbriewe in. Dan lees jy die teller op die NAT-reël en sien 'n nul wat nie beweeg het nie. 'n Reël wat nooit 'n pakkie getel het nie, het nooit een gepas nie, en op 'n gebrugde bediener is die rede struktureel: kliëntverkeer verlaat die stelsel deur die virtuele tap-toestel, terwyl die reël die fisiese kaart noem wat jy uit 'n ouer gids gekopieer het.

Die teller is die bewys, nie die tabelinskrywing nie

Reëls wat bestaan en reëls wat pas, is verskillende dinge, en die teller skei hulle. Lys die NAT-tabel met uitgebreide tellers en lees die getalle langs elke reël voordat jy iets verander. 'n Teller wat op nul staan terwyl verkeer vloei, beteken die reël is oorgeslaan, hoe sinvol sy adresse ook al lyk. 'n Teller wat klim terwyl die verbinding steeds misluk, stuur jou elders heen: aanstuur, die terugpad, of die ander kant.

iptables -t nat -L POSTROUTING -v -n

Lees eerste die teller langs die koppelvlak-pas. As die bronreeks reg is en die uitgangskant verkeerd is, is die regstelling een woord in die reël eerder as 'n heeltemal nuwe reël.

Vind die naam wat die kern werklik aanteken

Identifiseer die tonneltoestel by naam voordat jy die reël skryf, met die koppelvlaklys eerder as jou geheue. Op 'n gebrugde OpenVPN opstelling is die toestel gewoonlik 'n tap-koppelvlak wat deur die bediener geskep is, en sy naam is deel van jou plaaslike konfigurasie, nie 'n universele konstante nie. Bevestig dat dit bestaan terwyl die tonnel op is, want 'n toestel wat eers verskyn nadat 'n kliënt verbind, sal 'n vroeëre toets soos 'n reëlprobleem laat lyk.

ip -brief link

Skryf die naam neer. Elke latere opdrag in hierdie diagnose verwys daarna, en 'n tikfout hier lewer presies dieselfde nulteller as die oorspronklike fout.

Herskryf die reël teen die tonneltoestel

Rig die reël op die tonneltoestel en hou die kliëntreeks as sy pasvoorwaarde, sodat dit tonnelverkeer dek en die eie verbindings van die gasheer met rus laat. Vervang jou eie reeks en toestelnaam, want albei hier onder is voorbeelde en nie een is oordraagbaar tussen installasies nie.

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

Kontroleer dan die twee ander toestande wat dieselfde simptoom verberg. Kyk of aanstuur geaktiveer is, en indien nie, aktiveer dit in die verspreiding se eie konfigurasie eerder as met 'n echo wat by herbegin verdwyn. Lees ook die tellers van die forward-ketting, en as dit die tonnelverkeer laat val, laat daardie koppelvlak spesifiek toe en los die kettingbeleid alleen.

Om die forward-ketting met tellers te lees neem een opdrag en sluit die helfte van die oorblywende moontlikhede uit voordat jy aan nog 'n reël raak.

Waarom die fisiese kaart nooit pas nie

'n Brug is 'n sagteware-skakelaar wat uit die tap-toestel en een fisiese koppelvlak saamgestel is. Die kliëntraam gaan daardie skakelaar binne en verlaat dit na die fisiese netwerk as 'n lid van die brug, nie as 'n pakkie op die kaart nie. Die kern skryf die pakkie dus aan die brug en sy poort toe, en daarom verskyn die kaart waaraan jy gedink het nooit in die pas nie. Niks is verkeerd met die fisiese koppelvlak nie; dit is bloot nie die toestel wat die kern aan daardie pakkie toeskryf nie.

Die opvolgprobleem wat mense volgende tref, kom uit dieselfde struktuur: raamfiltering op 'n brug is 'n aparte fasiliteit van IP-filtering. As die vereiste raamvlakbeperking is, hoort dit by brugfiltering, nie by 'n IP-tabelreël nie.

Bewys dit van begin tot end, en maak dit dan blywend

Bring 'n enkele kliënt op en ping iets op die bediener se LAN; daardie pad oefen aanstuur sonder enige vertaling. Vra daarna iets openbaar aan sodat die masquerade-reël gebruik moet word, en lees die teller weer: dit behoort vir hierdie toets te beweeg en nie vir die vorige een nie. 'n Opname wat op die tonneltoestel geneem is, wys beide waar die raam verskyn en watter adres dit dra.

Laaste stap: plaas die reëls wat werk in die konfigurasie wat 'n herbegin lees, en let op die toestelnaam wat hierdie gasheer se brug werklik gebruik. Enigiets wat met die hand getik is, is ná 'n herbegin weg, en dieselfde fout kom terug met niks oor om dit te verduidelik nie.

As die teller ná die herskrywing steeds nie beweeg nie, vergelyk die bronreeks in die reël met die adres wat die kliënt werklik ontvang het, want 'n gebrugde bediener kan adresse uit 'n reeks uitdeel wat jy nie bedoel het nie.