Broforbundne OpenVPN-klienter har ingen internet? Kontroller NAT-reglen

Den broforbundne server kører, masquerade-reglen er der, og browseren på klienten snurrer stadig. Alt ser ud, som om det burde virke, og derfor går den første time med at kontrollere tunnelen og legitimationsoplysningerne. Derefter læser du tælleren på NAT-reglen og finder et nul, der ikke har flyttet sig. En regel, der aldrig har talt en pakke, har aldrig matchet nogen, og på en broforbundet server er årsagen strukturel: klienttrafikken forlader systemet gennem den virtuelle tap-enhed, mens reglen angiver det fysiske kort, du kopierede fra en ældre guide.

Tælleren er beviset, ikke tabelrækken

Regler, der findes, og regler, der matcher, er forskellige ting, og tælleren er det, der skiller dem. Vis NAT-tabellen med udførlige tællere, og læs tallene ved hver regel, før du ændrer noget. En tæller, der står på nul, mens trafikken løber, betyder, at reglen blev sprunget over, hvor fornuftige dens adresser end ser ud. En tæller, der stiger, mens forbindelsen stadig fejler, sender dig et andet sted hen: videresendelse, returvejen eller den fjerne ende.

iptables -t nat -L POSTROUTING -v -n

Læs først tælleren ved interface-matchningen. Hvis kildeområdet er rigtigt, og udgangssiden er forkert, er rettelsen et ord i reglen og ikke en helt ny regel.

Find det navn, kernen faktisk registrerer

Identificér tunne-enheden ved navn, før du skriver reglen, og brug interfacelisten i stedet for hukommelsen. På et broforbundet OpenVPN opsætning er enheden normalt et tap-interface oprettet af serveren, og dens navn er en del af din lokale konfiguration, ikke en universel konstant. Bekræft, at den findes, mens tunnelen er oppe, for en enhed, der først dukker op, når en klient forbinder, får en tidligere test til at ligne et regelfejl.

ip -brief link

Skriv navnet ned. Hver senere kommando i denne diagnostik henviser til det, og en tastefejl her giver præcis den samme nultæller som den oprindelige fejl.

Skriv reglen om mod tunne-enheden

Ret reglen mod tunne-enheden, og behold klientområdet som dens matchbetingelse, så den dækker tunneltrafik og lader værtens egne forbindelser være i fred. Indsæt dit eget område og enhedsnavn, for begge eksemplerne nedenfor er eksempler, og ingen af dem kan flyttes mellem installationer.

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

Kontrollér derefter de to andre betingelser, som det samme symptom skjuler. Kontrollér, om videresendelse er aktiveret, og hvis ikke, så aktiver det i distributionens egen konfiguration i stedet for med et echo, der forsvinder ved genstart. Læs også tællerne i forward-kæden, og hvis den dropper tunneltrafikken, så tillad netop det interface og lad kædens politik være urørt.

At læse forward-kæden med tællere tager én kommando og udelukker halvdelen af de resterende muligheder, før du rører en anden regel.

Hvorfor det fysiske kort aldrig matcher

En bro er en softwareswitch sammensat af tap-enheden og et fysisk interface. Klientens frame går ind i den switch og forlader den mod det fysiske netværk som medlem af broen, ikke som en pakke på kortet. Derfor tilskriver kernen pakken broen og dens port, og derfor dukker det kort, du tænkte på, aldrig op i matchningen. Der er intet i vejen med det fysiske interface; det er blot ikke den enhed, kernen tilskriver den pakke.

Det næste problem, folk støder på, kommer fra samme struktur: frame-filtrering på en bro er en separat facilitet fra IP-filtrering. Hvis kravet er begrænsning på frame-niveau, hører det til brofiltrering, ikke til en IP-tabelregel.

Bevis det fra ende til anden, og gør det så permanent

Start en enkelt klient og ping noget på serverens LAN; den vej øver videresendelse uden nogen oversættelse. Bed derefter om noget offentligt, så masquerade-reglen skal bruges, og læs tælleren igen: den bør flytte sig for denne test og ikke for den forrige. En optagelse på tunne-enheden viser både, hvor framen dukker op, og hvilken adresse den bærer.

Sidste trin: sæt de regler, der virker, ind i den konfiguration, en genstart læser, og notér det enhedsnavn, som denne værts bro faktisk bruger. Alt, hvad der er skrevet i hånden, er væk efter en genstart, og den samme fejl vender tilbage uden noget at forklare den med.

Hvis tælleren stadig ikke flytter sig efter omskrivningen, så sammenlign kildeområdet i reglen med den adresse, klienten faktisk fik, for en broforbundet server kan uddele adresser fra et område, du ikke havde tænkt på.