Divi klienti var abi atvērt lēciena resursdatoru un tomēr nedrīkstēt atvērt viens otru. Sasniegt pakalpojumu ir pārsūtīšanas lēmums, bet sasniegt vienaudzi ir politikas lēmums, un lielākā daļa VPN steku tos glabā atsevišķos objektos. Nekas, ko konfigurējat pirmajam, neizpilda otro. Tāpēc uzdevums nav pievienot noteikumu, bet atrast objektu, kas šajā serverī nosaka vienaudžu datplūsmu, tur ierakstīt liegumu un pierādīt to no klienta.

Maršruts uz koplietoto pakalpojumu nav atļauja starp vienaudžiem

Klientu apakštīkla reklamēšana pasaka vienaudzim, kā likt paketi uz vada pretī cita klienta adresei. Vai šī pakete tiks piegādāta, tiek izlemts vēlāk, ar to, kas to pārsūta. Linux vārtejā tā ir FORWARD ķēde; lietotāja telpas dēmonā tā ir paša tuneļa sesiju tabula. Maršruts atbild uz sasniedzamību un atstāj atļauju neskartu.

Tāpēc izolācijas pārbaude, kas lasa tikai maršrutus, neko nepierāda. /24 var nosūtīt katram klientam, kamēr katra vienaudžu pakete tiek nomesta pārsūtīšanas āķī. Bīstamais gadījums ir pretējs: nav skaidra noteikuma, ir atļaujoša noklusējuma vērtība un izolācija, kas pastāv tikai tāpēc, ka neviens to nav pārbaudījis.

Pierakstiet prasību vienā rindā pirms termināļa atvēršanas. Sasniedziet pakalpojumu bloku un lēciena resursdatoru, klientu bloka iekšienē nesasniedziet neko citu.

Noskaidrojiet, kas patiešām pārsūta vienaudža paketi

Divas servera uzvedības no klienta puses izskatās vienādi un prasa atšķirīgus noteikumus. Vai nu kodols atkal pārsūta paketi ārpus tuneļa saskarnes, vai dēmons to kopē starp sesijām un kodols to nekad neredz.

WireGuard pieder pirmajai grupai: tam nav vienaudžu slēdža, tāpēc pakete no 10.8.0.4 uz 10.8.0.5 nonāk uz wg0, atsitas pret pārsūtīšanas āķi un atkal tiek maršrutēta ārpus wg0, kad AllowedIPs aptver abas adreses. OpenVPN ir otrā grupa, tiklīdz servera konfigurācijā ir iestatīts client-to-client, jo šī direktīva nodod paketi starp sesijām lietotāja telpā. Pirms kaut ko rakstāt, pārbaudiet ielādēto konfigurāciju attiecībā uz šo direktīvu. Kodola noteikumu, kas nekad neredz datplūsmu, nevar atšķirt no strādājoša noteikuma, un tieši tā izvietošana beidzas bez jebkādas izolācijas.

Lasiet faktisko konfigurāciju, nevis failu, ko uzskatāt par ielādētu, jo izplatīšanas pakotnes nodrošina savus iekļāvumus. Ja dēmons pārsūta, liegums pieder tā paša vadībai katram klientam, un resursdatora ugunsmūris filtrē tikai resursdatoram adresēto datplūsmu. Ja kodols pārsūta, pārsūtīšanas āķis ir vienīgā vieta, kas nozīmīga.

Maršrutētām un tulkotām izvietošanām vajadzīga vēl viena pārbaude: avots, ko redz tāls klients, var nebūt tas, ko gaidāt. Tad noteikums, kas atbilst klientu apakštīklam, neatbilst nekam. Pierakstiet adresi, kas izdzīvo tulkojumu, pirms rakstāt atbilstību, un dodiet priekšroku saskarņu pāra atbilstībai, nevis NAT adrešu minēšanai.

Piešķiriet katrai adresei patstāvīgi atsaucamu identitāti

