VPN-klienten sletter den tilføyde ruten? Bruk en policytabell

Én /24 for en laboratorieprinter forsvinner mellom to ip route show-kall, og klientloggen sier bare at nettverket endret seg. Det var ingenting galt med kommandoen, prefikset eller rettighetene dine. En bedriftsklient som eier vertens rutingsmodell gjenoppretter den modellen hver gang noen andre redigerer den, så oppføringen du la til, fjernes som en inntrenger. Å kjempe mot den i samme tabell er en tapt posisjon. Løsningen er å slutte helt å konkurrere om den tabellen og legge unntaket der overvåkeren aldri ser.

Overvåkeren forklarer den manglende ruten

Vis det før du redesigner noe: les tabellen, legg til prefikset, vent noen sekunder, les igjen. Hvis oppføringen mangler og du ikke skrev noe for å fjerne den, er en agent på vakt. Finn prosessen som eier denne atferden, og les journalen dens rundt øyeblikket ruten forsvinner, fordi den samme tjenesten vanligvis vedlikeholder tunnelen, pakkefiltrene og resolver-konfigurasjonen. Å drepe den for å beholde ruten er en byttehandel du vil angre på ved neste gjenoppkobling.

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

Prefikset og grensesnittet ovenfor er plassholdere. Å kopiere et grensesnittnavn fra et fungerende eksempel på en annen maskin er den vanligste grunnen til at denne demonstrasjonen ikke gir noe som helst.

En andre tabell er usynlig for overvåkeren

Agenten bygger bare på nytt tabellen den eier. Gi unntaket sin egen tabell pluss en regel som sender samsvarende destinasjoner dit, og hovedtabellen endres aldri, så agenten har ingenting å rette. Det er hele ideen: ett navnerom med ruter som noen andre vedlikeholder, og ett som bare du rører.

Byttehandelen er vedlikehold. To objekter kan gli fra hverandre, og regelenes plassering i listen betyr like mye som ruten inne i tabellen den velger.

Bygg unntaket, og la det deretter vinne

Opprett tabellen, installer ruten og legg til en regel som velger tabellen for den destinasjonen. Prioritet avgjør om regelen din blir konsultert før eller etter dem klienten satte inn, og en regel som sorteres senere blir aldri nådd, så nummeret er en del av designet og ikke dekorasjon. Spør deretter kjernen hva den faktisk ville gjøre, noe som er et annet spørsmål enn det du konfigurerte.

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 løser opp ruten kjernen ville brukt, inkludert enheten og kildeadressen. Den skriver ikke ut tabellidentifikatoren, så par den med ip rule show når du må bekrefte hvilken tabell som vant. Sammen svarer de på det eneste spørsmålet som betyr noe: forlater trafikken til den adressen der du hadde tenkt?

Andre former for den samme ideen

Mønsteret generaliseres når du slutter å tenke i destinasjoner. Et lokalt subnett kan forbli tilgjengelig mens tunnelen beholder standardruten. Svar fra en LAN-tilkoblet SSH-server kan gå ut via grensesnittet de kom inn på i stedet for å forsvinne i tunnelen. Og en grensesnittbasert regel kan skyve alt som kommer på et trådløst grensesnitt inn i tunnelen, mens trafikk verten selv genererer blir værende på Ethernet:

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

Det siste tilfellet samsvarer med det innkommende grensesnittet i stedet for destinasjonen, noe som er en annen regeltype og en annen mental modell. Videresendt trafikk trenger også net.ipv4.ip_forward aktivert, og den fjerne enden må rute kildeområdet tilbake eller oversette det; en regel på én maskin skaper aldri den andre halvdelen av banen.

Behandle regelen som engangs

Regler og tabellruter lever i minnet. Etter en gjenoppkobling kan tunneleenheten få nytt navn, den tildelte adressen kan flytte seg, og en regel som holder den gamle verdien slutter stille å samsvare. Bruk hele endringen på nytt fra ett enkelt skript som eier den, og kontroller deretter ip rule show, gjeldende enhetsnavn og en fersk ip route get mot en reell destinasjon før du stoler på unntaket.

To grenser overlever uansett hvor nøye du er. Klienten kontrollerer fortsatt sine egne filterregler og resolver-konfigurasjonen, og et rutingsunntak overstyrer ingen av dem. Hvis klienten også sletter policyregelen din, er de støttede veiene dens egen split-tunnel-policy eller en klient som lar deg administrere ruter, som OpenConnect; å lappe en leverandørs binærfil for å stilne overvåkeren er en vedlikeholdsforpliktelse med en integritetssjekk vedlagt.

Skriv tabellnummeret, prioriteten og destinasjonen i et notat ved siden av skriptet. Ellers finner neste person en regel som overstyrer tunnelen og har ingen måte å vite hvorfor.