Neka jedan OpenVPN klijent ide SSH na drugi bez otvaranja pula

Ostavite client-to-client isključen, pustite kernel da prosledi jedan tok, a ostatak pula neka ostane zatvoren. Dva pravila na serveru plus jedno na odredištu.

Jedan klijent treba da dosegne SSH uslugu drugog klijenta, a ostatak pula treba da ostane izolovan kao i danas. Primetljiv prekidač je client-to-client, koji uključuje pristup među klijentima za sve odjednom i odluku prepušta OpenVPN umesto kernelu. Uže rešenje drži taj prekidač isključenim i pušta da rutiranje i firewall servera nose tačno jedan tok.

Mehanizam je važniji od teksta pravila, jer dva pristupa stavljaju paket na različita mesta. Kada znate koji ste izabrali, to objašnjava i pravilo koje kao da ništa ne radi i klijenta koji se povezuje bez njega.

Kuda client-to-client premešta paket

Kada je client-to-client uključen, server prosleđuje paket klijenta interno umesto da ga pošalje natrag kroz tunelski uređaj, pa paket nikada ne stiže na kernelov put prosleđivanja. To je zgodno i ujedno znači da vaš firewall nikada ne vidi tok koji bi trebalo da čuva. Ostavite opciju isključenu i server usmerava paket natrag kroz isto sučelje, što ga stavlja pred netfilter. Isto sučelje ulazi, isto izlazi, a lanac FORWARD dobija glas.

Razmena je jasna: dobijate tačku politike i preuzimate rutiranje i prosleđivanje koje je prečica radila za vas. Taj posao je mali za jedan tok i raste sa svakim izuzetkom koji dodate. Prebrojte izuzetke sada, jer pravila su mesto gde politika prema klijentima zaista živi.

Put kojim paket klijenta zaista prolazi

Pretpostavite Linux Community OpenVPN 2.6 uslugu, obradu TUN u korisničkom prostoru umesto DCO, subnet topologiju, tun0 i pul od 10.44.0.0/24 sa klijentom A na 10.44.0.21 i klijentom B na 10.44.0.37. Kod subnet topologije adresa i maska koju je A dobio već pokrivaju pul, pa A šalje paket tunelskom uređaju bez dodatne gurnute rute. Proverite stvarnu rutu na A umesto da je pretpostavljate.

Na serveru paket stiže adresiran na B, što nije lokalna adresa, pa se prosleđuje. IPv4 prosleđivanje mora biti uključeno da bi se to uopšte dogodilo, a pretraga rute mora poslati paket natrag kroz tun0. Firewall zato vidi prosleđeni tok sa istim sučeljem na obe strane, a to je detalj koji većina skupova pravila propusti. Ovde nije potrebno prevođenje izvora, a očuvanje A-ove adrese je ono što B-u omogućava da primeni svoje pravilo zasnovano na izvoru.

Dva pravila na serveru, ovim redom

Tri pravila nose celu dozvolu: prosleđivanje, izuzetak za par i podrazumevano odbacivanje za tunelski par. Pravilo prihvatanja imenuje par i uslugu, pa dozvola preživljava pul koji raste. Postavite ga pre bilo kakvog sveobuhvatnog odbijanja tunel-na-tunel saobraćaja, jer prvo podudaranje pobeđuje:

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

Te komande su ilustrativne i pripadaju mehanizmu koji vaš host koristi za čuvanje pravila; unos u toku rada nestaje pri sledećem podizanju. Pravilo stanja je ono koje pušta B-ove odgovore i TCP rukovanje natrag bez drugog, preslikanog prihvatanja.

Proverite brojače posle, a ne listu pravila, jer pravilo koje se nikad ne podudara izgleda isto kao ono koje radi. Ako brojači ostanu na nuli, paket ne ide putem koji mislite.

Šta B još mora da dopusti

B pokreće SSH uslugu, pa B odlučuje da li bilo šta sluša na tunelskoj adresi i da li njegov sopstveni firewall prihvata izvor. Mrežna dozvola na serveru nije dozvola za bilo koji nalog na B-u, a provera ključa hosta i autentifikacija korisnika i dalje važe kao i sa bilo kog drugog mesta.

Prvo testirajte pozitivan slučaj: novu SSH vezu od A do B-ove tunelske adrese, prihvaćenu sa očekivanim ključem hosta. Zatim testirajte drugog klijenta ili drugi port i potvrdite da je odbijen, jer dozvola koja tiho dopušta sve ne razlikuje se od one koja radi sve dok ne postane važno. Obe polovine tog testa su neophodne, a drugu ljudi preskaču.

Zapišite dodeljene adrese, stvarne rute na oba klijenta i tačna pravila na serveru i na B-u. Uspešan ping do gejta ili otvoren port na serveru ne dokazuje ništa od ovoga, jer oboje može biti tačno dok je prosleđivanje među klijentima još blokirano. Zapišite te brojeve dok je tunel podignut, jer adresa koju klijent dobije nakon ponovnog povezivanja može biti druga.

Povezani članci