Bridgade OpenVPN-klienter har inget internet? Kontrollera NAT-regeln

Den bridgade servern är uppe, masquerade-regeln finns, och webbläsaren på klienten snurrar fortfarande. Allt ser ut som att det borde fungera, och därför går den första timmen åt till att kontrollera tunneln och inloggningsuppgifterna. Sedan läser du räknaren på NAT-regeln och hittar en nolla som inte har flyttat sig. En regel som aldrig har räknat ett enda paket har aldrig matchat ett, och på en bridgad server är orsaken strukturell: klienttrafiken går ut via den virtuella tap-enheten, medan regeln namnger det fysiska kortet du kopierade från en äldre guide.

Räknaren är beviset, inte tabellposten

Regler som finns och regler som matchar är olika saker, och räknaren är det som skiljer dem. Lista NAT-tabellen med detaljerade räknare och läs siffrorna bredvid varje regel innan du ändrar något. En räknare som står på noll medan trafiken flödar betyder att regeln hoppades över, hur förnuftiga adresserna än ser ut. En räknare som klättrar medan anslutningen fortfarande misslyckas skickar dig någon annanstans: till vidarebefordran, returvägen eller den bortre änden.

iptables -t nat -L POSTROUTING -v -n

Läs först räknaren bredvid gränssnittsmatchningen. Om källintervallet är rätt och utsidan är fel, är rättelsen ett ord i regeln i stället för en helt ny regel.

Hitta namnet som kärnan faktiskt registrerar

Identifiera tunnel-enhetens namn innan du skriver regeln, med hjälp av gränssnittslistan och inte minnet. I en bridgad OpenVPN -konfiguration är enheten vanligtvis ett tap-gränssnitt som skapats av servern, och namnet är en del av din lokala konfiguration, inte en universell konstant. Bekräfta att den finns medan tunneln är uppe, eftersom en enhet som först dyker upp efter att en klient ansluter får ett tidigare test att se ut som ett regelproblem.

ip -brief link

Skriv ner namnet. Varje senare kommando i den här diagnostiken hänvisar till det, och ett skrivfel här ger exakt samma nollräknare som det ursprungliga misstaget.

Skriv om regeln mot tunnel-enheten

Rikta regeln mot tunnel-enheten och behåll klientintervallet som dess matchningsvillkor, så att den täcker tunneltrafik och låter värdens egna anslutningar vara i fred. Byt ut mot ditt eget intervall och enhetsnamn, eftersom båda nedan är exempel och inget av dem är portabelt mellan installationer.

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

Kontrollera sedan de två andra villkoren som samma symptom döljer. Kontrollera om vidarebefordran är aktiverad, och om inte, aktivera den i distributionens egen konfiguration i stället för med en echo som försvinner vid omstart. Läs också räknarna i forward-kedjan och, om den släpper tunneltrafiken, tillåt just det gränssnittet och lämna kedjeprincipen orörd.

Att läsa forward-kedjan med räknare tar ett kommando och utesluter hälften av de återstående möjligheterna innan du rör en annan regel.

Varför det fysiska kortet aldrig matchar

En bridge är en mjukvaruswitch som byggs av tap-enheten och ett fysiskt gränssnitt. Klientens ramverk går in i den switchen och ut mot det fysiska nätverket som medlem av bron i stället för som ett paket på kortet. Kärnan tillskriver därför paketet bron och dess port, och därför dyker aldrig kortet du tänkte på upp i matchningen. Ingenting är trasigt på det fysiska gränssnittet; det är helt enkelt inte den enhet som kärnan tillskriver paketet.

Nästa problem som folk stöter på kommer från samma struktur: ramfiltrering på en bro är en separat funktion från IP-filtrering. Om kravet är en begränsning på ramnivå hör den till brofiltreringen, inte till en regel i IP-tabellen.

Bevisa det hela vägen och gör det sedan beständigt

Starta en enda klient och pinga något på serverns LAN; den vägen övar vidarebefordran utan någon översättning. Begär sedan något offentligt så att masquerade-regeln måste användas, och läs räknaren en gång till: den ska röra sig för det här testet och inte för det förra. En fångst tagen på tunnel-enheten visar både var ramverket dyker upp och vilken adress det bär.

Sista steget: lägg reglerna som fungerar i den konfiguration som en omstart läser, och notera enhetsnamnet som den här värdens bro faktiskt använder. Allt som skrivs för hand är borta efter en omstart, och samma fel kommer tillbaka utan något kvar som förklarar det.

Om räknaren fortfarande inte rör sig efter omskrivningen, jämför källintervallet i regeln med adressen klienten faktiskt fick, eftersom en bridgad server kan dela ut adresser från ett intervall du inte hade tänkt på.