Ĉu la VPN-kliento forigas vian aldonitan itineron? Uzu politikan tabelon
La kliento realtrudas la itinerojn, kiujn ĝi posedas, do permane aldonita rikordo malaperas en sekundoj. Metu la escepton en politikan tabelon kun regul-prefero, kiu venkas.
Unu /24 por laboratoria printilo malaperas inter du alvokoj de ip route show, kaj la klienta protokolo nur diras, ke la reto ŝanĝiĝis. Nenio maltrafis en la komando, la prefikso aŭ viaj rajtoj. Entreprena kliento, kiu posedas la enkursigan modelon de la gastiganto, realtrudas tiun modelon ĉiam, kiam iu alia redaktas ĝin, do la rikordo, kiun vi aldonis, foriĝas kiel entrudulo. Batali kontraŭ ĝi en la sama tabelo estas malgajnita pozicio. La solvo estas tute ĉesi konkurenci pri tiu tabelo kaj meti la escepton tie, kie la monitoro neniam rigardas.
La monitoro klarigas la mankan itineron
Montru tion antaŭ ol vi rekonstruos ion ajn: legu la tabelon, aldonu la prefikson, atendu kelkajn sekundojn, legu denove. Se la rikordo mankas kaj vi tajpis nenion por forigi ĝin, agento observas. Trovu la procezon, kiu posedas tiun konduton, kaj legu ĝian protokolon ĉirkaŭ la momento, kiam la itinero malaperas, ĉar la sama servo kutime prizorgas la tunelon, la pakedfiltrojn kaj la agordon de la solvilo. Mortigi ĝin por ke via itinero restu estas interŝanĝo, kiun vi bedaŭros ĉe la sekva rekonekto.
ip route show
ip route add 192.168.2.0/24 dev enp0s31f6
sleep 5; ip route showLa prefikso kaj interfaco supre estas lokokupiloj. Kopii interfacan nomon el funkcianta ekzemplo sur alia maŝino estas la plej ofta kialo, ke ĉi tiu demonstro tute nenion produktas.
Dua tabelo estas nevidebla por la monitoro
La agento rekonstruas nur la tabelon, kiun ĝi posedas. Donu al la escepto propran tabelon plus regulon, kiu sendas kongruajn celojn tien, kaj la ĉefa tabelo neniam ŝanĝiĝas, do la agento havas nenion por korekti. Tio estas la tuta ideo: unu nomspaco de itineroj, kiun prizorgas iu alia, kaj unu, kiun nur vi tuŝas.
La interŝanĝo estas prizorgado. Du objektoj povas malproksimiĝi, kaj la pozicio de la regulo en la listo gravas same kiel la itinero ene de la tabelo, kiun ĝi elektas.
Konstruu la escepton, poste igi ĝin venki
Kreu la tabelon, instalu la itineron kaj aldonu regulon, kiu elektas la tabelon por tiu celo. La prefero decidas, ĉu via regulo estas konsultata antaŭ aŭ post tiuj, kiujn la kliento enmetis, kaj regulo, kiu ordiĝas poste, neniam atingiĝas, do la numero estas parto de la dezajno kaj ne ornamaĵo. Poste demandu la kernon, kion ĝi vere farus, kio estas alia demando ol tio, kion vi agordis.
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.50ip route get solvas la itineron, kiun la kerno uzus, inkluzive de la aparato kaj fonta adreso. Ĝi ne presas la tabelan identigilon, do parigu ĝin kun ip rule show, kiam vi devas konfirmi, kiu tabelo venkis. Kune ili respondas la solan demandon, kiu gravas: ĉu trafiko al tiu adreso foriras tien, kien vi intencis?
Aliaj formoj de la sama ideo
La ŝablono ĝeneraliĝas, tuj kiam vi ĉesas pensi per celoj. Loka subreto povas resti atingebla, dum la tunelo tenas la defaŭltan itineron. Respondoj de LAN-alkroĉita SSH-servilo povas eliri per la interfaco, per kiu ili alvenis, anstataŭ malaperi en la tunelon. Kaj interfaca regulo povas puŝi ĉion, kio alvenas sur sendrata interfaco, en la tunelon, dum trafiko, kiun la gastiganto mem generas, restas sur Ethernet:
ip rule add iif wlan0 table 10
ip route add default dev tun0 table 10Tiu lasta kazo kongruas la envenantan interfacon anstataŭ la celon, kio estas alia regula tipo kaj alia mensa modelo. Plusendita trafiko ankaŭ bezonas ŝaltitan net.ipv4.ip_forward, kaj la malproksima fino devas enkursigi la fontan intervalon reen aŭ traduki ĝin; regulo sur unu maŝino neniam kreas la alian duonon de la vojo.
Traktu la regulon kiel forĵeteblan
Reguloj kaj tabelaj itineroj vivas en memoro. Post rekonekto la tunela aparato povas esti renomita, la asignita adreso povas moviĝi, kaj regulo kun la malnova valoro silente ĉesas kongrui. Reapliku la tutan ŝanĝon el unu skripto, kiu posedas ĝin, poste rekontrolu ip rule show, la aktualan aparatan nomon kaj novan ip route get kontraŭ reala celo antaŭ ol fidi la escepton.
Du limoj postvivas ajnan zorgon. La kliento ankoraŭ kontrolas siajn proprajn filtrregulojn kaj la agordon de la solvilo, kaj enkursiga escepto transprenas neniun el ili. Se la kliento ankaŭ forigas vian politikan regulon, la subtenataj vojoj estas ĝia propra politiko de dividita tunelo aŭ kliento, kiu lasas vin administri itinerojn, kiel OpenConnect; fliki vendistan binaraĵon por silentigi ĝian monitoron estas prizorga devontigo kun integreca kontrolo alkroĉita.
Skribu la tabelan numeron, la preferon kaj la celon en noton apud la skripto. Alie la sekva persono trovas regulon, kiu superas la tunelon, kaj havas neniun rimedon scii kial.