Kontā balstīta maršrutēšana ir piemērota, ja katra viena Linux lietotāja IPv4 ligzda ir jāizlaiž caur esošu tuneli, un tā nav piemērota, ja jums vajadzīga izolācija programmas līmenī. Tā izvēlas pēc UID, tāpēc viss, kas darbojas ar šo kontu, ir tvērumā, tostarp aizmirstais pakešuzdevums. Atrisiniet šo jautājumu, pirms pieskaraties kaut vienai ip rule.

Tālāk esošais piemērs pieņem atsevišķu pārlūka kontu ar UID 1500, tuneļa ierīci tun-office ar vietējo adresi 10.80.0.11 un VPN, kas atļauj attiecīgos galamērķus. Pats dēmons darbojas ārpus šī UID.

Trīs nosacījumi, kas izvēlas mehānismu

Izvēlieties UID noteikumu, kad darbu veicošā identitāte ir konts, kad visa tā trafika pārvietošana ir pieņemama un kad namespace būtu smagāks, nekā uzdevums ir pelnījis. Izvēlieties tīkla namespace, kad darba slodzei vajadzīgas savas saskarnes, atrisinātājs un maršrutēšanas tabula. Izvēlieties starpniekserveri vai piesaisti katram procesam kad jāpārvieto tieši viena lietojumprogramma, kamēr pārējā sesija paliek vietējā ceļā. Šo trīs pierakstīšana novērš noteikumu, kas klusi aptver vairāk, nekā paredzēts.

Kļūda, no kuras jāizvairās, ir pieņēmums, ka palaidējs nosaka īpašnieku. Pārlūks, kuram URL nodeva cita lietotāja sesija, nav izveidojis ligzdas ar UID 1500, un neviens noteikums nepārvietos tā radīto trafiku.

Tabula, noteikums un sargs

Pēc esošo noteikumu pārbaudes un neizmantotu tabulas un prioritātes numuru izvēles izkārtojums ir īss: noklusējuma maršruts īpašā tabulā, kas nes tuneļa avota adresi, noteikums, kas konta vaicājumus sūta uz šo tabulu, un noslēguma noteikums, kas bloķē rezerves ceļu. Pierakstīts tas ir idempotenta maršruta aizstāšana, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, kam seko ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

Sargs ir ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, un tas nozīmē vairāk, nekā liek domāt tā garums. Bez tā tabulā 51820 trūkstošais maršruts iekrīt parastajā augšupceļā, un konts klusi noplūdina trafiku, ko politikai bija jānoķer. Ar to tā pati kļūme kļūst par taimautu, tas ir, bloķēšanu, nevis rezerves ceļu.

Turiet parasto vietējās adreses noteikumu šo priekšā un apzināti izlemiet, vai LAN vai pārvaldības izņēmumi iet pirms izvēlētās tabulas. Tur atrastais noklusējums vēlāk nevaicā main par konkrētāku LAN maršrutu, kas pārsteidz tos, kuri gaida, ka garākā prefiksa atbilstība darbojas starp tabulām. Ierakstiet paredzēto izņēmumu sarakstu izmaiņu piezīmē, kamēr pamatojums vēl ir svaigs.

Ko UID maršrutēšana atstāj ārpusē: DNS

Atrisinātāja dēmons atver savas augšupējās ligzdas ar savu UID, tāpēc 1500 izvēle šos vaicājumus nepārvieto uz tabulu 51820. DNS integrācija ir atsevišķs lēmums: vērsiet kontu uz atrisinātāju, kas sasniedzams caur tuneli, vai pieņemiet, ka nosaukumu atrisināšana seko resursdatora ceļam, bet trafiks ne.

Loopback vaicājums vietējam stub nav pierādījums, ka augšupējais vaicājums izmantoja pārlūka maršrutu, un arī veiksmīga lapas ielāde no kešatmiņas nav.

IPv6 projektā vajag savu teikumu

Iepriekš minētie noteikumi aptver tikai IPv4. Ja prasība ir IPv4 tunelis bez tieša IPv6 no šī konta, pievienojiet pārskatītu noslēguma noteikumu, piemēram, ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, pēc tam pārbaudiet iepriekšējos IPv6 noteikumus un loopback izņēmumus, ko vēlaties saglabāt.

Tieša IPv6 bloķēšana nav dubultsteka tuneļošana; tā ir robeža. To saucot par tuneļošanu, jūs mulsināsiet nākamo cilvēku, kurš lasīs politiku, un apjukums izpaudīsies kā atbalsta pieteikums par salauztu IPv6 vietni.

Pārbaudiet ar īsto kontu, pēc tam pārņemiet dzīves ciklu

Salīdziniet vaicājumus: ip -4 route get 198.51.100.25 uid 1500 ar to pašu galamērķi un parastu UID. Pēc tam veiciet atļautu pieprasījumu ar īpašo kontu un pārbaudiet avota adresi, ko redz tālā puse. Vēlamā avota adrese nav source NAT, un tā neuzvarēs lietojumprogrammu, kas piesaista ko citu. Ja abi vaicājumi atgriež vienu un to pašu ceļu, noteikums nedara to, ko jūs domājat.

Turiet tabulu, noteikumus un tuneļa maršruta darbības laiku pie viena īpašnieka, pārbaudiet atkārtotu savienojumu un tuneļa zudumu, un, izbeidzot politiku, noņemiet tikai tās precīzos ierakstus. Namespace joprojām ir pieejams, ja atsevišķas saskarnes un atsevišķs stāvoklis ir tas, kas jums patiešām vajadzīgs.

Saistītie raksti