Lasi unu OpenVPN-klienton SSH al alia sen malfermi la adresaron
Tenu client-to-client malŝaltita, lasu la kernon plusendi unu fluon kaj lasu la reston de la adresaro fermita. Du reguloj sur la servilo kaj unu sur la celo.
Unu kliento devas atingi la SSH-servon de alia kliento, kaj la resto de la adresaro devas resti same izolita kiel hodiaŭ. La alloga ŝaltilo estas client-to-client, kiu ŝaltas aliron inter samuloj por ĉiuj samtempe kaj transdonas la decidon al OpenVPN anstataŭ al la kerno. Pli mallarĝa respondo tenas tiun ŝaltilon malŝaltita kaj lasas la propran enkursigadon kaj fajroŝirmilon de la servilo porti precize unu fluon.
La mekanismo pli gravas ol la teksto de la regulo, ĉar la du aliroj metas la paketon en malsamajn lokojn. Scii kiun vi elektis klarigas kaj la regulon, kiu ŝajnas fari nenion, kaj la samulon, kiu konektiĝas sen ĝi.
Kien client-to-client movas la paketon
Kiam client-to-client estas ŝaltita, la servilo plusendas paketon de samulo interne anstataŭ resendi ĝin tra la tunela aparato, do la paketo neniam atingas la plusendan vojon de la kerno. Tio estas oportuna kaj ankaŭ signifas, ke via fajroŝirmilo neniam vidas la fluon, kiun ĝi devus kontroli. Lasu la opcion malŝaltita kaj la servilo enkursigas la paketon denove eksteren tra la sama interfaco, kio metas ĝin antaŭ netfilter. Sama interfaco enen, sama interfaco eksteren, kaj la ĉeno FORWARD havas la voĉon.
La interŝanĝo estas klara: vi gajnas unu politikan punkton kaj vi prenas sur vin la enkursigadon kaj plusendadon, kiujn la mallongigo faris por vi. Tiu laboro estas malgranda por unu fluo kaj kreskas kun ĉiu escepto, kiun vi aldonas. Kalkulu la esceptojn nun, ĉar en la regularo vere loĝas la politiko inter samuloj.
La vojo, kiun paketo de samulo fakte iras
Supozu servon Linux Community OpenVPN 2.6, TUN-prilaboradon en uzantspaco anstataŭ DCO, subretan topologion, tun0 kaj adresaron 10.44.0.0/24 kun kliento A ĉe 10.44.0.21 kaj kliento B ĉe 10.44.0.37. Ĉe subreta topologio la adreso kaj retmasko, kiujn A ricevis, jam kovras la adresaron, do A sendas la paketon al la tunela aparato sen bezoni plian puŝitan itineron. Kontrolu la efektivan itineron sur A anstataŭ supozi unu.
Sur la servilo la paketo alvenas adresita al B, kio ne estas loka adreso, do ĝi estas plusendata. IPv4-plusendado devas esti ŝaltita por ke tio entute okazu, kaj la itinera serĉo devas resendi la paketon tra tun0. La fajroŝirmilo do vidas plusenditan fluon kun la sama interfaco ambaŭflanke, kaj tio estas la detalo, kiun plej multaj regularoj maltrafas. Ĉi tie neniu fonta traduko necesas, kaj ĝuste teni la adreson de A sendifekta ebligas al B apliki sian propran fontbazitan regulon.
Du reguloj sur la servilo, en ĉi tiu ordo
Tri reguloj portas la tutan permeson: plusendado, la par-escepto kaj defaŭlta forĵeto por la tunela paro. La akcepta regulo nomas la paron kaj la servon, do la permeso postvivas kreskantan adresaron. Metu ĝin antaŭ ajna ĝenerala malpermeso de tunel-al-tunela trafiko, ĉar la unua kongruo gajnas:
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 DROPTiuj komandoj estas ilustraj kaj apartenas al la mekanismo, kiun via gastiganto uzas por konservi regulojn; enmeto dum rulado malaperas ĉe la sekva ekŝalto. La statokonscia regulo estas tiu, kiu lasas la respondojn de B kaj la TCP-manpremon reveni sen dua, spegulita akcepto.
Kontrolu la nombrilojn poste anstataŭ la reguloliston, ĉar regulo, kiu neniam kongruas, aspektas idente al unu, kiu funkcias. Se la nombriloj restas ĉe nulo, la paketo ne sekvas la vojon, kiun vi pensas.
Kion B ankoraŭ devas permesi
B funkciigas la SSH-servon, do B decidas ĉu io aŭskultas ĉe la tunela adreso kaj ĉu ĝia propra gastiganta fajroŝirmilo akceptas la fonton. Retpermeso sur la servilo ne estas permeso por iu ajn konto ĉe B, kaj gastigantŝlosila kontrolo kaj uzantaŭtentikigo ankoraŭ validas kiel de iu ajn alia loko.
Testu unue la pozitivan kazon: nova SSH-konekto de A al la tunela adreso de B, akceptita kun la atendata gastigantŝlosilo. Poste testu alian samulon aŭ alian pordon kaj konfirmu, ke ĝi estas rifuzata, ĉar permeso, kiu silente permesas ĉion, ne distingiĝas de tiu, kiu funkcias, ĝis ĝi gravas. Ambaŭ duonoj de tiu testo necesas, kaj la dua estas tiu, kiun homoj saltas.
Notu la asignitajn adresojn, la efektivajn itinerojn sur ambaŭ klientoj kaj la ĝustajn regulojn sur la servilo kaj sur B. Sukcesa ping al la enirejo aŭ malferma pordo sur la servilo pruvas nenion el tio, ĉar ambaŭ povas esti veraj dum plusendado inter samuloj ankoraŭ estas blokita. Skribu tiujn nombrojn dum la tunelo staras, ĉar la adreso, kiun kliento ricevas post rekonekto, povas esti alia.