Malhelpu, ke klientoj de VPN atingu unu la alian en la tunelo

Du klientoj povas ambaŭ malfermi la saltgastiganton kaj tamen havi neniun aferon malfermi unu la alian. Atingi servon estas plusenda decido, dum atingi kunulon estas decido de politiko, kaj plej multaj VPN-stakoj tenas tiujn en apartaj objektoj. Nenio, kion vi agordas por la unua, plenumas la duan. La tasko do ne estas aldoni regulon, sed trovi la objekton, kiu decidas la trafikon inter kunuloj sur ĉi tiu servilo, skribi la malpermeson tie, kaj pruvi ĝin el kliento.

Itinero al la komuna servo ne estas permeso inter kunuloj

Anonci la klientan subreton diras al kunulo, kiel meti paketon sur la draton al la adreso de alia kliento. Ĉu tiu paketo estos liverita, decidiĝas poste, per tio, kio plusendas ĝin. Sur Linuksa pordego tio estas la ĉeno FORWARD; ene de demono en uzantspaco tio estas la propra sesitabelo de la tunelo. Itinero respondas al atingeblo kaj lasas permeson netuŝita.

Tial izoltesto, kiu legas nur itinerojn, pruvas nenion. /24 povas esti puŝita al ĉiu kliento, dum ĉiu kunula paketo estas faligita ĉe la plusenda hoko. La danĝera kazo estas la mala: neniu eksplicita regulo, permesema defaŭlto, kaj izolo, kiu ekzistas nur ĉar neniu testis ĝin.

Skribu la postulon en unu linio antaŭ ol malfermi terminalon. Atingu la servan blokon kaj la saltgastiganton, atingi nenion alian ene de la klienta bloko.

Malkovru, kiu efektive plusendas la kunulan paketon

Du servilaj kondutoj aspektas samaj de la klienta flanko kaj postulas malsamajn regulojn. Aŭ la kerno plusendas la paketon denove el la tunela interfaco, aŭ la demono kopias ĝin inter sesioj kaj la kerno neniam vidas ĝin.

WireGuard apartenas al la unua grupo: ĝi havas neniun kunulan ŝaltilon, do paketo de 10.8.0.4 al 10.8.0.5 alvenas sur wg0, trafas la plusendan hokon kaj estas denove enkursigita el wg0, kiam AllowedIPs kovras ambaŭ adresojn. OpenVPN estas la dua grupo, kiam client-to-client estas agordita en la servila agordo, ĉar tiu direktivo transdonas la paketon inter sesioj en uzantspaco. Kontrolu la ŝarĝitan agordon por tiu direktivo antaŭ ol skribi ion ajn. Kernoregelo, kiu neniam vidas trafikon, ne distingiĝas de regulo, kiu funkcias, kaj tiel disfaldiĝo finiĝas tute sen izolo.

Legu la efektivan agordon anstataŭ la dosieron, kiun vi supozas ŝarĝita, ĉar distribuaĵoj alportas siajn proprajn inkludojn. Se la demono plusendas, la malpermeso apartenas al ĝiaj propraj per-klientaj regiloj, kaj gastiga fajroŝirmilo filtras nur trafikon adresitan al la gastigo. Se la kerno plusendas, la plusenda hoko estas la sola loko, kiu gravas.

Enkursigitaj kaj tradukitaj disfaldiĝoj bezonas ankoraŭ unu kontrolon: la fonto, kiun vidas fora kliento, eble ne estas tiu, kiun vi atendas. Tiam regulo kongruanta kun la klienta subreto kongruas kun nenio. Notu la adreson, kiu pluvivas la tradukon, antaŭ ol skribi la kongruon, kaj preferu kongruigi la interfacan paron anstataŭ diveni NAT-adresojn.

Donu al ĉiu adreso identecon, kiun oni povas revoki memstare

Izolo kolapsas tuj kiam du aparatoj kunhavas unu akreditaĵon. Regulo ligita al tiu identeco ne povas ilin apartigi, kaj revoko de perdita tekkomputilo revokas la tutan grupon. Atestiloj por aparato aŭ ŝlosiloj por kunulo tenas revokon loka kaj la politikon legebla, ĉar ĉiu adreso mapiĝas al precize unu persono aŭ maŝino. Kie la dezajno ne povas tion fari, diru tion en la runlibro anstataŭ priskribi la regulon kiel fajngrajna.

Adresa disdonado devas akordi kun la politiko. Rezervu blokon por servoj, blokon por klientoj, kaj disdonu klientajn adresojn el provizo, kiun vi kontrolas, anstataŭ el gamo laŭ unua-venas-unua-prenas. Se la servilo tradukas aŭ pontas, tenu la mapan tabelon apud la agordo, ĉar tiu tabelo estas tio, kion la sekva leganto bezonas por re-derivi la regulon.

Metu la malpermeson tie, kie la paketo transiras la tunelon

Sur pordego, kiu plusendas WireGuard-trafikon, du reguloj kovras la kazon: permesi la servan blokon, poste faligi la reston de la klienta bloko. La interfaca paro gravas tiom kiom la adresoj, ĉar kongruo nur laŭ celo kaptas ankaŭ trafikon venantan el la LAN. Ŝarĝu ilin en tiu ordo, por ke la permeso estu taksita unue.

Kun nftables la paro iras en ekzistantan inet filter-tabelon, permeso unue kaj faligo due. Ambaŭ kongruoj fiksas la interfacan paron same kiel la adresojn.

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

Legu la ĉenon reen post ŝarĝo anstataŭ fidi la elirstaton, kaj konfirmu, ke ambaŭ reguloj staras en la ordo, kiun vi intencis. Aldonu kongruajn ip6-regulojn por la IPv6-provizo, alie la v4-paro estas nur ornamaĵo sur duobla staka tunelo. Se la servilo jam havas permeseman plusendan politikon, aldonu la faligon anstataŭ anstataŭigi la tutan ĉenon.

Kiam client-to-client estas ŝaltita sur OpenVPN, ĉi tiuj plusendaj reguloj neniam kongruas kun kunula trafiko kaj la malpermeso devas vivi en la propraj regiloj de la demono. Tenu la kernoregulojn por trafiko adresita al la gastigo, sed ne kalkulu ilin kiel la izolilon.

Pruvu la malpermeson el kliento, ne el la servilo

Testado el la pordego pruvas nenion, ĉar loke generita trafiko prenas la eliran vojon kaj neniam transiras la plusendan hokon. Uzu du verajn klientojn: unu, kiu devus atingi la servon, unu, kiu devus esti rifuzita. Rulu la permesan kazon unue, por ke rompita tunelo ne estu konfuzita kun funkcianta politiko.

El la permesita kliento, konfirmu, ke la servo respondas sur sia pordo. El la sama kliento, provu la kunulan adreson kaj atendu silentan faligon anstataŭ rifuzo:

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

Faligita paketo kaj eksterreta kunulo ambaŭ aspektas kiel templimo, do kontrolu la nombrilojn antaŭ ol konkludi ion. Konfirmu, ke la nombrilo de la faliga regulo kreskas dum la kunulo estas pruveble funkcianta. Ripetu tra IPv6, kie mankanta ip6-regulo lasas la v4-malpermeson aspekti efika. Registru la akceptitajn kaj rifuzitajn rezultojn en la runlibro kun la dato, ĉar la sekva migrado re-derivos la regulon.