Izolācija sabrūk, tiklīdz divas ierīces dala vienu akreditācijas datu kopu. Noteikums, kas piesaistīts šai identitātei, nevar tās atdalīt, un pazaudēta portatīvā datora atsaukšana atsauc visu grupu. Sertifikāti katrai ierīcei vai atslēgas katram vienaudzim notur atsaukšanu lokālu un politiku lasāmu, jo katra adrese atbilst tieši vienai personai vai mašīnai. Kur dizains to nevar, sakiet to ekspluatācijas rokasgrāmatā, nevis raksturojiet noteikumu kā smalkgraudainu.

Adrešu sadalei jāsaskan ar politiku. Rezervējiet bloku pakalpojumiem, bloku klientiem, un izdaliet klientu adreses no jūsu kontrolēta baseina, nevis no diapazona, kurā pirmais nāk, pirmais saņem. Ja serveris tulko vai tilto, turiet kartēšanas tabulu blakus konfigurācijai, jo tieši tā nākamajam lasītājam vajadzīga, lai no jauna atvasinātu noteikumu.

Novietojiet liegumu tur, kur pakete šķērso tuneli

Vārtejā, kas pārsūta WireGuard datplūsmu, gadījumu sedz divi noteikumi: atļaujiet pakalpojumu bloku, pēc tam nometiet pārējo klientu bloku. Saskarņu pāris ir tikpat svarīgs kā adreses, jo atbilstība tikai pēc galamērķa pārtver arī datplūsmu no LAN. Ielādējiet tos šādā secībā, lai atļauja tiktu novērtēta pirmā.

Ar nftables pāris nonāk esošajā inet filter tabulā, vispirms atļauja un pēc tam nomešana. Abas atbilstības piesprauž saskarņu pāri un adreses.

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

Pēc ielādes izlasiet ķēdi atpakaļ, nevis paļaujieties uz izejas statusu, un apstipriniet, ka abi noteikumi stāv paredzētajā secībā. Pievienojiet atbilstošus ip6 noteikumus IPv6 baseinam, citādi v4 pāris divkāršā steka tunelī ir tikai dekorācija. Ja serverim jau ir atļaujoša pārsūtīšanas politika, pievienojiet nomešanu, nevis aizstājiet visu ķēdi.

Kad OpenVPN ir iespējots client-to-client, šie pārsūtīšanas noteikumi nekad neatbilst vienaudžu datplūsmai un liegumam jādzīvo paša dēmona vadībā. Saglabājiet kodola noteikumus resursdatoram adresētajai datplūsmai, bet neuzskatiet tos par izolācijas vadību.

Pierādiet liegumu no klienta, nevis no servera

Testēšana no vārtejas neko nepierāda, jo lokāli ģenerētā datplūsma iet pa izejas ceļu un nekad nešķērso pārsūtīšanas āķi. Izmantojiet divus īstus klientus: vienu, kam jāsasniedz pakalpojums, un vienu, kas jānoraida. Vispirms palaidiet atļaujas gadījumu, lai bojāts tunelis netiktu uzskatīts par strādājošu politiku.

No atļautā klienta apstipriniet, ka pakalpojums atbild savā portā. No tā paša klienta izmēģiniet vienaudža adresi un gaidiet klusu nomešanu, nevis atteikumu:

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

Nomesta pakete un bezsaistes vienaudzis abi izskatās kā taimauts, tāpēc pirms secinājumiem pārbaudiet skaitītājus. Apstipriniet, ka nomešanas noteikuma skaitītājs pieaug, kamēr vienaudzis acīmredzami darbojas. Atkārtojiet ar IPv6, kur trūkstošs ip6 noteikums liek v4 liegumam izskatīties efektīvam. Ierakstiet pieņemtos un noraidītos rezultātus rokasgrāmatā ar datumu, jo nākamā migrācija noteikumu atkal atvasinās.

Saistītie raksti