Kāpēc jūsu iptables noteikums nekad neredz VPN datplūsmu pāri tiltam

Divas virtuālās mašīnas vienā saimniekā sasniedz LAN pāri tiltam, un noteikums, kas ievietots ip forward ķēdē, rāda skaitītāju, kas nekad nekustas. Kadri ir īsti, datplūsma iet, un noteikums vienkārši nav tās ceļā. Divu veidu, kā Linux parāda datplūsmu pāri tiltam, salīdzinājums izskaidro šo klusumu, un tas arī izskaidro, kāpēc viena veca moduļa ielāde ir sliktāka atbilde, nekā izskatās.

Divi ceļi caur vienu saimnieku

Pakete var atstāt šo saimnieku divos ļoti atšķirīgos veidos, un starpība nosaka, kuri āķi to redzēs. Ja galamērķis atrodas aiz fiziskas ostas un kadrs tiek pārslēgts starp divām tilta ostām, saimnieks pārsūta Ethernet kadru; maršrutēšanas kods netiek jautāts, un nenotiek neviens maršrutēts lēciens. Ja galamērķis ir pats saimnieks vai tīkls, kas sasniegts caur tuneļa saskarni, pakete tiek maršrutēta un IP slāņa āķi patiešām darbojas. Paturiet šo sazarojumu prātā, jo katrs vēlākais jautājums par ķēdēm un saimēm izriet no tā, kuru no diviem ceļiem kadrs izvēlas.

Šī atšķirība ir viss stāsts aiz noteikuma, kas neko neskaita. Kadrs pāri tiltam no veth9a1 uz enp3s0 šķērso tiltu, nevis IP steku, tāpēc ip forward ķēde neredz neko, ar ko saskaņot. Saskarņu nosaukumi vecākā piemērā nenosaka, kurš ceļš jums ir, un tāpēc pirmais solis ir skatīties uz topoloģiju, nevis uz noteikumu kopu.

Tunelis pievieno trešo gadījumu, kas ir pelnījis nosaukumu. TUN ierīce piegādā IP paketes saimniekam, tāpēc tās tiek maršrutētas un patiešām iet caur IP ķēdēm, bet tiltam pievienota TAP ierīce piegādā kadrus un uzvedas kā tilta gadījums. Izšķir ierīces tips, nevis produkta nosaukums.

Salīdziniet abas saimes, kas var redzēt kadru pāri tiltam

Linux atbalsta vietējo tilta filtrēšanu caur nftables bridge saimi, un tam nav vajadzīgs neviens vecs modulis, lai lidinā kadrus pārbaudītu un nomestu. Paša kodola tilta dokumentācija sniedz šo ieteikumu tieši, ko ir vērts zināt, pirms meklēšanas rezultāts liek jums ielādēt moduli.

Izmantojot nft komandu iptables vietā, noteikums pats par sevi neietilpst pareizajā saimē. Bridge saimē deklarētā ķēde redz kadrus; ip, ip6 vai inet deklarētā ķēde tos neredz, lai kura binārā datne to būtu radījusi. Saime ir ķēdes īpašība, nevis rīka, kas to ierakstīja.

Vecais ceļš darbojas savādāk, un tieši tāpēc ir vērts salīdzināt, nevis izvēlēties pusi pēc ieraduma. Ielādējot br_netfilter un iespējojot bridge-nf-call iestatījumus, datplūsma pāri tiltam IPv4 un IPv6 atkal tiek parādīta caur IP slāņa āķiem, tāpēc parasts iptables noteikums beidzot var ar to saskaņoties. Kadri nemainās; mainās āķu kopa, caur kuriem tie iet, kas nozīmē, ka katram esošajam saimnieka noteikumam tagad ir jauna auditorija.

Izlasiet faktisko ceļu, pirms pievienojat noteikumu

Trīs komandas nosaka, kur jūs atrodaties: kam tilts ir pievienots, vai vecais modulis ir aktīvs un kādas ķēdes bridge saimē jau pastāv. Palaidiet tās, pirms kaut ko rakstāt, jo atbilde nosaka, kuru no diviem dizainiem jūs paplašināt. Šī soļa izlaišana ir veids, kā pareizs noteikums nonāk ķēdē, caur kuru nekas neiet.

bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"

Izvade gadījumus šķir tīri. Ostas, kas uzskaitītas zem tilta, pasaka, kuras saskarnes tiek pārslēgtas; tukšs lsmod rezultāts nozīmē nekādu IP slāņa redzamību kadriem pāri tiltam; esoša bridge saimes forward ķēde nozīmē, ka politikas īpašnieks jau ir un jūsu noteikums pieder tur, nevis jaunā savā ķēdē.

Pēc tam pievienojiet vienu viegli nolasāmu noteikumu ar skaitītāju un nemainot spriedumu, un lai caur tiltu iet viens reprezentatīvs datplūsmas vilnis. Kustošs skaitītājs pierāda, ka kadrs sasniedza noteikumu. Tas ir viss, ko tas pierāda, tāpēc sekojiet tam arī ar noraidīto ceļu, jo politika, kas pieņem visu, arī rada kustošu skaitītāju.

nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter accept

Kur vecais modulis maina uzvedību

Vecā ceļa iespējošana darbojošā tiltā nav neitrāla redzamības pievienošanas darbība. Noteikumi, kas iepriekš bija nesasniedzami datplūsmai pāri tiltam, kļūst sasniedzami, tostarp saimnieka noteikumi, kas rakstīti citai saskarnei, un noklusējuma drop politika ip forward ķēdē var pēkšņi attiekties uz kadriem, kas agrāk gāja garām neskarti. Saimniekā, ko pārvalda caur šo tiltu, rezultāts ir bloķēšanās bez konsoles. Tas nav hipotētisks atteices režīms; tā ir parastā sekas, paplašinot āķu kopu mašīnā, kurai jūs piekļūstat pa tikko paplašināto ceļu.

Drošākā secība ir izlemt, kura saime pārvalda politiku, tur rakstīt noteikumus un saglabāt neatkarīgu atkopšanas ceļu, pirms maināt jebkuru sysctl. Ja divas saimes tur noteikumus, dokumentējiet, kura ir autoritatīvā; divas pārklājošās politikas ir veids, kā pakete tiek pieņemta vienā vietā un nomesta citā, bez neviena faila, ko izlasīt.

Izolācija pati par sevi joprojām prasa pilnu dizainu. Atļaušana vienam avotam sasniegt vienu galamērķi pierāda tikai to, ka viena datplūsma darbojas, bet prasība parasti ir tāda, ka VM nevar sasniegt savus kaimiņus vai saimnieku. Skaitītāji noraidīšanas noteikumos ir svarīgāki par skaitītāju pieņemšanas noteikumā, jo pieņemšanas skaitītājs ir tas, kura kustību jūs jau gaidījāt.

Visbeidzot, turiet saimnieka ievades gadījumu atsevišķi. Datplūsma, kas adresēta paša tilta IP, nonāk input, nevis forward, un noteikums forward ķēdē to nekad neredzēs, lai kuru saimi jūs izvēlētos. Trīs gadījumi, divas saimes, viena mācība: ceļš nosaka āķi, un āķis nosaka, vai jūsu noteikums vispār pastāv.