LAN-asiakkaat ohittavat reitittimen VPN:n, kunnes käytäntöpohjainen reititys otetaan käyttöön

Reititin pääsee internetiin tunnelinsa kautta, kun taas sen takana oleva kannettava ilmoittaa yhä ISP-osoitteen. Hyväksymissääntöjen lisääminen ei auta, ja tämä epäonnistuminen on valaiseva: suodatus vastaa, saako paketti kulkea, ei siihen minne se menee. Rajapinnan valinnan on jo tehnyt reitityshaku, joka ei tiedä asiakaslistastasi mitään. Korjaa haku, niin palomuuri lakkaa olemasta epäilty.

Suodatussääntö ei voi valita rajapintaa

Pakettivirta Linux-reitittimellä tekee ensin reitityspäätöksen ja vasta sitten forward-koukun. Kun sääntö osuu lähtevään tunnelilaitteeseen, ydin on jo päättänyt, että tunneli on tie ulos. Jos päätaulukko suosii yhä WANin oletusreittiä, paketti on matkalla ISP:lle eikä juuri kirjoittamasi hyväksymissääntö näe sitä koskaan. Tämä yksi järjestystä koskeva tosiasia selittää, miksi sivu uusia palomuurisääntöjä ei muuta mitään.

Alla oleva esimerkki käyttää LAN-verkkoa 192.168.8.0/24 br-lanissa, tunnelilaitetta tun0 ja yhtä digiboksia osoitteessa 192.168.8.23, jonka pitäisi käyttää tunnelia.

Lue haku ennen kuin muokkaat sääntöjä

Pyydä ydintä selvittämään reitti tuon asiakkaan puolesta. Vastaus sisältää lähtevän laitteen ja valittavan lähdeosoitteen, ja se on kaikki, mitä tarvitset diagnoosin vahvistamiseen. Jos vastaus nimeää WAN-laitteen, paketilla ei ollut koskaan mahdollisuutta päästä sääntöösi.

ip -4 route get 198.51.100.7 from 192.168.8.23

Toista kysely asiakkaalle, jonka pitäisi pysyä tavallisella polulla. Kun molemmat vastaukset nimeävät saman laitteen, lähdekohtaista käytäntöä ei vielä ole pelissä, ja korjaus kuuluu reititykseen eikä suodatukseen.

Liitä taulukko asiakkaisiin, jotka haluat kattaa

Käytäntöpohjainen reititys lisää sääntöhaun ennen päätaulukkoa. Rakenna taulukko, jonka oletusreitti on tunneli, ja liitä se sitten valitsimeen: syöttörajapinta, lähdeosoite tai palomuurimerkki. Prioriteetit määräävät järjestyksen, ja päätaulukko on listalla hyvin alhaalla kohdassa 32766, joten pienen numeron sääntöä kysytään ensin. Rajapintavalitsimet kattavat jokaisen sillan asiakkaan; osoitevalitsimet kattavat yhden koneen.

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

Laiteohjelmiston käyttöliittymät näyttävät yleensä samat objektit kuin käytäntöpohjaisen reitityksen tai VPN-käytännön sivu. Laiteluettelo siellä on helpompi ylläpitää kuin käsin kirjoitetut säännöt ja kestää yleensä päivitykset, jotka muuttavat sääntöjen syntaksia.

Valitse valitsin tarkoituksella. Rajapintasääntö on lyhyt ja tulevaisuudenkestävä, mutta se nappaa myös reitittimen oman hallintaliikenteen, joka saapuu sille sillalle. Lähdesääntö on täsmällinen ja vaatii muokkauksen aina, kun laiteluettelo muuttuu. Kirjoita valinta ylös, koska seuraava henkilö, joka kysyy, miksi yksi laite käyttäytyy eri tavalla, tarvitsee sitä.

Pidä paikalliset kohteet tunnelin ulkopuolella

Uusi taulukko tuntee vain ne reitit, jotka siihen laitat. LAN-etuliite puuttuu, joten tulostimen ja NASin liikenne seuraisi tunnelin oletusreittiä ja katoaisi. Throw-reitti lopettaa haun tässä taulukossa ja palauttaa päätöksen päätaulukolle.

ip -4 route add throw 192.168.8.0/24 table 200

Jos jätät reitin pois, paikalliset jaot menevät rikki, ja reitittimen oma hallintasessio voi kadota, jos valitsin on laajempi kuin on tarkoitettu. Ratkaise sitten lähdekysymys: tunnelipaketit, jotka yhä kantavat LAN-osoitteita, tarvitsevat toiselta puolelta tunnetun paluupolun, kun taas tunnelilla tehtävä masquerading poistaa tämän vaatimuksen ja poistaa myös sen asiakasidentiteetin, jonka toinen puoli näkisi.

Ajonaikaisesti lisätyt säännöt ja reitit katoavat uudelleenkäynnistyksen tai laiteohjelmistopäivityksen jälkeen. Lisää ne reitittimen käynnistysmekanismiin, käynnistä kerran uudelleen ja testaa uudelleen asiakkaalta: sen julkinen osoite, toinen asiakas, jonka pitäisi pysyä WANissa, ja tunnelin laskurit uuden yhteyden aikana.