Vietējā lietotne, VPN noteikums: kāpēc jūsu FORWARD ķēde nekad neiedarbojas
Procesi iekārtā izmanto OUTPUT, nevis FORWARD. Izvēlieties āķi pareizajā nosaukumtelpā un pēc tam izlemiet, vai pietiek ar atzīmi vai vienkāršu maršrutu.
Jūs pievienojat noteikumu VPN trafikam FORWARD ķēdē, palaižat pieprasījumu no tās pašas Linux iekārtas, un skaitītājs paliek uz nulles. Noteikums, visticamāk, ir pareizs. Pakete nekad nav gājusi pa šo ceļu, jo iekārtā pašā radītu pieprasījumu tā nepārsūta. Paketes dzīves izsekošana no ligzdas līdz vadam izskaidro, kāpēc tā notiek un kur noteikumam īstenībā jāatrodas.
Noskaidrojiet, kur pakete piedzima
Netfilter āķu secība atdala trīs gadījumus, un tikai viens no tiem ietver FORWARD:
| Origin | Path | Hook that sees it |
|---|---|---|
| Local process | OUTPUT then POSTROUTING | OUTPUT, POSTROUTING |
| Addressed to a local service | PREROUTING then INPUT | PREROUTING, INPUT |
| Received for another host | PREROUTING, FORWARD, POSTROUTING | FORWARD |
Vietējā lietotne sākas OUTPUT ceļā, jo kodols jau ir noteicis, ka pakete rodas šeit un nekad nav pārsūtīšanas kandidāts. Tunelis šo klasifikāciju nemaina; tunelis ir ierīce, pa kuru pakete var iziet, nevis posms, kas vietējo izvadi pārvērš tranzītā.
Divas paketes, viens stāsts
Kad tunelis ir pacelts, lietotnes iekšējā pakete un šifrētā ārējā pakete ir dažādi objekti. Iekšējā pakete nes to galamērķi un kravu, ko izvēlējās lietotne. Ārējā pakete nes šifrtekstu uz partnera adresi un portu, un tieši tā faktiski šķērso fizisko interfeisu.
Jūsu politika attiecas uz vienu no tām, un nepareizās izvēle ir biežs iemesls, kāpēc noteikums šķietami neko nedara. Noteikums, kas atbilst partnera ārējai adresei, redz katru tuneļa paketi vienādi, lai ko darītu iekšējā lietotne. Noteikums, kas atbilst iekšējam galamērķim, redz trafiku, kas jums svarīgs, un tas iedarbosies tikai tad, kad šī pakete sasniegs āķi, uz kura jūs noteikumu uzstādījāt.
Nosaukumtelpas pārvieto robežu
Konteiners to padara grūtāku, nemainot principu. Lietotnes pieprasījums ir vietējā izvade konteinera tīkla nosaukumtelpā. Resursdators šo trafiku saņem uz virtuāla Ethernet interfeisa un var to pārsūtīt, tāpēc FORWARD noteikums resursdatorā var būt jēgpilns, lai gan process, kas radīja pieprasījumu, nekad nav aizticis resursdatora OUTPUT ķēdi.
Pirms izvēlēties āķi, noskaidrojiet, kur īstenībā dzīvo noteikumu kopa un tunelis. Tunelis konteinera iekšienē, tunelis resursdatorā ar konteineru maršrutētu caur to un tunelis atsevišķā nosaukumtelpā ir trīs dažādas topoloģijas ar trim dažādām noteikumu vietām. Lasiet noteikumus tajā nosaukumtelpā, kurai pieder ierīce, nevis tikai noklusējuma.
Jautājiet, vai atzīme vispār ir vajadzīga
Ja mērķis ir sūtīt vienu galamērķa prefiksu pa tuneli, ar maršrutu šim prefiksam var pietikt. Vispirms pārbaudiet spēkā esošos maršrutus, ieskaitot visu, ko serveris ir iespiedis: novirzīts noklusējuma maršruts sūta pa VPN daudz vairāk trafika nekā šaurā politika, ko bijāt iecerējis, un neviens atzīmēšanas apjoms rezultātu nesaskaņos ar nodomu.
Klasifikācija vajadzīga, kad lēmums ir atkarīgs no kaut kā, ko maršruts nevar izteikt, piemēram, avota, lietotāja vai procesa. Saņemtajam trafikam atzīmēšana PREROUTING darbojas. Vietējam trafikam atzīmēšanai jānotiek izvades posmā, kas pēc atzīmes uzstādīšanas var izraisīt jaunu maršruta meklēšanu. Ar nftables tas ir route tipa ķēde izvades āķī; parasta izvades filtra ķēde uzstādīs vērtību un atstās maršrutu nemainītu.
Ar iptables ekvivalents dzīvo mangle OUTPUT izkārtojumā, un attiecas tā pati prasība: maršrutēšanas lēmums ir jāpārskata pēc tam, kad atzīme pastāv. Tad politikas noteikumam jāpatērē atzīme un jānorāda uz tabulu, kurā ir lietojams maršruts. Conntrack atzīmes uzstādīšana ir trešā, atsevišķā darbība; tā glabā vērtību plūsmā un pati par sevi neliek šo vērtību uz pašreizējās paketes, lai maršrutēšana to nolasītu.
Pārbaudiet meklēšanu un skaitītāju kopā
nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1
Adrese un atzīme ir ilustratīvas, un divi maršruta vaicājumi atbild uz dažādiem jautājumiem. Otrais jautā, ko kodols darītu, ja paketei būtu šī atzīme; tas neparāda, ka jūsu noteikumu kopa kādu piešķir. Uztveriet to kā hipotēzes pārbaudi, nevis kā pierādījumu, ka politika darbojas.
Pēc tam palaidiet nekaitīgu pieprasījumu un vērojiet divas lietas vienlaikus: skaitītāju uz izvēlētā āķa un izeju, kuru pakete faktiski izvēlējās. Ja skaitītājs kustas un pakete iziet citur, atzīme vai tabula ir nepareiza. Ja nekustas neviens, pakete nemaz nesasniedz šo āķi, un nākamais jautājums ir nosaukumtelpa vai ceļš.
Visbeidzot, ierobežojiet testu ar to, ko mehānisms spēj izteikt. Viens maršruts vienai adresei nekļūst par pastāvīgu politiku servisam, kura adreses mainās. Vispirms izlemiet pakešu tvērumu, pēc tam pārbaudiet, vai maršrutēšanas un atzīmēšanas dizains spēj saglabāt šo tvērumu pēc atkārtota savienojuma.