Geti klientar á tveimur OpenVPN-þjónum náð hvor til annars?

Að setja upp annan OpenVPN þjón gefur þér annan stað fyrir klienta að tengjast, og ekkert meira. Það setur þessa klienta ekki á net fyrsta þjónsins, og valkosturinn sem heitir client-to-client breytir aðeins framsendingu innan eins þjónsferlis. Söfnin tvö verða eitt net þegar þú beinir á milli þeirra viljandi, með eiganda fyrir hvora stefnu. Allt hér að neðan gerir ráð fyrir TUN-stillingu í notendarými með þeirri innri framsendingu slökktri, svo kjarninn tekur ákvörðunina.

Goðsögnin: einn reikningalisti, eitt net

Auðkenning og náanleiki ruglast saman því bæði búa í stillingum þjónsins. Notandi sem getur skráð sig inn á hvora gáttina sem er virðist að utan eins og notandi á einu kerfi með tveimur dyrum. Inni úthlutar hver þjónn heimilum úr eigin safni og setur upp leiðir aðeins fyrir þá klienta sem hann lýkur. Þannig biður klientur á gátt A sem sendir pakka til klients á gátt B um áfangastað sem hans eigin þjónn hefur aldrei heyrt um. Pakkinn fer á sjálfgefna leið A, yfirgefur göngin og kemur að eldvegg sem aldrei var beðinn um að leyfa hann.

Að bæta við öðrum þjóni bætir því ekki við ofgnótt, uppgötvun eða sameiginlegu útvarpssvæði. Það bætir við beindu neti sem þarf áætlun, og áætlunin byrjar á vistföngum.

Gefðu hverri gátt eigið safn og gegnumferðarfang

Tvö svið sem geta ekki skarast við neitt annað, auk lítillar gegnumferðartengingar milli hýslanna, er öll vistfangaáætlunin. Hafðu gegnumferðina á einkahluta sem þú stýrir, og skrifaðu tölurnar niður áður en nokkur þjónn veitir leigu.

Andstattu freistingunni að gefa báðum þjónum sama safn svo sniðin haldist eins. Kjarnaleið getur ekki sagt hvor af tveimur hýslum eigi nú handahófskennt vistfang innan sameiginlegs sviðs, svo beiningataflan myndi vísa á eina gátt og klienturinn gæti verið tengdur hinni. Viðmótsheiti eru staðbundnar venjur, ekki sameiginlegt ástand. Báðir hýslarnir hér kalla göngutækið tun0 og gegnumferðartenginguna transit0, sem er í lagi því enginn pakki ber þessi heiti.

Settu leiðina upp á báðum hliðum

Hver gátt þarf leið að safni hinnar í gegnum gegnumferðarfangið, og framsending verður að vera virk svo hvor sem er geti starfað sem stökk. Staðfestu núverandi töflu fyrst, bættu síðan færslunni við og gerðu hana varanlega í gegnum netstjóra hýsilsins frekar en tengikrók við endurtengingu.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Speglaðu þetta á hinum hýslinum með söfnin víxluð. Endurtekin viðbót sömu leiðar frá ótengdu skripti er hvernig hýsill endar með nokkur eintök og dulræna breytingu næst þegar einhver les töfluna. Ef gegnumferðartengingin er sjálf göng, vísar leiðin á netfræði þeirra ganga og stökkið verður að standast endurtengingu þeirra. Gegnumferðarfang sem hverfur í þrjátíu sekúndur tekur leiðina milli safnanna með sér, sem er hönnunareiginleiki sem betra er að lýsa yfir en uppgötva.

Ýttu leið klientsins án þess að þykjast eiga hana

Klientar þurfa leið að fjarlæga safninu, annars sendir þeirra eigið stýrikerfi pakkann á sjálfgefna gátt og göngin sjá hann aldrei. Stilling þjónsins er eðlilegur staður til að afhenda það.

push "route 10.64.20.0 255.255.255.0"

Settu spegilinn í stillingar hins þjónsins, tengdu svo prófklient aftur og lestu töfluna hans. Klientur sem hunsar ýttar leiðir þarf sína eigin samþykktu stillingu, og leið sem kemur aldrei er ekki aðgangsstýring. Gefðu klient ekki iroute fyrir allt safn hinnar gáttarinnar. Þessi tilskipun er fyrir undirnet bak við einn tengdan klient, og að nota hana til að hylja leið sem vantar milli gátta skapar þjón sem trúir því að hann eigi vistföng sem hann nær ekki.

Sannaðu eina beiðni og hafnaðu annarri

Veldu raunverulega aðgerð, til dæmis HTTPS frá klient á 10.64.10.21 til þjónustu á 10.64.20.37, og leyfðu nákvæmlega það á báðum hýslum. Hver eldveggur tekur við beiðninni á innstreymishlið og reknu svari á afturhlið; þjónustustefna áfangastaðarins verður samt að samþykkja hana.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Með gagnkvæmum leiðum er upptökunetfangi óþarft og hér virkilega skaðlegt: þýðing upptökunnar felur hvaða klientur lagði fram beiðnina og grafa undan stefnu sem byggir á upptöku hjá áfangastaðnum. Athugaðu að núverandi masquerade-regla fyrir internetútganga grípi ekki líka þessa leið. Prófaðu svo höfnunina. Þjónusta sem á að vera staðbundin í safni B verður að vera óaðgengileg frá safni A, og prófa þarf klientapör á sömu gátt líka, þar sem framsendingarstefnan sem þú breyttir rétt í gildir líka um þau.

Ein leiðrétting enn á hugmyndalíkaninu: gegnumferðartengingin flytur afkóðuð innri pakka, svo hún er traustamörk en ekki einkagarantí. Ef hún liggur í gegnum net sem þú stýrir ekki, verndaðu það stökk með samþykktum dulkóðuðum göngum og beindu í gegnum raunverulega netfræði þeirra. TLS frá enda til enda auðkennir forritið samt sjálft, þess vegna ætti innri þjónustan að halda áfram að nota það.