Stopp VPN-klientar frå å nå kvarandre på tunnelen

To klientar kan begge opne hoppverten og likevel ikkje ha noko å gjere med å opne kvarandre. Å nå ein teneste er ei videresendingsavgjerd, medan å nå ein peer er ei policyavgjerd, og dei fleste VPN-stakkar held dei i separate objekt. Ingenting du konfigurerer for det første handhevar det andre. Oppgåva er derfor ikkje å leggje til ei regel, men å finne objektet som avgjer peer-trafikken på denne serveren, skrive avvisinga der og prove ho frå ein klient.

Ei rute til den delte tenesta er ikkje ei løyve mellom peerar

Å annonsere klientundernettet fortel ein peer korleis han skal setje ein pakke på leidningen mot adressa til ein annan klient. Om pakken blir levert blir avgjort etterpå, av det som videresender han. På ein Linux-gateway er det FORWARD-kjeda; inne i ein daemon i brukarrommet er det den eigne sesjonstabellen til tunnelen. Ei rute svarar på tilgjenge og lèt løyvet vere urørt.

Derfor provar ein isolasjonskontroll som berre les ruter ingenting. Eit /24 kan skyvast til kvar klient medan kvar peer-til-peer-pakke blir droppa ved forward-kroken. Det farlege tilfellet er det motsette: inga uttrykkeleg regel, ein ettergjevande standard, og isolasjon som berre finst fordi ingen har testa han.

Skriv kravet på éi line før du opnar ein terminal. Nå tenesteblokken og hoppverten, nå ingenting anna inne i klientblokken.

Finn ut kven som faktisk videresender peer-pakken

To serveråtferder ser like ut frå klientsida og krev ulike reglar. Anten videresender kjernen pakken ut av tunellgrensesnittet igjen, eller daemonen kopierer han mellom sesjonar og kjernen ser han aldri.

WireGuard høyrer til den første gruppa: det har ingen peer-til-peer-brytar, så ein pakke frå 10.8.0.4 til 10.8.0.5 kjem inn på wg0, treffer forward-kroken og blir ruta ut av wg0 igjen når AllowedIPs dekkjer begge adressene. OpenVPN er den andre gruppa når client-to-client er sett i serverkonfigurasjonen, fordi den direktivet overleverer pakken mellom sesjonar i brukarrommet. Sjekk den innlesne konfigurasjonen for den direktivet før du skriv noko. Ein kjerneregel som aldri ser trafikk kan ikkje skiljast frå ein regel som verkar, og slik endar ein utrulling heilt utan isolasjon.

Les den effektive konfigurasjonen i staden for fila du antek er lasta, fordi distribusjonspakkar leverer sine eigne inkluderingar. Viss daemonen videresender, høyrer avvisinga til i hans eigne per-klient-kontrollar, og ein vertsbrannmur filtrerer berre trafikk adressert til verten. Viss kjernen videresender, er forward-kroken det einaste staden som tel.

Ruta og omsette utrullingar treng ein sjekk til: kjelda ein fjern klient ser er kanskje ikkje den du ventar. Då passar ein regel som passar klientundernettet ikkje med noko. Noter adressa som overlever omsetjinga før du skriv treffet, og føretrekk å matche grensesnittparet framfor å gjette på NAT-adresser.

Gje kvar adresse ein identitet du kan kalle tilbake åleine

Isolasjonen bryt saman så snart to einingar deler éin legitimasjon. Ein regel knytt til den identiteten kan ikkje skilje dei, og tilbakekalling av ein mista berbar PC kallar tilbake heile gruppa. Sertifikat per eining eller nøklar per peer held tilbakekallinga lokal og policyen lesbar, fordi kvar adresse svarar til nøyaktig éin person eller maskin. Der designet ikkje kan gjere det, seie det i runboka i staden for å skildre regelen som finkorna.

Adressetildeling må stemme med policyen. Reserver ein blokk til tenester, ein blokk til klientar, og del ut klientadresser frå ein pool du kontrollerer i staden for eit område etter fyrstemann-til-mølla. Viss serveren omset eller bruar, hald mappingstabellen ved sida av konfigurasjonen, fordi den tabellen er det neste lesar treng for å leie ut regelen på nytt.

Plasser avvisinga der pakken kryssar tunnelen

På ein gateway som videresender WireGuard-trafikk, dekkjer to reglar tilfellet: tillat tenesteblokken, og dropp deretter resten av klientblokken. Grensesnittparet tyder like mykje som adressene, fordi treff berre på mål også fangar trafikk som kjem frå LAN. Last dei i den rekkjefølgja slik at løyvet blir vurdert først.

Med nftables går paret inn i ein eksisterande inet filter-tabell, løyve først og dropp deretter. Begge treffa festar grensesnittparet så vel som adressene.

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

Les kjeda tilbake etter lasting i staden for å stole på utgangsstatusen, og stadfest at begge reglane står i den rekkjefølgja du meinte. Legg til treffande ip6-reglar for IPv6-poolen, elles er v4-paret berre dekorasjon på ein dual-stack-tunnel. Viss serveren alt har ein ettergjevande forward-policy, legg til droppet i staden for å bytte ut kjeda heilt.

Når client-to-client er aktivert på OpenVPN, treff desse forward-reglane aldri peer-trafikk, og avvisinga må liggje i daemonen sine eigne kontrollar. Hald kjernereglane for trafikk adressert til verten, men rekn dei ikkje som isolasjonskontrollen.

Prov avvisinga frå ein klient, ikkje frå serveren

Testing frå gatewayen provar ingenting, fordi lokalt generert trafikk tek utgangsstien og kryssar aldri forward-kroken. Bruk to ekte klientar: éin som skal nå tenesta, éin som skal bli avvist. Køyr løyvetilfellet først, slik at ein broten tunnel ikkje blir forveksla med ein policy som verkar.

Frå den tillatne klienten, stadfest at tenesta svarar på porten sin. Frå same klient, prøv peer-adressa og vent eit stille dropp i staden for ei avvising:

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

Ein droppa pakke og ein offline peer ser begge ut som ein tidsavbrot, så sjekk teljarane før du konkluderer noko. Stadfest at teljaren for droppregelen aukar medan peeren er provande oppe. Gjenta over IPv6, der ein manglande ip6-regel får v4-avvisinga til å sjå effektiv ut. Noter dei aksepterte og avviste resultata i runboka med dato, fordi neste migrering vil leie ut regelen på nytt.