Engedjük, hogy egy OpenVPN-kliens SSH-val elérjen egy másikat a pool megnyitása nélkül

Egy kliensnek el kell érnie egy másik kliens SSH-szolgáltatását, a pool többi részének pedig ugyanolyan elkülönítettnek kell maradnia, mint most. A csábító kapcsoló a client-to-client, amely mindenki számára egyszerre kapcsolja be a partnerek közötti hozzáférést, és a döntést a kernel helyett a OpenVPN-ra bízza. A szűkebb válasz kikapcsolva tartja ezt a kapcsolót, és a kiszolgáló saját útvonalválasztására és tűzfalára bízza pontosan egy folyam továbbítását.

A mechanizmus fontosabb a szabály szövegénél, mert a két megközelítés más helyre teszi a csomagot. Ha tudjuk, melyiket választottuk, az megmagyarázza mind a semmittevőnek tűnő szabályt, mind a nélküle csatlakozó partnert.

Hová mozgatja a csomagot a client-to-client

Ha a client-to-client be van kapcsolva, a kiszolgáló belsőleg továbbítja a partner csomagját, ahelyett hogy visszaküldené az alagút-eszközön, így a csomag soha nem ér el a kernel továbbítási útvonalára. Ez kényelmes, és azt is jelenti, hogy a tűzfalad soha nem látja azt a folyamot, amelyet felügyelnie kellene. Hagyd kikapcsolva a beállítást, és a kiszolgáló ugyanazon a csatolón küldi vissza a csomagot, ami a netfilter elé teszi. Ugyanaz a csatoló be, ugyanaz ki, és a FORWARD láncé a szó.

A csere egyértelmű: kapsz egy szabályozási pontot, és átvállalod az útvonalválasztást és a továbbítást, amelyet a rövidítés helyetted végzett. Ez a munka egyetlen folyamhoz kicsi, és minden hozzáadott kivétellel nő. Számold meg most a kivételeket, mert a szabálykészlet az, ahol a partnerek közti szabályozás valójában él.

Az útvonal, amelyet egy partner csomagja valójában bejár

Tételezz fel egy Linux Community OpenVPN 2.6 szolgáltatást, felhasználói térben futó TUN-feldolgozást DCO helyett, subnet topológiát, tun0, valamint egy 10.44.0.0/24 poolt, amelyben az A kliens 10.44.0.21, a B kliens pedig 10.44.0.37 címen van. Subnet topológiánál az A által kapott cím és maszk már lefedi a poolt, így az A plusz küldött útvonal nélkül küldi a csomagot az alagút-eszközre. Ellenőrizd az A tényleges útvonalát ahelyett, hogy feltételeznél egyet.

A kiszolgálón a csomag B címére érkezik, ami nem helyi cím, ezért továbbítódik. Az IPv4-továbbításnak be kell lennie kapcsolva ahhoz, hogy ez egyáltalán megtörténjen, és az útvonalkeresésnek vissza kell küldenie a csomagot a tun0 felé. A tűzfal tehát egy továbbított folyamot lát, amelynek mindkét oldalán ugyanaz a csatoló van, és ez az a részlet, amelyet a legtöbb szabálykészlet kihagy. Itt nincs szükség forrásfordításra, és éppen az A címének érintetlenül hagyása teszi lehetővé, hogy a B a saját forrásalapú szabályát alkalmazza.

Két szabály a kiszolgálón, ebben a sorrendben

A teljes engedélyt három szabály hordozza: a továbbítás, a pár kivétele és az alagútpár alapértelmezett eldobása. Az elfogadó szabály megnevezi a párt és a szolgáltatást, így az engedély túléli a növekvő poolt. Helyezd bármilyen általános alagút-alagút tiltás elé, mert az első egyezés nyer:

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

Ezek a parancsok szemléltetőek, és abba a mechanizmusba tartoznak, amellyel a gazdagéped a szabályokat tartósítja; a futásidejű beszúrás eltűnik a következő indításkor. Az állapotkövető szabály az, amely lehetővé teszi, hogy a B válaszai és a TCP kézfogás második, tükrözött elfogadás nélkül visszatérjenek.

Utólag a számlálókat ellenőrizd, ne a szabálylistát, mert egy soha nem egyező szabály pontosan úgy néz ki, mint egy működő. Ha a számlálók nullán maradnak, a csomag nem azt az utat járja, amelyet hiszel.

Mit kell a B-nek továbbra is engedélyeznie

A B futtatja az SSH-szolgáltatást, így a B dönti el, hallgat-e valami az alagútcímén, és elfogadja-e a gazdagép saját tűzfala a forrást. A kiszolgálón adott hálózati engedély nem engedély a B egyetlen fiókjának sem, a gazdagépkulcs-ellenőrzés és a felhasználói hitelesítés pedig továbbra is érvényes, mint bármely más helyről.

Először a pozitív esetet teszteld: egy friss SSH-kapcsolatot az A-tól a B alagútcímére, a várt gazdagépkulccsal elfogadva. Utána tesztelj egy másik partnert vagy egy másik portot, és igazold, hogy elutasítja, mert egy mindent csendben engedélyező engedély megkülönböztethetetlen egy működőtől addig, amíg nem számít. A teszt mindkét fele szükséges, és a másodikat szokták kihagyni.

Jegyezd fel a kiosztott címeket, a tényleges útvonalakat mindkét kliensen, valamint a pontos szabályokat a kiszolgálón és a B-n. Egy sikeres ping az átjáróra vagy egy nyitott port a kiszolgálón ebből semmit nem bizonyít, mivel mindkettő igaz lehet, miközben a partnerek közti továbbítás még blokkolt. Írd fel ezeket a számokat, amíg az alagút áll, mert az újracsatlakozás után kapott cím lehet más.