Viens TAP serveris vai vairāki? OpenVPN klienti uz tilta

Vairākiem TAP klientiem nav nepieciešams katram savs servera process, viens UDP ports un viens TAP ierīces eksemplārs uz resursdatora. Viens OpenVPN serveris Ethernet režīmā var uzņemt daudzus autentificētus klientus un pievienot tos vienam tiltam, un tas ir dokumentētais veids, kā paplašināt 2. slāņa segmentu. Viena procesa risinājums ir tas, ko dokumentē rokasgrāmata, un parasti tas ir pareizais noklusējums.

Īstais jautājums ir, vai šiem klientiem vajadzētu dalīt šo segmentu. Procesu skaits uz to neatbild, jo izolācijas īpašības nāk no topoloģijas, nevis no tā, cik daudz dēmonu darbojas. Pārējā salīdzinājuma daļa ir par abām topoloģijām un to, ko katra atvieglo.

Divas arhitektūras, nevis divi iestatījumi

Maršrutēts TUN izvietojums katram klientam dod punkts-punktā savienojumu servera maršrutēšanas domēnā. Apraides apstājas serverī, klienti neredz viens otra kadrus, un starpklientu trafikam, ja tāds ir, jābūt skaidri maršrutētam un filtrētam.

Tiltots TAP izvietojums padara klientus par viena Ethernet segmenta dalībniekiem. Viņi redz apraides, var atrast viens otru ar ARP un, lai paliktu atdalīti, paļaujas uz tilta un ugunsmūra politiku, nevis maršrutēšanu. Tas ir noderīgi, ja klientiem jāizskatās tā, it kā tie būtu pievienoti tam pašam komutatoram.

Tātad salīdzinājums ir par to, kas klientiem jāsasniedz, nevis par veiktspēju. Vispirms izvēlieties slāni, pēc tam izlemiet, cik procesu to apkalpos.

Ko dara server-bridge palīgs

server-bridge palīgs konfigurē vairāku klientu Ethernet režīmu. Tā adrešu kopas forma ņem vārteju, tīkla masku un īpašu diapazonu tiltotā apakštīklā, piemēram, vārteju 192.168.50.1 ar kopu no 192.168.50.160 līdz 192.168.50.199.

Rezervējiet šo diapazonu ārpus jebkuras citas DHCP vai statiskas piešķiršanas. Palīgs no tā piešķir adreses, bet nesaskaņo darbības ar citu sadalītāju tajā pašā segmentā, un divas pārklājošas kopas rada dublētas adreses, kas izskatās kā nejaušas savienojuma kļūdas. Ierakstiet rezervēto diapazonu vietnes adrešu plānā, lai nākamā persona to neizmantotu atkārtoti. Komentārs servera konfigurācijā ir slikts šī ieraksta aizstājējs.

Ir forma ar DHCP starpnieku izvietojumiem, kuros adreses izsniedz ārējs serveris. Tai ir savi priekšnosacījumi, un abu formu sajaukšana rada tieši to konfliktu, par ko brīdina dokumentācija. Izvēlieties vienu sadalītāju tiltotajam apakštīklam.

Izolācija nenāk no procesu skaita

Astoņi OpenVPN procesi, kas pievienoti tai pašai neierobežotajai tiltai, joprojām dala vienu apraides domēnu. Klienti var sūtīt ARP viens otram pāri tiltam, un klausītāju skaits to nemainīja.

Ja prasība ir, lai klientu grupas 2. slānī neredzētu viena otru, projektam vajag atsevišķus tiltus vai VLAN pieslēgumus kopā ar atbilstošajiem piekļuves noteikumiem. Tas ir tīkla projektēšanas lēmums, un tas ir vienāds neatkarīgi no tā, vai iesaistīts viens servera process vai astoņi. Tilta filtrēšana var ierobežot daļu trafika, bet nerada atsevišķas apraides domēnas. Uzskatiet to par segmentācijas papildinājumu, nevis aizstājēju.

Ja prasība ir tikai, lai klienti sasniegtu noteiktus IP pakalpojumus, maršrutēts TUN risinājums parasti ir vienkāršāks nekā tiltēšana ar filtrēšanu. Katrs klients iegūst savu savienojumu, un politika dzīvo maršrutēšanas un ugunsmūra noteikumos, nevis tilta iekšienē.

Kad vairāki procesi tomēr ir pareizi

Atsevišķus procesus var pamatot ar ekspluatācijas vajadzībām: atšķirīgas autentifikācijas aizmugures sistēmas, atšķirīgas sertifikācijas iestādes, atsevišķi atjaunināšanas cikli vai nesaderīgas opciju kopas. Tie ir reāli iemesli, un tie nav atkarīgi no klientu skaita.

Ja izmantojat vairākus, piešķiriet katram savu klausītāju un ierīces īpašumtiesības un saskaņojiet adrešu diapazonus. Divi serveri, kas abi uzskata, ka tiem pieder tā pati kopa uz tā paša tilta, galu galā izsniegs to pašu adresi.

Pēc tam pārbaudiet projektu ar vairākiem klientiem vienlaikus. Pārbaudiet, vai adreses ir unikālas, vai paredzētais starpklientu trafiks darbojas un vai pāris, kuram nevajadzētu sazināties, to nevar. Viena klienta veiksmīgs ping nepārbauda neko no vairāku klientu projekta.

Izlasiet tiltu un servera režīmu no darbojošā resursdatora, pirms uzticaties shēmai. Svarīgā konfigurācija ir tā, ko kodols un dēmons faktiski ielādēja, un tieši to var pārbaudīt recenzents.