VPN-klienten slettar den tilførte ruta? Bruk ein policytabell

Éi /24 for ein laboratorieprinter forsvinn mellom to ip route show-kall, og klientloggen seier berre at nettverket endra seg. Det var ingenting gale med kommandoen, prefikset eller rettane dine. Ein bedriftsklient som eig rutemodellen til verten, gjenopprettar den modellen kvar gong nokon andre redigerer han, så oppføringa du la til, blir fjerna som ein inntrengjar. Å kjempe mot han i same tabell er ein tapt posisjon. Løysinga er å slutte heilt å konkurrere om den tabellen og leggje unntaket der overvakaren aldri ser.

Overvakaren forklarer den manglande ruta

Vis det før du redesignar noko: les tabellen, legg til prefikset, vent nokre sekund, les igjen. Viss oppføringa manglar og du ikkje skreiv noko for å fjerne ho, er ein agent på vakt. Finn prosessen som eig denne åtferda, og les journalen hans rundt augneblinken ruta forsvinn, fordi den same tenesta vanlegvis vedlikeheld tunnelen, pakkefiltra og resolver-konfigurasjonen. Å drepe han for å behalde ruta er ein byttehandel du vil angre på ved neste gjenoppkopling.

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

Prefikset og grensesnittet ovanfor er plasshaldarar. Å kopiere eit grensesnittnamn frå eit fungerande døme på ein annan maskin er den vanlegaste grunnen til at denne demonstrasjonen ikkje gir noko som helst.

Ein andre tabell er usynleg for overvakaren

Agenten byggjer berre på nytt tabellen han eig. Gi unntaket sin eigen tabell pluss ein regel som sender samsvarande destinasjonar dit, og hovudtabellen endrar seg aldri, så agenten har ingenting å rette. Det er heile ideen: eitt namnerom med ruter som nokon andre vedlikeheld, og eitt som berre du rører.

Byttehandelen er vedlikehald. To objekt kan gli frå kvarandre, og plasseringa av regelen i lista betyr like mykje som ruta inne i tabellen han vel.

Bygg unntaket, og la det deretter vinne

Opprett tabellen, installer ruta og legg til ein regel som vel tabellen for den destinasjonen. Prioritet avgjer om regelen din blir konsultert før eller etter dei klienten sette inn, og ein regel som blir sortert seinare blir aldri nådd, så nummeret er ein del av designet og ikkje dekorasjon. Spør deretter kjernen kva han faktisk ville gjere, noko som er eit anna 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øyser opp ruta kjernen ville brukt, inkludert eininga og kjeldeadressa. Han skriv ikkje ut tabellidentifikatoren, så par han med ip rule show når du må stadfeste kva tabell som vann. Saman svarar dei på det einaste spørsmålet som betyr noko: forlèt trafikken til den adressa der du hadde tenkt?

Andre former for den same ideen

Mønsteret generaliserer når du sluttar å tenkje i destinasjonar. Eit lokalt subnett kan halde fram med å vere tilgjengeleg medan tunnelen held standardruta. Svar frå ein LAN-tilknytt SSH-tenar kan gå ut via grensesnittet dei kom inn på i staden for å forsvinne i tunnelen. Og ein grensesnittbasert regel kan skyve alt som kjem på eit trådlaust grensesnitt inn i tunnelen, medan trafikk verten sjølv genererer blir verande på Ethernet:

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

Det siste tilfellet samsvarar med det innkommande grensesnittet i staden for destinasjonen, noko som er ein annan regeltype og ein annan mental modell. Vidaresend trafikk treng òg net.ipv4.ip_forward aktivert, og den fjerne enden må rute kjeldeområdet tilbake eller omsetje det; ein regel på éin maskin skaper aldri den andre halvdelen av banen.

Behandle regelen som eingongs

Reglar og tabellruter lever i minnet. Etter ei gjenoppkopling kan tunneleininga få nytt namn, den tildelte adressa kan flytte seg, og ein regel som held den gamle verdien sluttar stille å samsvare. Bruk heile endringa på nytt frå eitt enkelt skript som eig ho, og kontroller deretter ip rule show, gjeldande einingsnamn og ein fersk ip route get mot ein reell destinasjon før du stolar på unntaket.

To grenser overlever uansett kor nøye du er. Klienten kontrollerer framleis sine eigne filterreglar og resolver-konfigurasjonen, og eit ruteunntak overstyrer ingen av dei. Viss klienten òg slettar policyregelen din, er dei støtta vegane hans eigen split-tunnel-policy eller ein klient som lèt deg administrere ruter, som OpenConnect; å lappe ei binærfil frå ein leverandør for å stille overvakaren hans er ei vedlikehaldsforplikting med ein integritetssjekk vedlagt.

Skriv tabellnummeret, prioriteten og destinasjonen i eit notat ved sida av skriptet. Elles finn neste person ein regel som overstyrer tunnelen og har ingen måte å vite kvifor.