LAN-i kliendid eiravad ruuteri VPN-i, kuni poliitikapõhine marsruutimine rakendub

Ruuter jõuab internetti oma tunneli kaudu, samal ajal kui selle taga olev sülearvuti teatab endiselt ISP aadressi. Vastuvõtureeglite lisamine ei aita ja see ebaõnnestumine on õpetlik: filtreerimine vastab, kas pakett tohib läbi minna, mitte kuhu see läheb. Liidese valiku on juba teinud marsruudiotsing, mis ei tea sinu kliendinimekirjast midagi. Paranda otsing ja tulemüür ei ole enam kahtlusalune.

Filtrireegel ei saa liidest valida

Paketivoog Linuxi ruuteril teeb kõigepealt marsruudiotsuse ja seejärel forward-konksu. Kui reegel sobib väljuva tunneliseadmega, on tuum juba otsustanud, et tunnel on väljapääs. Kui põhitabel eelistab endiselt WAN-i vaikemarsruuti, on pakett teel ISP juurde ja äsja kirjutatud vastuvõtureegel ei näe seda kunagi. See üks järjekorrafakt selgitab, miks uute tulemüürireeglite leht ei muuda midagi.

Allolev näide kasutab LAN-i 192.168.8.0/24 br-lanil, tunneliseadet tun0 ja ühte digiboksi aadressil 192.168.8.23, mis peaks kasutama tunnelit.

Loe otsing läbi enne reeglite muutmist

Palu tuumal selle kliendi nimel marsruut lahendada. Vastus sisaldab väljuvat seadet ja valitavat lähteaadressi ning see on kõik, mida diagnoosi kinnitamiseks vaja. Kui vastus nimetab WAN-i seadet, ei olnud paketil kunagi võimalust sinu reeglini jõuda.

ip -4 route get 198.51.100.7 from 192.168.8.23

Korda päringut kliendi jaoks, kes peaks jääma tavalisse teekonda. Kui mõlemad vastused nimetavad sama seadet, ei ole allikapõhine poliitika veel mängus ja parandus kuulub marsruutimisse, mitte filtreerimisse.

Seo tabel klientidega, keda soovid katta

Poliitikapõhine marsruutimine lisab reegliotsingu enne põhitabelit. Ehita tabel, mille vaikemarsruut on tunnel, ja seo see tabel seejärel valijaga: sisendliides, lähteaadress või tulemüürimärk. Prioriteedid määravad järjekorra ja põhitabel asub nimekirjas väga all, 32766 juures, seega madalama numbriga reeglit vaadatakse esimesena. Liidese valijad katavad iga kliendi sillal; aadressi valijad katavad ühe masina.

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

Püsivara liidesed näitavad tavaliselt samu objekte nagu poliitikapõhise marsruutimise või VPN-i poliitika leht. Seadmenimekiri on seal lihtsam hooldada kui käsitsi kirjutatud reeglid ja peab tavaliselt vastu uuendustele, mis muudavad reeglite süntaksit.

Vali valija teadlikult. Liidese reegel on lühike ja tulevikukindel, kuid püüab kinni ka ruuteri enda haldusliikluse, mis sellele sillale saabub. Allika reegel on täpne ja vajab muutmist alati, kui seadmenimekiri muutub. Kirjuta valik üles, sest järgmine inimene, kes küsib, miks üks seade käitub teisiti, vajab seda.

Hoia kohalikud sihtkohad tunnelist väljas

Uus tabel teab ainult marsruute, mille sa sinna paned. LAN-i prefiks puudub, seega printeri ja NAS-i liiklus järgiks tunneli vaikemarsruuti ja kaoks. Throw-marsruut lõpetab otsingu selles tabelis ja annab otsuse tagasi põhitabelile.

ip -4 route add throw 192.168.8.0/24 table 200

Jäta see marsruut vahele ja kohalikud jagamised katkevad, samuti võib ruuteri enda haldusseanss kaduda, kui valija on kavatsetust laiem. Seejärel lahenda allika küsimus: tunnelipaketid, mis kannavad endiselt LAN-i aadresse, vajavad, et kaugpool teaks tagasiteed, samas kui tunnelil tehtav masquerading eemaldab selle nõude ja eemaldab ka kliendi identiteedi, mida kaugpool näeks.

Käitamise ajal lisatud reeglid ja marsruudid kaovad pärast taaskäivitust või püsivara uuendust. Lisa need ruuteri käivitusmehhanismi, taaskäivita korra ja testi uuesti kliendist: selle avalik aadress, teine klient, kes peaks jääma WAN-i, ja tunneli loendurid uue ühenduse ajal.