VPN-asiakas poistaa lisäämäsi reitin? Käytä käytäntötaulua

Yhden /24 laboratoriotulostimelle katoaa kahden ip route show-kutsun välissä, ja asiakkaan loki kertoo vain, että verkko muuttui. Komennossa, etuliitteessä tai oikeuksissasi ei ollut mitään vikaa. Yritysasiakas, joka omistaa isännän reititysmallin, palauttaa kyseisen mallin aina, kun joku muu muokkaa sitä, joten lisäämäsi merkintä poistetaan tunkeilijana. Sitä vastaan taisteleminen samassa taulussa on häviöasema. Ratkaisu on lopettaa kokonaan kilpailu tuosta taulusta ja sijoittaa poikkeus sinne, minne valvoja ei koskaan katso.

Valvoja selittää kadonneen reitin

Näytä se ennen kuin suunnittelet mitään uudelleen: lue taulu, lisää etuliite, odota muutama sekunti, lue uudelleen. Jos merkintä puuttuu etkä kirjoittanut mitään sen poistamiseksi, jokin agentti tarkkailee. Etsi prosessi, joka omistaa tämän käyttäytymisen, ja lue sen lokia reitin katoamisen hetken ympäriltä, sillä sama palvelu ylläpitää yleensä tunnelia, pakettisuodattimia ja resolverin asetuksia. Sen tappaminen reittisi pitämiseksi on vaihtokauppa, jota tulet katumaan seuraavassa uudelleenyhdistämisessä.

ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route show

Yllä oleva etuliite ja liitäntä ovat paikkamerkkejä. Liitännän nimen kopioiminen toisella koneella toimivasta esimerkistä on yleisin syy siihen, ettei tämä esittely tuota yhtään mitään.

Toinen taulu on näkymätön valvojalle

Agentti rakentaa uudelleen vain omistamansa taulun. Anna poikkeukselle oma taulu ja sääntö, joka lähettää vastaavat kohteet sinne, niin päätaulu ei koskaan muutu, eikä agentilla ole mitään korjattavaa. Koko idea on tämä: yksi reittien nimiavaruus, jota joku muu ylläpitää, ja toinen, johon vain sinä kosket.

Vaihtokauppa on ylläpito. Kaksi oliota voi ajautua erilleen, ja säännön sijainti luettelossa on yhtä tärkeä kuin reitti taulussa, jonka se valitsee.

Rakenna poikkeus ja anna sen sitten voittaa

Luo taulu, asenna reitti ja lisää sääntö, joka valitsee taulun kyseiselle kohteelle. Prioriteetti ratkaisee, tarkistetaanko sääntösi ennen asiakkaan lisäämiä sääntöjä vai niiden jälkeen, eikä myöhemmin lajiteltu sääntö koskaan toteudu, joten numero on osa suunnittelua eikä koriste. Kysy sitten ytimeltä, mitä se todella tekisi, mikä on eri kysymys kuin se, mitä konfiguroit.

ip rule add to 192.168.2.0/24 table 110 pref 30010
ip route add 192.168.2.0/24 dev enp0s31f6 table 110
ip route get 192.168.2.50

ip route get selvittää reitin, jota ydin käyttäisi, mukaan lukien laite ja lähdeosoite. Se ei tulosta taulun tunnistetta, joten yhdistä se ip rule show-komentoon, kun sinun on vahvistettava, mikä taulu voitti. Yhdessä ne vastaavat ainoaan tärkeään kysymykseen: lähteekö liikenne tuohon osoitteeseen sieltä, mihin tarkoitit?

Saman idean muita muotoja

Malli yleistyy, kun lopetat ajattelemisen kohteina. Paikallinen aliverkko voi pysyä tavoitettavana, kun tunnelilla on oletusreitti. LANiin liitetyn SSH-palvelimen vastaukset voivat lähteä siltä liitännältä, jolta ne saapuivat, sen sijaan että ne katoaisivat tunneliin. Ja liitäntäpohjainen sääntö voi työntää kaiken langattomaan liitäntään saapuvan tunneliin, kun isännän itse tuottama liikenne jää Ethernetiin:

ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10

Viimeinen tapaus vastaa saapuvaa liitäntää eikä kohdetta, mikä on eri sääntötyyppi ja eri ajatusmalli. Edelleen välitetty liikenne tarvitsee myös käytössä olevan net.ipv4.ip_forward-asetuksen, ja kauko-osan on reititettävä lähdealue takaisin tai käännettävä se; yhden koneen sääntö ei koskaan luo polun toista puolta.

Kohtele sääntöä kertakäyttöisenä

Säännöt ja taulureitit elävät muistissa. Uudelleenyhdistämisen jälkeen tunnelilaite voi saada uuden nimen, osoitettu osoite voi siirtyä, ja vanhaa arvoa pitävä sääntö lakkaa hiljaa täsmäämästä. Käytä koko muutos uudelleen yhdestä skriptistä, joka sen omistaa, ja tarkista sitten ip rule show, nykyinen laitenimi ja tuore ip route get todellista kohdetta vastaan ennen kuin luotat poikkeukseen.

Kaksi rajaa säilyy kaikesta huolellisuudesta huolimatta. Asiakas hallitsee edelleen omia suodatinsääntöjään ja resolverin asetuksia, eikä reitityspoikkeus ohita kumpaakaan. Jos asiakas poistaa myös käytäntösäännösi, tuetut polut ovat sen oma jaetun tunnelin käytäntö tai asiakas, joka sallii reittien hallinnan, kuten OpenConnect; toimittajan binaarin paikkaaminen sen valvojan vaientamiseksi on ylläpitovelvoite, johon liittyy eheystarkistus.

Kirjoita taulun numero, prioriteetti ja kohde skriptin viereen muistiinpanoon. Muuten seuraava henkilö löytää säännön, joka ohittaa tunnelin, eikä hänellä ole keinoa tietää miksi.