Brua OpenVPN-klientar har ikkje internett? Sjekk NAT-regelen

Den brua serveren er oppe, masquerade-regelen finst, og nettlesaren på klienten snurrar framleis. Alt ser ut som det skal verke, og difor går den første timen med til å sjekke tunnelen og påloggingsdetaljane. Så les du teljaren på NAT-regelen og finn ein null som ikkje har flytta seg. Ein regel som aldri har talt ei einaste pakke, har aldri treft ei, og på ein brua server er årsaka strukturell: klienttrafikken går ut gjennom den virtuelle tap-eininga, medan regelen nemner det fysiske kortet du kopierte frå ei eldre rettleiing.

Teljaren er provet, ikkje tabelloppføringa

Reglar som finst og reglar som treff er ulike ting, og teljaren er det som skil dei. List opp NAT-tabellen med detaljerte teljarar og les tala ved sida av kvar regel før du endrar noko. Ein teljar som står på null medan trafikken flyt, tyder at regelen vart hoppa over, uansett kor fornuftige adressene ser ut. Ein teljar som klatrar medan tilkoplinga framleis feilar, sender deg ein annan stad: videresending, returvegen eller den andre enden.

iptables -t nat -L POSTROUTING -v -n

Les teljaren ved sida av grensesnitttreffet først. Viss kjeldeområdet er rett og utgangssida er feil, er rettinga eitt ord i regelen i staden for ein heilt ny regel.

Finn namnet kjernen faktisk registrerer

Identifiser tunnel-eininga ved namn før du skriv regelen, ved hjelp av grensesnittlista og ikkje minnet. På eit brua OpenVPN oppsett er eininga vanlegvis eit tap-grensesnitt laga av serveren, og namnet er ein del av den lokale konfigurasjonen din, ikkje ein universell konstant. Stadfest at ho finst medan tunnelen er oppe, fordi ei eining som først dukkar opp etter at ein klient koplar til, vil få ein tidlegare test til å sjå ut som eit regelproblem.

ip -brief link

Skriv ned namnet. Kvar seinare kommando i denne diagnosen viser til det, og ein skrivefeil her gir nøyaktig same nullteljar som den opphavlege feilen.

Skriv regelen på nytt mot tunnel-eininga

Pek regelen mot tunnel-eininga og hald klientområdet som treffvilkår, slik at han dekkjer tunneltrafikk og lèt dei eigne tilkoplingane til verten vere i fred. Bytt ut med ditt eige område og einingnamn, fordi båe nedanfor er døme og ingen av dei kan flyttast mellom installasjonar.

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

Sjekk deretter dei to andre vilkåra som same symptomet skjuler. Sjekk om videresending er slått på, og viss ikkje, slå det på i konfigurasjonen til distribusjonen sjølv og ikkje med ein echo som forsvinn ved omstart. Les òg teljarane i forward-kjeda, og viss ho slepp tunneltrafikken, gje det aktuelle grensesnittet eksplisitt løyve og la kjedepolitikken vere.

Å lese forward-kjeda med teljarar tek éin kommando og utelukkar halvparten av dei gjenverande moglegheitene før du rører ein annan regel.

Kvifor det fysiske kortet aldri treff

Ei bru er ein programvarebrytar sett saman av tap-eininga og eitt fysisk grensesnitt. Klientramma går inn i den brytaren og ut mot det fysiske nettverket som medlem av brua i staden for som ei pakke på kortet. Kjernen tildeler difor pakka til brua og porten hennar, og difor dukkar aldri kortet du tenkte på opp i treffet. Ingenting er i stykke på det fysiske grensesnittet; det er rett og slett ikkje eininga kjernen tildeler pakka til.

Oppfølgingsproblemet folk møter neste gong kjem frå same struktur: rammefiltrering på ei bru er ei eiga ordning frå IP-filtrering. Viss kravet er avgrensing på rammenivå, høyrer det til brufiltrering, ikkje til ein regel i IP-tabellen.

Prov det ende til ende, og gjer det deretter varig

Start éin klient og ping noko på LAN-et til serveren; den vegen prøver videresending utan noka omsetjing. Be deretter om noko offentleg slik at masquerade-regelen må brukast, og les teljaren ein gong til: han skal flytte seg for denne testen og ikkje for den førre. Ein fangst teken på tunnel-eininga viser både kvar ramma dukkar opp og kva adresse ho ber.

Siste steg: legg reglane som verkar inn i konfigurasjonen ein omstart les, og noter einingnamnet brua til denne verten faktisk brukar. Alt som er skrive for hand er borte etter ein omstart, og same feilen kjem tilbake utan noko att som forklarer han.

Viss teljaren framleis ikkje flyttar seg etter omskrivinga, samanlikn kjeldeområdet i regelen med adressa klienten faktisk fekk, fordi ein brua server kan dele ut adresser frå eit område du ikkje hadde tenkt på.