Ļaut vienam OpenVPN klientam ar SSH savienojumu sasniegt otru, neatverot adrešu baseinu

Vienam klientam jāsasniedz cita klienta SSH pakalpojums, un pārējam baseinam jāpaliek tikpat izolētam kā tagad. Kārdinošais slēdzis ir client-to-client, kas ieslēdz piekļuvi starp vienaudžiem visiem uzreiz un nodod lēmumu OpenVPN, nevis kodolam. Šaurāka atbilde atstāj šo slēdzi izslēgtu un ļauj paša servera maršrutēšanai un ugunsmūrim pārvadāt tieši vienu plūsmu.

Mehānisms ir svarīgāks par noteikuma tekstu, jo abas pieejas ievieto pakešu dažādās vietās. Zināšana, kuru izvēlējāties, izskaidro gan noteikumu, kas šķietami neko nedara, gan vienaudzi, kas savienojas bez tā.

Kur client-to-client pārvieto pakešu

Kad client-to-client ir ieslēgts, serveris pārsūta vienaudža pakešu iekšēji, nevis sūta to atpakaļ ārā pa tuneļa ierīci, tāpēc pakešu nekad nesasniedz kodola pārsūtīšanas ceļu. Tas ir ērti, un tas arī nozīmē, ka jūsu ugunsmūris nekad neredz plūsmu, kuru tam būtu jāuzrauga. Atstājiet opciju izslēgtu, un serveris maršrutē pakešu atpakaļ ārā pa to pašu saskarni, kas to noliek netfilter priekšā. Tā pati saskarne iekšā, tā pati ārā, un FORWARD ķēdei ir balss.

Apmaiņa ir skaidra: jūs iegūstat politikas punktu un uzņematies maršrutēšanas un pārsūtīšanas darbu, ko saīsne darīja jūsu vietā. Šis darbs ir mazs vienai plūsmai un pieaug ar katru pievienoto izņēmumu. Saskaitiet izņēmumus tagad, jo tieši noteikumu kopā patiesībā dzīvo politika starp vienaudžiem.

Ceļš, kuru vienaudža pakešu patiešām iet

Pieņemiet Linux Community OpenVPN 2.6 pakalpojumu, TUN apstrādi lietotāja telpā, nevis DCO, apakštīkla topoloģiju, tun0 un baseinu 10.44.0.0/24 ar klientu A adresē 10.44.0.21 un klientu B adresē 10.44.0.37. Apakštīkla topoloģijā A saņemtā adrese un tīkla maska jau aptver baseinu, tāpēc A sūta pakešu uz tuneļa ierīci bez papildu stumta maršruta. Pārbaudiet faktisko maršrutu uz A, nevis pieņemiet tādu.

Serverī pakešu pienāk adresēts B, kas nav vietējā adrese, tāpēc tas tiek pārsūtīts. IPv4 pārsūtīšanai jābūt ieslēgtai, lai tas vispār notiktu, un maršruta meklējumam ir jāsūta pakešu atpakaļ pa tun0. Tāpēc ugunsmūris redz pārsūtītu plūsmu ar to pašu saskarni abās pusēs, un tas ir detaļa, ko lielākā daļa noteikumu kopu palaiž garām. Šeit nav nepieciešama avota tulkošana, un tieši A adreses saglabāšana ļauj B piemērot savu avotā balstīto noteikumu.

Divi noteikumi serverī, šādā secībā

Trīs noteikumi nes visu atļauju: pārsūtīšana, pāra izņēmums un noklusējuma nomešana tuneļa pārim. Pieņemšanas noteikums nosauc pāri un pakalpojumu, tāpēc atļauja pārdzīvo augošu baseinu. Novietojiet to pirms jebkura vispārēja tuneļa-uz-tuneli satiksmes aizlieguma, jo uzvar pirmā atbilstība:

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

Šīs komandas ir ilustratīvas un pieder pie mehānisma, ko jūsu saimnieks izmanto noteikumu saglabāšanai; izpildlaika ievietojums pazūd nākamajā palaišanā. Tieši stāvokļa noteikums ļauj B atbildēm un TCP roku paspiešanai atgriezties bez otras, spoguļotas pieņemšanas.

Pēc tam pārbaudiet skaitītājus, nevis noteikumu sarakstu, jo noteikums, kas nekad nesakrīt, izskatās tieši tāpat kā strādājošs. Ja skaitītāji paliek nullē, pakešu neiet pa ceļu, kuru domājat.

Kas B vēl ir jāatļauj

B darbina SSH pakalpojumu, tāpēc B izlemj, vai kaut kas klausās tuneļa adresē un vai tā paša resursdatora ugunsmūris pieņem avotu. Tīkla atļauja serverī nav atļauja nevienam B kontam, un resursdatora atslēgas pārbaude un lietotāja autentifikācija joprojām ir spēkā kā no jebkuras citas vietas.

Vispirms pārbaudiet pozitīvo gadījumu: jaunu SSH savienojumu no A uz B tuneļa adresi, pieņemtu ar gaidīto resursdatora atslēgu. Pēc tam pārbaudiet citu vienaudzi vai citu portu un apstipriniet, ka tas tiek noraidīts, jo atļauja, kas klusi atļauj visu, nav atšķirama no strādājošas, līdz tas kļūst svarīgi. Abas šī testa puses ir vajadzīgas, un otro cilvēki izlaiž.

Pierakstiet piešķirtās adreses, faktiskos maršrutus abos klientos un precīzos noteikumus serverī un uz B. Veiksmīgs ping uz vārteju vai atvērts ports serverī neko no tā nepierāda, jo abi var būt patiesi, kamēr pārsūtīšana starp vienaudžiem joprojām ir bloķēta. Pierakstiet šos skaitļus, kamēr tunelis ir pacelts, jo adrese, ko klients saņem pēc atkārtotas pieslēgšanās, var būt cita.