Preprečite, da bi se odjemalci VPN v tunelu dosegali med seboj

Dva odjemalca lahko oba odpreta skakalnega gostitelja in vendar nimata nič opraviti z odpiranjem drug drugega. Doseči storitev je odločitev o posredovanju, medtem ko je doseči partnerja odločitev politike, in večina skladov VPN jih hrani v ločenih objektih. Nič, kar nastavite za prvo, ne uveljavi drugega. Naloga torej ni dodati pravilo, ampak najti objekt, ki na tem strežniku odloča o prometu med partnerji, tam zapisati zavrnitev in jo dokazati z odjemalca.

Pot do skupne storitve ni dovoljenje med partnerji

Oglaševanje odjemalskega podomrežja pove partnerju, kako položiti paket na žico proti naslovu drugega odjemalca. Ali bo paket dostavljen, se odloči pozneje, po tistem, kar ga posreduje. Na prehodu Linux je to veriga FORWARD; v demonu v uporabniškem prostoru je to lastna tabela sej tunela. Pot odgovori na dosegljivost in dovoljenje pusti nedotaknjeno.

Zato preverjanje izolacije, ki bere le poti, ničesar ne dokaže. /24 je mogoče potisniti vsakemu odjemalcu, medtem ko se vsak paket med partnerji zavrže na kavlju posredovanja. Nevaren je obraten primer: nobenega izrecnega pravila, dovoljujoča privzeta nastavitev in izolacija, ki obstaja le zato, ker je nihče ni preizkusil.

Zahtevo zapišite v eno vrstico, preden odprete terminal. Dosezite blok storitev in skakalnega gostitelja, ne dosezite ničesar drugega znotraj bloka odjemalcev.

Ugotovite, kdo paket partnerja v resnici posreduje

Dve vedenji strežnika sta z odjemalčeve strani videti enaki in zahtevata različna pravila. Bodisi jedro paket znova posreduje iz vmesnika tunela, bodisi ga demon kopira med sejami in jedro ga nikoli ne vidi.

WireGuard sodi v prvo skupino: nima stikala med partnerji, zato paket od 10.8.0.4 do 10.8.0.5 prispe na wg0, zadene kavelj posredovanja in se znova usmeri iz wg0, ko AllowedIPs pokriva oba naslova. OpenVPN je druga skupina, ko je v konfiguraciji strežnika nastavljen client-to-client, ker ta direktiva preda paket med sejami v uporabniškem prostoru. Preden kar koli napišete, preverite naloženo konfiguracijo za to direktivo. Pravila jedra, ki nikoli ne vidi prometa, ni mogoče ločiti od delujočega pravila, in tako se uvedba konča povsem brez izolacije.

Berite dejansko konfiguracijo, ne datoteke, za katero domnevate, da je naložena, ker distribucijski paketi prinašajo svoje vključitve. Če posreduje demon, zavrnitev spada v njegove lastne kontrole na odjemalca, požarni zid gostitelja pa filtrira le promet, naslovljen na gostitelja. Če posreduje jedro, je kavelj posredovanja edino mesto, ki šteje.

Usmerjene in prevedene uvedbe potrebujejo še eno preverjanje: vir, ki ga vidi oddaljeni odjemalec, morda ni tisti, ki ga pričakujete. Takrat pravilo, ki se ujema s podomrežjem odjemalcev, ne ustreza ničemur. Zapišite naslov, ki preživi prevod, preden napišete ujemanje, in raje uskladite par vmesnikov kot ugibate naslove NAT.

Vsakemu naslovu dajte samostojno preklicljivo identiteto

Izolacija se zruši takoj, ko si dve napravi delita eno poverilnico. Pravilo, vezano na to identiteto, ju ne more ločiti, preklic izgubljenega prenosnika pa prekliče celo skupino. Potrdila na napravo ali ključi na partnerja ohranjajo preklic lokalni in politiko berljivo, ker vsak naslov ustreza natanko eni osebi ali stroju. Kjer zasnova tega ne zmore, povejte to v priročniku, namesto da bi pravilo opisovali kot drobnozrnato.

Dodeljevanje naslovov se mora ujemati s politiko. Rezervirajte blok za storitve, blok za odjemalce, in delite odjemalske naslove iz nabora, ki ga nadzirate, ne iz obsega prvi-pride-prvi-dobi. Če strežnik prevaja ali mosti, imejte preslikovalno tabelo ob konfiguraciji, ker to tabelo potrebuje naslednji bralec, da znova izpelje pravilo.

Zavrnitev postavite tja, kjer paket prečka tunel

Na prehodu, ki posreduje promet WireGuard, primer pokrijeta dve pravili: dovolite blok storitev, nato zavrzite preostanek bloka odjemalcev. Par vmesnikov šteje toliko kot naslovi, ker ujemanje le po cilju ujame tudi promet iz LAN. Naložite ju v tem vrstnem redu, da se dovoljenje oceni prvo.

Z nftables par vstopi v obstoječo tabelo inet filter, najprej dovoljenje in nato zavrženje. Obe ujemanji pripmeta par vmesnikov in naslove.

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

Po nalaganju preberite verigo nazaj, namesto da zaupate izhodnemu stanju, in potrdite, da obe pravili stojita v predvidenem vrstnem redu. Dodajte ustrezna pravila ip6 za nabor IPv6, sicer je par v4 na dvosklopnem tunelu le okras. Če ima strežnik že dovoljujočo politiko posredovanja, dodajte zavrženje, namesto da bi verigo v celoti zamenjali.

Ko je na OpenVPN omogočen client-to-client, se ta pravila posredovanja nikoli ne ujemajo s prometom med partnerji in zavrnitev mora živeti v lastnih kontrolah demona. Ohranite pravila jedra za promet, naslovljen na gostitelja, a jih ne štejte kot kontrolo izolacije.

Dokažite zavrnitev z odjemalca, ne s strežnika

Preizkušanje s prehoda ne dokaže ničesar, ker lokalno ustvarjen promet ubere izhodno pot in nikoli ne prečka kavlja posredovanja. Uporabite dva resnična odjemalca: enega, ki bi moral doseči storitev, in enega, ki bi moral biti zavrnjen. Najprej zaženite primer dovoljenja, da se pokvarjen tunel ne zamenja s politiko, ki deluje.

Z dovoljenega odjemalca potrdite, da se storitev odziva na svojih vratih. Z istega odjemalca poskusite naslov partnerja in pričakujte tiho zavrženje namesto zavrnitve:

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

Zavržen paket in partner brez povezave sta videti kot potek časa, zato preverite števce, preden kaj sklepate. Potrdite, da števec pravila zavrženja narašča, medtem ko je partner dokazljivo dosegljiv. Ponovite prek IPv6, kjer manjkajoče pravilo ip6 pusti zavrnitev v4 videti učinkovito. Zapišite sprejete in zavrnjene izide v priročnik z datumom, ker bo naslednja selitev pravilo znova izpeljala.