Vai klienti divos OpenVPN serveros var sasniegt viens otru?

Otra OpenVPN servera uzstādīšana dod otru vietu, kur klienti var pieslēgties, un neko vairāk. Tas neliek šos klientus pirmā servera tīklā, un opcija ar nosaukumu client-to-client maina tikai pāradresāciju vienā servera procesā. Abi apgabali kļūst par vienu tīklu, kad jūs apzināti maršrutējat starp tiem, ar atbildīgo katram virzienam. Viss turpmāk pieņem lietotāja telpas TUN režīmu ar izslēgtu šo iekšējo pāradresāciju, tāpēc lēmumu pieņem kodols.

Mīts: viens kontu saraksts, viens tīkls

Autentifikācija un sasniedzamība tiek jaukta, jo abas dzīvo servera konfigurācijā. Lietotājs, kurš var pieslēgties jebkuram no diviem vārtiem, no ārpuses izskatās kā vienas sistēmas lietotājs ar divām durvīm. Iekšpusē katrs serveris izdala adreses no sava apgabala un instalē maršrutus tikai tiem klientiem, kuru sesiju tas pārtrauc. Tāpēc klients pie vārtiem A, sūtot pakešu klientam pie vārtiem B, pieprasa galamērķi, par kuru viņa paša serveris nekad nav dzirdējis. Pakete dodas uz A noklusējuma maršrutu, atstāj tuneli un nonāk pie ugunsmūra, kuram nekad nav lūgts to atļaut.

Tāpēc otra servera pievienošana nepievieno dublējumu, atklāšanu vai kopīgu apraides domēnu. Tā pievieno maršrutētu tīklu, kam vajadzīgs plāns, un plāns sākas ar adresāciju.

Dodiet katriem vārtiem savu apgabalu un tranzīta adresi

Divi diapazoni, kas nevar pārklāties ar neko citu, un neliela tranzīta saite starp resursdatoriem – tas ir viss adrešu plāns. Turiet tranzītu privātā segmentā, ko kontrolējat, un pierakstiet skaitļus, pirms kāds serveris izsniedz nomu.

Pretojieties kārdinājumam dot abiem serveriem vienu un to pašu apgabalu, lai profili paliktu identiski. Kodola maršruts nevar pateikt, kurš no diviem resursdatoriem pašlaik pārvalda patvaļīgu adresi kopīgā diapazonā, tāpēc maršrutēšanas tabula norādītu uz vieniem vārtiem, bet klients varētu būt pievienots otriem. Saskarnes nosaukumi ir vietējas konvencijas, nevis kopīgs stāvoklis. Abi resursdatori šeit tuneļa ierīci sauc tun0, bet tranzīta saiti transit0, un tas ir kārtībā, jo neviena pakete nenes šos nosaukumus.

Instalējiet maršrutu abās pusēs

Katram vārtiem vajadzīgs maršruts uz otra apgabalu caur tranzīta adresi, un pāradresācijai jābūt ieslēgtai, lai jebkurš varētu darboties kā lēciens. Vispirms apstipriniet pašreizējo tabulu, pēc tam pievienojiet ierakstu un padariet to noturīgu, izmantojot resursdatora tīkla pārvaldnieku, nevis atkārtotas pievienošanās āķi.

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

Atkārtojiet to otrā resursdatorā ar apmainītiem apgabaliem. Viena un tā paša maršruta atkārtota pievienošana no nesaistīta skripta ir veids, kā resursdators iegūst vairākas kopijas un noslēpumainas izmaiņas nākamreiz, kad kāds lasa tabulu. Ja tranzīta saite pati ir tunelis, maršruts norāda uz tā topoloģiju, un lēcienam jāpārdzīvo tā atkārtota pievienošanās. Tranzīta adrese, kas pazūd uz trīsdesmit sekundēm, aizved līdzi arī ceļu starp apgabaliem, un tā ir projektēšanas īpašība, ko vērts paziņot, nevis atklāt.

Virziet klienta maršrutu, neviltojot īpašumtiesības

Klientiem vajadzīgs maršruts uz attālo apgabalu, citādi viņu pašu operētājsistēma sūta pakešu uz noklusējuma vārtiem, un tunelis to nekad neredz. Servera konfigurācija ir dabiskā vieta, kur to piegādāt.

push "route 10.64.20.0 255.255.255.0"

Ievietojiet spoguļa rindu otra servera konfigurācijā, pēc tam atkārtoti pievienojiet testa klientu un izlasiet tā tabulu. Klientam, kas ignorē virzītos maršrutus, vajadzīga sava apstiprinātā konfigurācija, un maršruts, kas nekad neierodas, nav piekļuves kontrole. Nedodiet klientam iroute visam otru vārtu apgabalam. Šī direktīva ir paredzēta apakštīklam aiz viena pievienota klienta, un tās izmantošana trūkstoša maršruta starp vārtiem aizsegšanai rada serveri, kas tic, ka tam pieder adreses, kuras tas nevar sasniegt.

Pierādiet vienu pieprasījumu un noraidiet citu

Izvēlieties reālu darbību, piemēram, HTTPS no klienta adresē 10.64.10.21 uz pakalpojumu adresē 10.64.20.37, un atļaujiet tieši to abos resursdatoros. Katrs ugunsmūris pieņem pieprasījumu savā ienākošajā pusē un izsekoto atbildi atgriešanās pusē; galamērķa pakalpojuma politikai tas vēl jāpieņem.

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

Ar savstarpējiem maršrutiem avota NAT nav vajadzīgs un šeit ir aktīvi kaitīgs: avota tulkošana slēpj, kurš klients iesniedza pieprasījumu, un grauj uz avotu balstītu politiku galamērķa pusē. Pārbaudiet, vai esošais maskēšanas noteikums interneta izejai neietver arī šo ceļu. Pēc tam pārbaudiet noraidījumu. Pakalpojumam, kam jāpaliek lokālam apgabalā B, jāpaliek nesasniedzamam no apgabala A, un arī klientu pāri pie tiem pašiem vārtiem ir jāpārbauda, jo tikko mainītā pāradresācijas politika attiecas arī uz tiem.

Vēl viens labojums domāšanas modelī: tranzīta saite pārvadā atšifrētas iekšējās paketes, tāpēc tā ir uzticēšanās robeža, nevis privāta garantija. Ja tā šķērso tīklu, ko jūs nekontrolējat, aizsargājiet šo lēcienu ar apstiprinātu šifrētu tuneli un maršrutējiet pa tā reālo topoloģiju. No gala līdz galam TLS joprojām pats autentificē lietotni, tāpēc iekšējam pakalpojumam tas jāturpina izmantot.