LAN-klienter ignorerer ruterens VPN til policy-ruting tas i bruk

Ruteren når internett gjennom tunnelen sin, mens en bærbar PC bak den fortsatt rapporterer ISP-adressen. Å legge til godkjenningsregler hjelper ikke, og den feilen er opplysende: filtrering svarer på om en pakke får passere, ikke hvor den skal. Grensesnittvalget er allerede tatt av et ruteoppslag som ikke vet noe om klientlisten din. Rett opp oppslaget, og brannmuren er ikke lenger den mistenkte.

En filterregel kan ikke velge et grensesnitt

Pakkehåndteringen på en Linux-ruter kjører rutingsbeslutningen først og forward-kroken etterpå. Når en regel treffer den utgående tunnelenheten, har kjernen allerede bestemt at tunnelen er veien ut. Hvis hovedtabellen fortsatt foretrekker WAN-standardruten, er pakken på vei til ISP-en, og godkjenningsregelen du nettopp skrev ser den aldri. Den ene rekkefølgefaktaen forklarer hvorfor en hel side med nye brannmurregler ikke endrer noe.

Eksempelet nedenfor bruker et LAN på 192.168.8.0/24 på br-lan, en tunnelenhet tun0 og én set-top-boks på 192.168.8.23 som bør bruke tunnelen.

Les oppslaget før du redigerer regler

Be kjernen løse opp en rute på vegne av den klienten. Svaret inneholder den utgående enheten og kildeadressen som ville blitt valgt, og det er alt du trenger for å bekrefte diagnosen. Hvis svaret nevner WAN-enheten, hadde pakken aldri en sjanse til å nå regelen din.

ip -4 route get 198.51.100.7 from 192.168.8.23

Gjenta spørringen for en klient som bør bli på den vanlige veien. Når begge svarene nevner samme enhet, er ingen kildebasert policy i spill ennå, og rettelsen hører til rutingen og ikke filtreringen.

Knytt en tabell til klientene du vil dekke

Policy-ruting setter inn et regeloppslag foran hovedtabellen. Bygg en tabell der standardruten er tunnelen, og knytt den deretter til en velger: et inngangsgrensesnitt, en kildeadresse eller en brannmurmarkering. Prioritetene bestemmer rekkefølgen, og hovedtabellen ligger langt nede på listen på 32766, så en regel med lavt nummer blir spurt først. Grensesnittvelgere dekker hver klient på broen; adressevelgere dekker én maskin.

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

Fastvaregrensesnitt viser vanligvis de samme objektene som en side for policy-ruting eller VPN-policy. En enhetsliste der er lettere å vedlikeholde enn håndskrevne regler og overlever vanligvis oppgraderinger som endrer regelsyntaksen.

Velg velgeren med vilje. En grensesnittregel er kort og fremtidsrettet, men fanger også ruterens egen administrasjonstrafikk som kommer inn på den broen. En kjelderegel er presis og trenger en redigering hver gang enhetslisten endres. Skriv ned valget, for den neste personen som spør hvorfor én enhet oppfører seg annerledes, vil trenge det.

Hold lokale mål utenfor tunnelen

En ny tabell kjenner bare rutene du legger i den. LAN-prefikset mangler, så skriver- og NAS-trafikk ville følge tunnelens standardrute og forsvinne. En throw-rute avslutter oppslaget i denne tabellen og gir beslutningen tilbake til hovedtabellen.

ip -4 route add throw 192.168.8.0/24 table 200

Hopper du over den ruten, brytes lokale delinger, og ruterens egen administrasjonsøkt kan forsvinne hvis velgeren er bredere enn tiltenkt. Deretter avgjør kilde-spørsmålet: tunnelpakker som fortsatt bærer LAN-adresser trenger at den andre siden kjenner en returvei, mens masquerading på tunnelen fjerner det kravet og fjerner også klientidentiteten den andre siden ville se.

Regler og ruter som legges til under kjøring, er borte etter en omstart eller en fastvareoppdatering. Legg dem til i ruterens oppstartsmekanisme, start på nytt én gang og test igjen fra klienten: dens offentlige adresse, en annen klient som bør bli på WAN, og tunnelens tellere under en ny tilkobling.