Lad én OpenVPN-klient SSH til en anden uden at åbne puljen

Én klient skal nå en anden klients SSH-tjeneste, og resten af puljen bør forblive lige så isoleret som i dag. Den fristende kontakt er client-to-client, som slår ligeværdig adgang til for alle på én gang og giver beslutningen til OpenVPN i stedet for kernen. Et snævrere svar holder den kontakt slået fra og lader serverens egen routing og firewall bære præcis én strøm.

Mekanismen betyder mere end reglens tekst, fordi de to tilgange placerer pakken forskellige steder. At vide, hvilken du valgte, forklarer både den regel, der ser ud til ikke at gøre noget, og den peer, der forbinder uden den.

Hvor client-to-client flytter pakken

Med client-to-client slået til videresender serveren en peer-pakke internt i stedet for at sende den ud igen gennem tunneleenheden, så pakken når aldrig kernens videresendelsessti. Det er bekvemt, og det betyder også, at din firewall aldrig ser den strøm, den skulle overvåge. Lad indstillingen være slået fra, og serveren ruter pakken ud igen gennem samme interface, hvilket sætter den foran netfilter. Samme interface ind, samme interface ud, og FORWARD-kæden får stemmen.

Byttehandlen er eksplicit: du får et politikpunkt, og du overtager det routing- og videresendelsesarbejde, som genvejen gjorde for dig. Det arbejde er lille for én strøm og vokser med hver undtagelse, du tilføjer. Tæl undtagelserne nu, fordi regelsættet er der, hvor peer-politikken faktisk bor.

Den vej, en peer-pakke faktisk tager

Antag en Linux Community OpenVPN 2.6-tjeneste, userspace-TUN-behandling i stedet for DCO, subnet-topologi, tun0 og en pulje på 10.44.0.0/24 med klient A på 10.44.0.21 og klient B på 10.44.0.37. Med subnet-topologi dækker den adresse og netmaske, A modtog, allerede puljen, så A sender pakken til tunneleenheden uden behov for en ekstra skubbet rute. Kontroller den effektive rute på A i stedet for at antage en.

På serveren ankommer pakken adresseret til B, som ikke er en lokal adresse, så den videresendes. IPv4-videresendelse skal være slået til, for at det overhovedet kan ske, og ruteopslaget skal sende pakken ud igen gennem tun0. Firewallen ser derfor en videresendt strøm med samme interface på begge sider, og det er den detalje, de fleste regelsæt overser. Intet kræver kildeoversættelse her, og det er ved at holde A's adresse intakt, at B kan anvende sin egen kildbaserede regel.

To regler på serveren, i denne rækkefølge

Tre regler bærer hele tilladelsen: videresendelse, par-undtagelsen og et standard-drop for tunnelparet. Accept-reglen navngiver parret og tjenesten, så tilladelsen overlever en pulje, der vokser. Placer den før enhver blanket afvisning af tunnel-til-tunnel-trafik, fordi det første match vinder:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

De kommandoer er illustrative og hører til i den mekanisme, din vært bruger til at bevare regler; et runtime-indskud forsvinder ved næste opstart. Den stateful regel er det, der lader B's svar og TCP-håndtrykket vende tilbage uden en anden, spejlet accept.

Kontroller tællerne bagefter i stedet for regellisten, fordi en regel, der aldrig matches, ser identisk ud med en, der virker. Hvis tællerne bliver på nul, tager pakken ikke den vej, du tror.

Hvad B stadig skal tillade

B kører SSH-tjenesten, så B afgør, om noget lytter på tunneladressen, og om dens egen vært-firewall accepterer kilden. En netværkstilladelse på serveren er ikke tilladelse for nogen konto på B, og værtsnøgleverifikation og brugerautentificering gælder stadig som fra alle andre steder.

Test det positive tilfælde først: en frisk SSH-forbindelse fra A til B's tunneladresse, accepteret med den forventede værtsnøgle. Test derefter en anden peer eller en anden port og bekræft, at den afvises, fordi en tilladelse, der stiltiende tillader alt, ikke kan skelnes fra en, der virker, før det betyder noget. Begge halvdele af den test er nødvendige, og den anden er den, folk springer over.

Skriv de tildelte adresser, de effektive ruter på begge klienter og de nøjagtige regler på serveren og på B ned. Et vellykket ping til gatewayen eller en åben port på serveren beviser intet af dette, da begge kan være sande, mens peer-videresendelse stadig er blokeret. Skriv de tal ned, mens tunnelen er oppe, fordi den adresse, en klient får efter en genopkobling, kan være en anden.