Brokoblede OpenVPN-klienter har ikke internett? Sjekk NAT-regelen

Den brokoblede serveren er oppe, masquerade-regelen finnes, og nettleseren på klienten spinner fortsatt. Alt ser ut som det skal virke, og derfor går den første timen med til å sjekke tunnelen og påloggingsdetaljene. Så leser du telleren på NAT-regelen og finner en null som ikke har flyttet seg. En regel som aldri har telt en eneste pakke, har aldri truffet en, og på en brokoblet server er årsaken strukturell: klienttrafikken går ut gjennom den virtuelle tap-enheten, mens regelen navngir det fysiske kortet du kopierte fra en eldre veiledning.

Telleren er beviset, ikke tabelloppføringen

Regler som finnes og regler som treffer er forskjellige ting, og telleren er det som skiller dem. List opp NAT-tabellen med detaljerte tellere og les tallene ved siden av hver regel før du endrer noe. En teller som står på null mens trafikken flyter betyr at regelen ble hoppet over, uansett hvor fornuftige adressene ser ut. En teller som klatrer mens tilkoblingen fortsatt feiler, sender deg et annet sted: videresending, returveien eller den andre enden.

iptables -t nat -L POSTROUTING -v -n

Les telleren ved siden av grensesnittstreffet først. Hvis kildeområdet er riktig og utgangssiden er feil, er rettelsen ett ord i regelen i stedet for en helt ny regel.

Finn navnet kjernen faktisk registrerer

Identifiser tunnel-enheten ved navn før du skriver regelen, ved hjelp av grensesnittlisten og ikke hukommelsen. På et brokoblet OpenVPN oppsett er enheten vanligvis et tap-grensesnitt opprettet av serveren, og navnet er en del av din lokale konfigurasjon, ikke en universell konstant. Bekreft at den finnes mens tunnelen er oppe, fordi en enhet som først dukker opp etter at en klient kobler til, vil få en tidligere test til å se ut som et regelproblem.

ip -brief link

Skriv ned navnet. Hver senere kommando i denne diagnosen viser til det, og en skrivefeil her gir nøyaktig samme nullteller som den opprinnelige feilen.

Skriv regelen på nytt mot tunnel-enheten

Pek regelen mot tunnel-enheten og behold klientområdet som treffbetingelse, slik at den dekker tunneltrafikk og lar vertens egne tilkoblinger være i fred. Bytt ut med ditt eget område og enhetsnavn, fordi begge nedenfor er eksempler og ingen av dem kan flyttes mellom installasjoner.

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

Sjekk deretter de to andre betingelsene som samme symptom skjuler. Sjekk om videresending er slått på, og hvis ikke, slå den på i distribusjonens egen konfigurasjon i stedet for med en echo som forsvinner ved omstart. Les også tellerne i forward-kjeden, og hvis den slipper tunneltrafikken, gi den aktuelle grensesnittet eksplisitt tillatelse og la kjedepolicyen være.

Å lese forward-kjeden med tellere tar én kommando og utelukker halvparten av de gjenværende mulighetene før du rører en annen regel.

Hvorfor det fysiske kortet aldri treffer

En bro er en programvarebryter satt sammen av tap-enheten og ett fysisk grensesnitt. Klientrammen går inn i den bryteren og ut mot det fysiske nettverket som medlem av broen i stedet for som en pakke på kortet. Kjernen tilordner derfor pakken til broen og porten dens, og derfor dukker aldri kortet du tenkte på opp i treffet. Ingenting er i stykker på det fysiske grensesnittet; det er rett og slett ikke enheten kjernen tilordner pakken til.

Oppfølgingsproblemet folk møter neste gang kommer fra samme struktur: rammefiltrering på en bro er en egen ordning fra IP-filtrering. Hvis kravet er begrensning på rammenivå, hører det til brofiltreringen, ikke til en IP-tabellregel.

Bevis det ende til ende, og gjør det deretter varig

Start én klient og ping noe på serverens LAN; den veien prøver videresending uten noen oversettelse. Be deretter om noe offentlig slik at masquerade-regelen må brukes, og les telleren en gang til: den skal bevege seg for denne testen og ikke for den forrige. En fangst tatt på tunnel-enheten viser både hvor rammen dukker opp og hvilken adresse den bærer.

Siste steg: legg reglene som virker inn i konfigurasjonen en omstart leser, og noter enhetsnavnet denne vertens bro faktisk bruker. Alt som er skrevet for hånd er borte etter en omstart, og samme feil kommer tilbake uten noe igjen som forklarer den.

Hvis telleren fortsatt ikke flytter seg etter omskrivingen, sammenlign kildeområdet i regelen med adressen klienten faktisk fikk, fordi en brokoblet server kan dele ut adresser fra et område du ikke hadde tenkt på.