LAN-klienter ignorerer routerens VPN, indtil politikbaseret routing aktiveres

Routeren når internettet gennem sin tunnel, mens en bærbar computer bagved stadig rapporterer ISP-adressen. At tilføje accept-regler hjælper ikke, og den fejl er informativ: filtrering svarer på, om en pakke må passere, ikke hvor den skal hen. Grænsefladevalget er allerede truffet af et routingopslag, der intet ved om din klientliste. Ret opslaget, og firewalling er ikke længere den mistænkte.

En filterregel kan ikke vælge en grænseflade

Pakkestrømmen på en Linux-router kører routingbeslutningen først og forward-krogen bagefter. Når en regel matcher den udgående tunnel-enhed, har kernen allerede besluttet, at tunnelen er vejen ud. Hvis hovedtabellen stadig foretrækker WAN-standardruten, er pakken på vej mod ISP'en, og den accept-regel, du netop har skrevet, ser den aldrig. Den ene rækkefølgefakta forklarer, hvorfor en hel side med nye firewallregler ikke ændrer noget.

Eksemplet nedenfor bruger et LAN på 192.168.8.0/24 på br-lan, en tunnel-enhed tun0 og én set-top-boks på 192.168.8.23, som bør bruge tunnelen.

Læs opslaget, før du redigerer regler

Bed kernen om at slå en rute op på vegne af den klient. Svaret indeholder den udgående enhed og den kilde adresse, der ville blive valgt, og det er alt, du behøver for at bekræfte diagnosen. Hvis svaret nævner WAN-enheden, havde pakken aldrig en chance for at nå din regel.

ip -4 route get 198.51.100.7 from 192.168.8.23

Gentag forespørgslen for en klient, der bør blive på den almindelige vej. Når begge svar nævner den samme enhed, er der endnu ingen kildebaseret politik i spil, og rettelsen hører til routing frem for filtrering.

Knyt en tabel til de klienter, du vil dække

Politikbaseret routing indsætter et regelopslag før hovedtabellen. Byg en tabel, hvis standardrute er tunnelen, og knyt derefter tabellen til en vælger: en inputgrænseflade, en kilde adresse eller et firewallmærke. Prioriteter afgør rækkefølgen, og hovedtabellen ligger langt nede på listen ved 32766, så en regel med et lavt nummer konsulteres først. Grænsefladevælgere dækker hver klient på broen; adressevælgere dækker én maskine.

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

Firmwaregrænseflader viser normalt de samme objekter som en side til politikbaseret routing eller VPN-politik. En enhedsliste der er lettere at vedligeholde end håndskrevne regler og overlever ofte opgraderinger, der ændrer regelsyntaksen.

Vælg vælgeren med vilje. En grænsefladeregel er kort og fremtidssikker, men fanger også routerens egen administrationstrafik, der ankommer på den bro. En kilderegel er præcis og kræver en redigering, hver gang enhedslisten ændres. Skriv valget ned, for den næste person, der spørger, hvorfor én enhed opfører sig anderledes, får brug for det.

Hold lokale destinationer ude af tunnelen

En ny tabel kender kun de ruter, du lægger i den. LAN-præfikset mangler, så printer- og NAS-trafik ville følge tunnelens standardrute og forsvinde. En throw-rute afslutter opslaget i denne tabel og giver beslutningen tilbage til hovedtabellen.

ip -4 route add throw 192.168.8.0/24 table 200

Spring den rute over, og lokale delinger går i stykker, og routerens egen administrationssession kan forsvinde, hvis vælgeren er bredere end tilsigtet. Afklar derefter kilde-spørgsmålet: tunnelpakker, der stadig bærer LAN-adresser, har brug for, at den anden side kender en returvej, mens masquerading på tunnelen fjerner det krav og også fjerner den klientidentitet, den anden side ville se.

Regler og ruter, der tilføjes under kørsel, er væk efter en genstart eller en firmwareopdatering. Føj dem til routerens opstartsmekanisme, genstart én gang, og test igen fra klienten: dens offentlige adresse, en anden klient, der bør blive på WAN, og tunnelens tællere under en ny forbindelse.