VPN-klient sletter din tilføjede rute? Brug en policytabel

En /24 til en laboratorieprinter forsvinder mellem to ip route show-kald, og klientloggen siger kun, at netværket ændrede sig. Der var intet galt med kommandoen, præfikset eller dine rettigheder. En virksomhedsklient, der ejer værtens routingmodel, gennemtvinger den model, når nogen andre redigerer den, så den post, du tilføjede, fjernes som en ubuden gæst. At kæmpe imod den i samme tabel er en tabt position. Løsningen er at holde helt op med at konkurrere om den tabel og lægge undtagelsen et sted, hvor monitoren aldrig kigger.

Monitoren forklarer den manglende rute

Demonstrér det, før du redesigner noget: læs tabellen, tilføj præfikset, vent nogle sekunder, læs igen. Hvis posten mangler, og du ikke har skrevet noget for at fjerne den, holder en agent øje. Find den proces, der ejer den adfærd, og læs dens journal omkring det øjeblik, ruten forsvinder, for den samme tjeneste vedligeholder normalt tunnelen, pakkefiltrene og resolver-konfigurationen. At dræbe den for at få din rute til at holde er et bytte, du vil fortryde ved næste genopkobling.

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

Præfikset og grænsefladen ovenfor er pladsholdere. At kopiere et grænsefladenavn fra et fungerende eksempel på en anden maskine er den mest almindelige grund til, at denne demonstration slet intet giver.

En anden tabel er usynlig for monitoren

Agenten genopbygger kun den tabel, den ejer. Giv undtagelsen sin egen tabel plus en regel, der sender matchende destinationer derhen, og hovedtabellen ændrer sig aldrig, så der er intet for agenten at rette. Det er hele ideen: ét navnerum af ruter, som nogen andre vedligeholder, og ét som kun du rører ved.

Byttet er vedligeholdelse. To objekter kan drive fra hinanden, og reglens placering på listen betyder lige så meget som ruten inde i den tabel, den vælger.

Byg undtagelsen, og lad den derefter vinde

Opret tabellen, installer ruten, og tilføj en regel, der vælger tabellen for den destination. Prioritäten afgør, om din regel bliver konsulteret før eller efter dem, klienten indsatte, og en regel, der sorteres senere, bliver aldrig nået, så tallet er en del af designet og ikke en dekoration. Spørg derefter kernen, hvad den faktisk ville gøre, hvilket er et andet spørgsmål end det, du konfigurerede.

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 opløser den rute, kernen ville bruge, inklusive enheden og kildeadressen. Den udskriver ikke tabelidentifikatoren, så par den med ip rule show, når du skal bekræfte, hvilken tabel der vandt. Sammen besvarer de det eneste spørgsmål, der betyder noget: forlader trafikken til den adresse det sted, du havde tiltænkt?

Andre former for den samme idé

Mønsteret generaliserer, når du holder op med at tænke i destinationer. Et lokalt subnet kan forblive tilgængeligt, mens tunnelen beholder standardruten. Svar fra en LAN-tilsluttet SSH-server kan gå ud via den grænseflade, de ankom på, i stedet for at forsvinde i tunnelen. Og en grænsefladebaseret regel kan skubbe alt, der ankommer på en trådløs grænseflade, ind i tunnelen, mens trafik, som værten selv genererer, bliver på Ethernet:

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

Det sidste tilfælde matcher den indgående grænseflade frem for destinationen, hvilket er en anden regeltype og en anden tankemodel. Videresendt trafik kræver også net.ipv4.ip_forward aktiveret, og den fjerne ende skal route kildeområdet tilbage eller oversætte det; en regel på én maskine skaber aldrig den anden halvdel af stien.

Behandl reglen som engangs

Regler og tabelruter lever i hukommelsen. Efter en genopkobling kan tunneleenheden få nyt navn, den tildelte adresse kan flytte sig, og en regel med den gamle værdi holder stille op med at matche. Anvend hele ændringen fra et enkelt script, der ejer den, og kontroller derefter ip rule show, det aktuelle enhedsnavn og et frisk ip route get mod en rigtig destination, før du stoler på undtagelsen.

To grænser overlever al omhu. Klienten styrer stadig sine egne filterregler og resolver-konfigurationen, og en routing-undtagelse tilsidesætter ingen af dem. Hvis klienten også sletter din policy-regel, er de understøttede veje dens egen split-tunnel-politik eller en klient, der lader dig administrere ruter, såsom OpenConnect; at patche en leverandørs binære fil for at bringe dens monitor til tavshed er en vedligeholdelsesforpligtelse med en integritetskontrol på købet.

Skriv tabelnummeret, prioriteten og destinationen i en note ved siden af scriptet. Ellers finder den næste person en regel, der overtrumfer tunnelen, og har ingen måde at vide hvorfor.