LAN-klientar ignorerer VPN-en til ruteren til policy-ruting vert teke i bruk

Ruteren når internett gjennom tunnelen sin, medan ein berbar PC bak han framleis rapporterer ISP-adressa. Å leggje til godkjenningsreglar hjelper ikkje, og den feilen er opplysande: filtrering svarar på om ein pakke får passere, ikkje kvar han skal. Grensesnittvalet er allereie teke av eit ruteoppslag som ikkje veit noko om klientlista di. Rett opp oppslaget, og brannmuren er ikkje lenger den mistenkte.

Ein filterregel kan ikkje velje eit grensesnitt

Pakkehandteringa på ein Linux-ruter køyrer rutingsavgjerda først og forward-kroken etterpå. Når ein regel treff den utgåande tunneleininga, har kjernen allereie bestemt at tunnelen er vegen ut. Viss hovudtabellen framleis føretrekkjer WAN-standardruta, er pakken på veg til ISP-en, og godkjenningsregelen du nettopp skreiv ser han aldri. Den eine rekkjefølgjefaktaen forklarar kvifor ei heil side med nye brannmurreglar ikkje endrar noko.

Dømet nedanfor brukar eit LAN på 192.168.8.0/24 på br-lan, ei tunneleining tun0 og ein set-top-boks på 192.168.8.23 som bør bruke tunnelen.

Les oppslaget før du redigerer reglar

Be kjernen løyse opp ei rute på vegner av den klienten. Svaret inneheld den utgåande eininga og kjeldeadressa som ville bli vald, og det er alt du treng for å stadfeste diagnosen. Viss svaret nemner WAN-eininga, hadde pakken aldri ein sjanse til å nå regelen din.

ip -4 route get 198.51.100.7 from 192.168.8.23

Gjenta spørjinga for ein klient som bør bli på den vanlege vegen. Når begge svara nemner same eining, er ingen kjeldebasert policy i spel enno, og rettinga høyrer til rutinga og ikkje filtreringa.

Knytt ein tabell til klientane du vil dekkje

Policy-ruting set inn eit regeloppslag framom hovudtabellen. Bygg ein tabell der standardruta er tunnelen, og knytt han deretter til ein veljar: eit inngangsgrensesnitt, ei kjeldeadresse eller ei brannmurmarkering. Prioritetane avgjer rekkjefølgja, og hovudtabellen ligg langt nede på lista på 32766, så ein regel med lågt nummer blir spurd først. Grensesnittveljarar dekkjer kvar klient på brua; adresseveljarar dekkjer eia maskin.

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

Fastvaregrensesnitt viser vanlegvis dei same objekta som ei side for policy-ruting eller VPN-policy. Ei einingliste der er lettare å vedlikehalde enn handskrivne reglar og overlever vanlegvis oppgraderingar som endrar regelsyntaksen.

Vel veljaren med vilje. Ein grensesnittregel er kort og framtidsretta, men fangar også eigen administrasjonstrafikk frå ruteren som kjem inn på den brua. Ein kjelderegel er presis og treng ei redigering kvar gong eininglista endrar seg. Skriv ned valet, for den neste personen som spør kvifor éi eining oppfører seg annleis, vil trengje det.

Hald lokale mål utanfor tunnelen

Ein ny tabell kjenner berre rutene du legg i han. LAN-prefikset manglar, så skrivar- og NAS-trafikk ville følgje standardruta til tunnelen og forsvinne. Ei throw-rute avsluttar oppslaget i denne tabellen og gir avgjerda tilbake til hovudtabellen.

ip -4 route add throw 192.168.8.0/24 table 200

Hoppar du over den ruta, bryt lokale delingar saman, og sjølve administrasjonsøkta til ruteren kan forsvinne viss veljaren er breiare enn tenkt. Deretter avgjer kjeldespørsmålet: tunnelpakkar som framleis ber LAN-adresser treng at den andre sida kjenner ein returveg, medan masquerading på tunnelen fjernar det kravet og fjernar også klientidentiteten den andre sida ville sjå.

Reglar og ruter som blir lagde til under køyring, er borte etter ein omstart eller ei fastvareoppdatering. Legg dei til i oppstartsmekanismen til ruteren, start på nytt éin gong og test igjen frå klienten: den offentlege adressa hans, ein annan klient som bør bli på WAN, og teljarane til tunnelen under ei ny tilkopling.