Éin klient må nå SSH-tenesta til ein annan klient, og resten av bassenget bør halde seg like isolert som i dag. Den freistande brytaren er client-to-client, som slår på likemannstilgang for alle på ein gong og gjev avgjerda til OpenVPN i staden for kjernen. Eit trongare svar held den brytaren av og lèt rutings- og brannmuren til tenaren bera nøyaktig éin straum.

Mekanismen tel meir enn teksten i regelen, fordi dei to måtane set pakken på ulike stader. Å vite kva for ein du valde forklarer både regelen som ser ut til å ikkje gjere noko, og likemannen som koplar til utan han.

Kvar client-to-client flyttar pakken

Med client-to-client på sender tenaren ein likemannspakke vidare internt i staden for å senda han ut att gjennom tunneleininga, slik at pakken aldri når videresendingsvegen til kjernen. Det er praktisk, og det tyder òg at brannmuren din aldri ser straumen han skulle overvake. Lat valet vere av og tenaren rutar pakken ut att gjennom same grensesnitt, noko som set han framfor netfilter. Same grensesnitt inn, same grensesnitt ut, og FORWARD-kjeda får røysta.

Bytet er tydeleg: du vinn eit politikkpunkt og tek på deg rutings- og videresendingsarbeidet som snarvegen gjorde for deg. Det arbeidet er lite for éin straum og veks med kvar eit nytt unntak du legg til. Tel unntaka no, fordi det er i regelverket at politikken mellom likemenn faktisk bur.

Vegen ein likemannspakke faktisk tek

Gå ut frå ein Linux Community OpenVPN 2.6-teneste, TUN-handsaming i brukarrom i staden for DCO, subnett-topologi, tun0 og eit 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 dekkjer adressa og nettmasken som A fekk allereie bassenget, så A sender pakken til tunneleininga utan ei ekstra dytta rute. Kontroller den effektive ruta på A i staden for å gå ut frå éi.

På tenaren kjem pakken adressert til B, som ikkje er ei lokal adresse, så han vert send vidare. IPv4-videresending må vere på for at det i det heile skal skje, og ruteoppslaget må senda pakken ut att gjennom tun0. Brannmuren ser difor ein videresend straum med same grensesnitt på begge sider, og det er detaljen dei fleste regelverk overser. Her trengst inga kjeldeomsetjing, og det er nettopp det å halde adressa til A intakt som lèt B bruke sin eigen kjeldebaserte regel.

To reglar på tenaren, i denne rekkjefølgja

Tre reglar ber heile løyvet: videresending, unntaket for paret og eit standard forkast for tunnelparet. Godtaksregelen nemner paret og tenesta, så løyvet overlever eit basseng som veks. Set han før kva som helst generell avvising av tunnel-til-tunnel-trafikk, fordi det første treffet vinn:

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

Dei kommandoane er illustrative og høyrer til i den mekanismen verten din brukar til å ta vare på reglar; ein innsetting ved køyretid forsvinn ved neste oppstart. Det er den tilstandsfylte regelen som lèt svara til B og TCP-handtrykket kome attende utan ei andre, spegla godtaking.

Kontroller teljarane etterpå i staden for regellista, fordi ein regel som aldri treff ser identisk ut med ein som verkar. Viss teljarane blir ståande på null, tek pakken ikkje den vegen du trur.

Kva B framleis må tillate

B køyrer SSH-tenesta, så B avgjer om noko lyttar på tunneladressa og om den eigne vertsbrannmuren godtek kjelda. Eit nettverksløyve på tenaren er ikkje løyve for nokon konto på B, og vertsnøkkelstadfesting og brukarautentisering gjeld framleis som frå kvar som helst elles.

Test det positive tilfellet først: ei ny SSH-tilkopling frå A til tunneladressa til B, godteken med den venta vertsnøkkelen. Test så ein annan likemann eller ein annan port og stadfest at han vert avvist, fordi eit løyve som stille tillèt alt, ikkje kan skiljast frå eit som verkar før det gjeld. Begge halvdelane av den testen trengst, og den andre er den folk hoppar over.

Skriv ned dei tildelte adressene, dei effektive rutene på begge klientane og dei nøyaktige reglane på tenaren og på B. Ein vellukka ping til gatewayen eller ein open port på tenaren provar ingen av desse, sidan begge kan vere sanne medan videresending mellom likemenn framleis er blokkert. Skriv ned tala medan tunnelen er oppe, fordi adressa ein klient får etter ei ny tilkopling kan vere ei anna.

Relaterte artiklar