Clienții OpenVPN în bridge nu au internet? Verificați regula NAT

Serverul în bridge este pornit, regula masquerade există, iar browserul de pe client se învârte în continuare. Totul pare că ar trebui să funcționeze, de aceea prima oră se duce pe verificarea tunelului și a credențialelor. Apoi citești contorul regulii NAT și găsești un zero care nu s-a mișcat. O regulă care nu a numărat niciodată un pachet nu s-a potrivit niciodată cu unul, iar pe un server în bridge motivul este structural: traficul clientului iese prin dispozitivul tap virtual, în timp ce regula numește placa fizică pe care ai copiat-o dintr-un ghid mai vechi.

Contorul este dovada, nu înregistrarea din tabel

Regulile care există și regulile care se potrivesc sunt lucruri diferite, iar contorul este cel care le desparte. Listează tabelul NAT cu contoare detaliate și citește numerele de lângă fiecare regulă înainte de a schimba ceva. Un contor blocat la zero în timp ce traficul curge înseamnă că regula a fost sărită, oricât de rezonabile ar părea adresele ei. Un contor care urcă în timp ce conexiunea tot eșuează te trimite în altă parte: la forwarding, la calea de întoarcere sau la capătul îndepărtat.

iptables -t nat -L POSTROUTING -v -n

Citește mai întâi contorul de lângă potrivirea interfeței. Dacă intervalul sursă este corect și partea de ieșire este greșită, remedierea este un singur cuvânt în regulă, nu o regulă complet nouă.

Găsește numele pe care kernelul îl înregistrează de fapt

Identifică numele dispozitivului de tunel înainte de a scrie regula, folosind lista de interfețe și nu memoria. Într-o configurație OpenVPN în bridge, dispozitivul este de obicei o interfață tap creată de server, iar numele ei face parte din configurația ta locală, nu dintr-o constantă universală. Confirmă că există în timp ce tunelul este activ, pentru că un dispozitiv care apare abia după ce se conectează un client va face un test anterior să pară o problemă de regulă.

ip -brief link

Notează numele. Fiecare comandă ulterioară din acest diagnostic se referă la el, iar o greșeală de tastare aici produce exact același contor zero ca eroarea inițială.

Rescrie regula pentru dispozitivul de tunel

Îndreaptă regula spre dispozitivul de tunel și păstrează intervalul clienților ca condiție de potrivire, astfel încât să acopere traficul tunelului și să lase în pace conexiunile proprii ale gazdei. Înlocuiește cu intervalul și numele dispozitivului tău, pentru că ambele de mai jos sunt exemple și niciunul nu este portabil între instalări.

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

Apoi verifică celelalte două condiții pe care același simptom le ascunde. Verifică dacă forwardingul este activat, iar dacă nu este, activează-l în configurația distribuției înseși, nu cu un echo care dispare la repornire. Citește și contoarele lanțului forward și, dacă acesta aruncă traficul tunelului, permite explicit acea interfață și lasă politica lanțului neatinsă.

Citirea lanțului forward cu contoare ia o singură comandă și elimină jumătate din posibilitățile rămase înainte de a atinge o altă regulă.

De ce placa fizică nu se potrivește niciodată

Un bridge este un switch software alcătuit din dispozitivul tap și o interfață fizică. Cadrul clientului intră în acel switch și iese spre rețeaua fizică ca membru al bridge-ului, nu ca pachet pe placă. Kernelul atribuie deci pachetul bridge-ului și portului acestuia, motiv pentru care placa la care te gândeai nu apare niciodată în potrivire. Nimic nu este stricat la interfața fizică; pur și simplu nu este dispozitivul căruia kernelul îi atribuie acel pachet.

Problema următoare cu care se confruntă oamenii vine din aceeași structură: filtrarea de cadre pe un bridge este o facilitate separată de filtrarea IP. Dacă cerința este o restricție la nivel de cadru, ea aparține filtrării bridge-ului, nu unei reguli din tabelul IP.

Demonstrează de la un capăt la altul, apoi fă-o permanentă

Pornește un singur client și fă ping către ceva din LAN-ul serverului; acea cale exersează forwardingul fără nicio traducere. După aceea, cere ceva public ca regula masquerade să trebuiască folosită și citește contorul încă o dată: ar trebui să se miște pentru acest test, nu pentru cel anterior. O captură făcută pe dispozitivul de tunel arată atât unde apare cadrul, cât și ce adresă transportă.

Ultimul pas: pune regulile care funcționează în configurația pe care o citește repornirea și notează numele dispozitivului pe care bridge-ul acestei gazde îl folosește efectiv. Tot ce este tastat de mână dispare după o repornire, iar aceeași defecțiune revine fără nimic care să o explice.

Dacă contorul tot nu se mișcă după rescriere, compară intervalul sursă din regulă cu adresa pe care clientul a primit-o efectiv, pentru că un server în bridge poate distribui adrese dintr-un interval pe care nu îl aveai în vedere.