Üks TAP-server või mitu? OpenVPN-i kliendid sillal
TAP-kliendid jagavad ühte silda ja ühte serveriprotsessi, mis tähendab ka ühte leviedastusdomeeni. Enne valimist võrrelge sillatud Etherneti marsruuditud TUN-iga.
Mitu TAP-klienti ei vaja igaüks oma serveriprotsessi, UDP-porti ja hosti TAP-seadet. Üks OpenVPN server Etherneti režiimis saab vastu võtta palju autenditud kliente ja siduda need ühe sillaga, ning see on dokumenteeritud viis kihi 2 segmendi laiendamiseks. Ühe protsessi lahendus on see, mida käsiraamat dokumenteerib, ja tavaliselt on see õige vaikeväärtus.
Tegelik küsimus on, kas need kliendid peaksid seda segmenti jagama. Protsesside arv ei vasta sellele, sest isolatsiooni omadused tulevad topoloogiast, mitte sellest, kui palju deemoneid töötab. Ülejäänud võrdlus käsitleb kahte topoloogiat ja seda, mida kumbki lihtsaks teeb.
Kaks arhitektuuri, mitte kaks seadet
Marsruuditud TUN-i juurutus annab igale kliendile punkt-punkti ühenduse serveri marsruutimisdomeeni. Leviedastused peatuvad serveris, kliendid ei näe üksteise kaadreid, ja klientidevaheline liiklus, kui seda on, tuleb selgesõnaliselt marsruutida ja filtreerida.
Sillatud TAP-i juurutus teeb klientidest ühe Etherneti segmendi liikmed. Nad näevad leviedastusi, saavad üksteist ARP-iga lahendada ja sõltuvad eraldi püsimiseks silla ning tulemüüri poliitikast, mitte marsruutimisest. See on kasulik siis, kui kliendid peavad paistma nii, nagu oleksid nad samasse kommutaatorisse ühendatud.
Võrdlus on seega sellest, milleni kliendid peavad jõudma, mitte jõudlusest. Valige esmalt kiht ja seejärel otsustage, mitu protsessi seda teenindab.
Mida server-bridge abivahend teeb
Abivahend server-bridge seadistab mitme kliendi Etherneti režiimi. Selle aadressipooli vorm võtab lüüsi, võrgumaski ja sillatud alamvõrgu sees oleva eraldatud vahemiku, näiteks lüüsi 192.168.50.1 ja pooli 192.168.50.160 kuni 192.168.50.199.
Hoidke see vahemik väljaspool igasugust muud DHCP või staatilist määramist. Abivahend eraldab sealt aadresse, kuid ei kooskõlasta tegevust teise jaotajaga samas segmendis, ja kaks kattuvat pooli tekitavad dubleeritud aadresse, mis näevad välja nagu juhuslikud ühendustõrked. Kirjutage eraldatud vahemik saidi aadressiplaani, et järgmine inimene ei kasutaks seda uuesti. Kommentaar serveri konfiguratsioonis on selle kirje kehv asendus.
Olemas on DHCP-puhverserveri vorm juurutustele, kus aadresse jagab väline server. Sellel on omad eeldused, ja kahe vormi segamine tekitab täpselt selle konflikti, mille eest dokumentatsioon hoiatab. Valige sillatud alamvõrgu jaoks üks jaotaja.
Isolatsioon ei tule protsesside arvust
Kaheksa OpenVPN-i protsessi, mis on ühendatud sama piiramata sillaga, jagavad endiselt ühte leviedastusdomeeni. Kliendid saavad silla kaudu üksteisele ARP-i saata ja kuulajate arv ei muutnud selles midagi.
Kui nõue on, et kliendirühmad ei näeks üksteist kihil 2, vajab lahendus eraldi sildu või VLAN-ühendusi koos nendega kaasnevate juurdepääsureeglitega. See on võrgu kujundamise otsus ja see on sama, olenemata sellest, kas osaleb üks serveriprotsess või kaheksa. Silla filtreerimine võib osa liiklust piirata, kuid ei loo eraldi leviedastusdomeene. Käsitlege seda segmenteerimise täiendusena, mitte selle asendusena.
Kui nõue on ainult see, et kliendid jõuaksid teatud IP-teenusteni, on marsruuditud TUN-i lahendus tavaliselt lihtsam kui sillutamine koos filtreerimisega. Iga klient saab oma ühenduse ja poliitika elab marsruutimis- ning tulemüürireeglites, mitte silla sisemuses.
Millal on mitu protsessi siiski õiged
Eraldi protsesse võib põhjendada töökorralduslike vajadustega: erinevad autentimistagused, erinevad sertifitseerimisasutused, eraldi uuendustsüklid või ühildumatud valikukomplektid. Need on tegelikud põhjused ja need ei sõltu klientide arvust.
Kui kasutate mitut, andke kõigile oma kuulaja ja seadme omand ning kooskõlastage aadressivahemikud. Kaks serverit, mis mõlemad usuvad, et omavad sama pooli samal sillal, jagavad lõpuks sama aadressi.
Seejärel kontrollige lahendust mitme kliendiga korraga. Kontrollige, et aadressid on unikaalsed, et kavandatud klientidevaheline liiklus töötab ja et paar, mis ei tohi suhelda, ei saagi seda teha. Ühe kliendi edukas ping ei kontrolli mitme kliendi lahendusest mitte midagi.
Lugege sild ja serveri režiim töötavalt hostilt enne, kui usaldate diagrammi. Oluline on konfiguratsioon, mille kernel ja deemon tegelikult laadisid, ja just seda saab ka ülevaataja kontrollida.