Clientul VPN șterge ruta pe care ați adăugat-o? Folosiți un tabel de politici

Un /24 pentru o imprimantă de laborator dispare între două apeluri ip route show, iar jurnalul clientului spune doar că rețeaua s-a schimbat. Nu era nimic greșit cu comanda, prefixul sau privilegiile dumneavoastră. Un client corporativ care deține modelul de rutare al gazdei reafirmă acel model ori de câte ori altcineva îl editează, așa că intrarea pe care ați adăugat-o este eliminată ca intrus. Lupta cu el în același tabel este o poziție pierdută. Soluția este să renunțați complet la competiția pentru acel tabel și să puneți excepția unde monitorul nu se uită niciodată.

Monitorul explică ruta dispărută

Demonstrați asta înainte de a reproiecta ceva: citiți tabelul, adăugați prefixul, așteptați câteva secunde, citiți din nou. Dacă intrarea lipsește și nu ați tastat nimic pentru a o elimina, un agent supraveghează. Găsiți procesul care deține acest comportament și citiți-i jurnalul în jurul momentului în care ruta dispare, pentru că același serviciu întreține de obicei tunelul, filtrele de pachete și configurația resolverului. Să-l ucideți ca să vă rămână ruta este un schimb pe care îl veți regreta la următoarea reconectare.

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

Prefixul și interfața de mai sus sunt substituenți. Copierea unui nume de interfață dintr-un exemplu funcțional de pe altă mașină este cel mai frecvent motiv pentru care această demonstrație nu produce absolut nimic.

Un al doilea tabel este invizibil pentru monitor

Agentul reconstruiește doar tabelul pe care îl deține. Dați excepției propriul tabel plus o regulă care trimite acolo destinațiile potrivite, iar tabelul principal nu se schimbă niciodată, așa că agentul nu are ce corecta. Aceasta este întreaga idee: un spațiu de nume de rute întreținut de altcineva și unul pe care îl atingeți doar dumneavoastră.

Schimbul este întreținerea. Două obiecte pot diverge, iar poziția regulii în listă contează la fel de mult ca ruta din tabelul pe care îl selectează.

Construiți excepția, apoi faceți-o să câștige

Creați tabelul, instalați ruta și adăugați o regulă care selectează tabelul pentru acea destinație. Prioritatea decide dacă regula dumneavoastră este consultată înainte sau după cele inserate de client, iar o regulă sortată mai târziu nu este niciodată atinsă, deci numărul face parte din proiect, nu este decor. Apoi întrebați nucleul ce ar face de fapt, ceea ce este o altă întrebare decât ceea ce ați configurat.

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 rezolvă ruta pe care ar folosi-o nucleul, inclusiv dispozitivul și adresa sursă. Nu afișează identificatorul tabelului, așa că îl asociați cu ip rule show când trebuie să confirmați care tabel a câștigat. Împreună răspund la singura întrebare importantă: traficul către acea adresă iese unde ați intenționat?

Alte forme ale aceleiași idei

Modelul se generalizează imediat ce încetați să gândiți în destinații. O subrețea locală poate rămâne accesibilă în timp ce tunelul păstrează ruta implicită. Răspunsurile de la un server SSH conectat la LAN pot ieși prin interfața pe care au ajuns în loc să dispară în tunel. Iar o regulă bazată pe interfață poate împinge în tunel tot ce sosește pe o interfață wireless, în timp ce traficul generat de gazdă rămâne pe Ethernet:

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

Ultimul caz corespunde interfeței de intrare, nu destinației, ceea ce este alt tip de regulă și alt model mental. Traficul redirecționat are nevoie și de net.ipv4.ip_forward activat, iar capătul îndepărtat trebuie să ruteze înapoi intervalul sursă sau să îl traducă; o regulă pe o singură mașină nu creează niciodată cealaltă jumătate a căii.

Tratați regula ca fiind de unică folosință

Regulile și rutele de tabel trăiesc în memorie. După o reconectare, dispozitivul tunelului poate fi redenumit, adresa alocată se poate muta, iar o regulă cu vechea valoare încetează silențios să se potrivească. Reaplicați întreaga modificare dintr-un singur script care o deține, apoi verificați din nou ip rule show, numele actual al dispozitivului și un ip route get proaspăt față de o destinație reală înainte de a avea încredere în excepție.

Două limite supraviețuiesc oricărei atenții. Clientul controlează în continuare propriile reguli de filtrare și configurația resolverului, iar o excepție de rutare nu le înlocuiește pe niciuna. Dacă clientul șterge și regula dumneavoastră de politică, căile acceptate sunt propria politică de tunel divizat sau un client care vă permite să administrați rute, cum ar fi OpenConnect; patch-ul unui binar de furnizor pentru a-i reduce la tăcere monitorul este un angajament de întreținere cu o verificare de integritate atașată.

Scrieți numărul tabelului, prioritatea și destinația într-o notă lângă script. Altfel, următoarea persoană găsește o regulă care depășește tunelul și nu are cum să afle de ce.