La én OpenVPN-klient nå en annen med SSH uten å åpne bassenget

Én klient må nå SSH-tjenesten til en annen klient, og resten av bassenget bør holde seg like isolert som i dag. Den fristende bryteren er client-to-client, som slår på likemannstilgang for alle på én gang og gir avgjørelsen til OpenVPN i stedet for kjernen. Et smalere svar holder den bryteren av og lar rutingen og brannmuren til serveren selv bære nøyaktig én strøm.

Mekanismen teller mer enn teksten i regelen, fordi de to tilnærmingene setter pakken på ulike steder. Å vite hvilken du valgte forklarer både regelen som ser ut til å ikke gjøre noe, og likemannen som kobler til uten den.

Hvor client-to-client flytter pakken

Med client-to-client på sender serveren en likemannspakke videre internt i stedet for å sende den ut igjen gjennom tunneleenheten, slik at pakken aldri når videresendingsveien til kjernen. Det er praktisk, og det betyr også at brannmuren din aldri ser strømmen den skulle overvåke. La valget være av og serveren ruter pakken ut igjen gjennom samme grensesnitt, noe som setter den foran netfilter. Samme grensesnitt inn, samme grensesnitt ut, og FORWARD-kjeden får stemmen.

Byttet er tydelig: du vinner et politikkpunkt og tar på deg ruting- og videresendingsarbeidet som snarveien gjorde for deg. Det arbeidet er lite for én strøm og vokser med hvert unntak du legger til. Tell unntakene nå, fordi det er i regelsettet politikken mellom likemenn faktisk bor.

Veien en likemannspakke faktisk tar

Gå ut fra en Linux Community OpenVPN 2.6-tjeneste, TUN-behandling i brukerrom i stedet for DCO, subnett-topologi, tun0 og et basseng på 10.44.0.0/24 med klient A på 10.44.0.21 og klient B på 10.44.0.37. Med subnett-topologi dekker adressen og nettverksmasken som A fikk allerede bassenget, så A sender pakken til tunneleenheten uten en ekstra dyttet rute. Kontroller den effektive ruten på A i stedet for å gå ut fra én.

På serveren kommer pakken adressert til B, som ikke er en lokal adresse, så den sendes videre. IPv4-videresending må være på for at det i det hele tatt skal skje, og ruteoppslaget må sende pakken ut igjen gjennom tun0. Brannmuren ser derfor en videresendt strøm med samme grensesnitt på begge sider, og det er detaljen de fleste regelsett overser. Her trengs ingen kildeoversettelse, og det er nettopp det å holde adressen til A intakt som lar B bruke sin egen kildetbaserte regel.

To regler på serveren, i denne rekkefølgen

Tre regler bærer hele tillatelsen: videresending, unntaket for paret og et standard forkast for tunnelparet. Godtakelsesregelen nevner paret og tjenesten, så tillatelsen overlever et basseng som vokser. Sett den før enhver generell avvisning av tunnel-til-tunnel-trafikk, fordi det første treffet vinner:

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 kommandoene er illustrative og hører til i den mekanismen verten din bruker til å ta vare på regler; en innsetting ved kjøretid forsvinner ved neste oppstart. Det er den tilstandsfulle regelen som lar svarene til B og TCP-håndtrykket komme tilbake uten en andre, speilet godtakelse.

Kontroller tellerne etterpå i stedet for regellisten, fordi en regel som aldri treffer ser identisk ut med en som virker. Hvis tellerne blir stående på null, tar pakken ikke den veien du tror.

Hva B fortsatt må tillate

B kjører SSH-tjenesten, så B avgjør om noe lytter på tunneladressen og om den egne vertsbrannmuren godtar kilden. En nettverkstillatelse på serveren er ikke tillatelse for noen konto på B, og vertsnøkkelbekreftelse og brukerautentisering gjelder fortsatt som fra hvor som helst ellers.

Test det positive tilfellet først: en ny SSH-tilkobling fra A til tunneladressen til B, godtatt med den forventede vertsnøkkelen. Test deretter en annen likemann eller en annen port og bekreft at den avvises, fordi en tillatelse som stille tillater alt, ikke kan skilles fra en som virker før det gjelder. Begge halvdelene av den testen trengs, og den andre er den folk hopper over.

Skriv ned de tildelte adressene, de effektive rutene på begge klientene og de nøyaktige reglene på serveren og på B. En vellykket ping til gatewayen eller en åpen port på serveren beviser ingen av disse, siden begge kan være sanne mens videresending mellom likemenn fortsatt er blokkert. Skriv ned tallene mens tunnelen er oppe, fordi adressen en klient får etter en ny tilkobling kan være en annen.