Egy TAP-kiszolgáló vagy több? OpenVPN-kliensek egy hídon

Több TAP-klienshez nem kell külön-külön egy kiszolgálófolyamat, egy UDP-port és egy gazdagép-TAP-eszköz. Egy Ethernet módban működő OpenVPN-kiszolgáló sok hitelesített klienst fogadhat és egyetlen hídhoz csatolhatja őket, és a 2-es réteg egy szegmensének bővítésére ez a dokumentált mód. Az egyfolyamatos kialakítás az, amelyet a kézikönyv dokumentál, és általában ez a helyes alapértelmezés.

Az igazi kérdés az, hogy ezeknek a klienseknek meg kell-e osztaniuk azt a szegmenst. A folyamatok száma nem válaszol rá, mert az elkülönítés tulajdonságai a topológiából erednek, nem abból, hány démon fut. Az összehasonlítás többi része a két topológiáról szól, és arról, hogy melyik mit tesz könnyűvé.

Két architektúra, nem két beállítás

Az irányított TUN-telepítés minden kliensnek pont-pont kapcsolatot ad a kiszolgáló irányítási tartományába. Az üzenetszórás a kiszolgálónál megáll, a kliensek nem látják egymás kereteit, a kliensek közötti forgalmat pedig, ha van, kifejezetten irányítani és szűrni kell.

A hidalt TAP-telepítés egy Ethernet-szegmens tagjaivá teszi a klienseket. Látják az üzenetszórást, ARP-pal feloldhatják egymást, és az elkülönüléshez a híd és a tűzfal szabályaira támaszkodnak az irányítás helyett. Ez akkor hasznos, ha a klienseknek úgy kell látszaniuk, mintha ugyanabba a kapcsolóba lennének bedugva.

Az összehasonlítás tehát arról szól, mit kell elérniük a klienseknek, nem a teljesítményről. Először a réteget válassza ki, aztán döntse el, hány folyamat szolgálja ki.

Mit tesz a server-bridge segéd

A server-bridge segéd a többklienses Ethernet módot állítja be. Címkészlet-formája átveszi az átjárót, a hálózati maszkot és a hidalt alhálózaton belüli elkülönített tartományt, például egy átjárót a 192.168.50.1 címen, 192.168.50.160-tól 192.168.50.199-ig terjedő készlettel.

Tartsa ezt a tartományt minden más DHCP- vagy statikus kiosztáson kívül. A segéd innen oszt címeket, de nem hangolja össze egy másik osztóval ugyanazon a szegmensen, és két átfedő készlet duplikált címeket eredményez, amelyek véletlenszerű kapcsolódási hibáknak tűnnek. Írja be a lefoglalt tartományt a telephely címtervébe, hogy a következő ember ne használja újra. A kiszolgáló konfigurációjában lévő megjegyzés szegény helyettesítője ennek a feljegyzésnek.

Létezik DHCP-proxy forma azokhoz a telepítésekhez, ahol külső kiszolgáló osztja a címeket. Ennek megvannak a maga előfeltételei, és a két forma keverése pontosan azt az ütközést hozza létre, amelyre a dokumentáció figyelmeztet. Válasszon egy osztót a hidalt alhálózathoz.

Az elkülönítés nem a folyamatok számából ered

Nyolc OpenVPN-folyamat, amely ugyanahhoz a korlátlan hídhoz csatlakozik, továbbra is egy üzenetszórási tartományt oszt meg. A kliensek ARP-ot küldhetnek egymásnak a hídon át, és a hallgatók száma ezen semmit sem változtatott.

Ha a követelmény az, hogy az ügyfélcsoportok ne lássák egymást a 2-es rétegen, a kialakításnak külön hidakra vagy VLAN-csatlakozásokra van szüksége, a hozzájuk tartozó hozzáférési szabályokkal. Ez hálózati tervezési döntés, és ugyanaz a döntés, akár egy, akár nyolc kiszolgálófolyamat vesz részt benne. A híd szűrése korlátozhat bizonyos forgalmat, de nem hoz létre külön üzenetszórási tartományokat. Tekintse a szegmentálás kiegészítésének, nem helyettesítőjének.

Ha csak az a követelmény, hogy a kliensek elérjenek bizonyos IP-szolgáltatásokat, az irányított TUN-kialakítás általában egyszerűbb a hidálás és szűrés kombinációjánál. Minden kliens saját kapcsolatot kap, és a szabályzat az irányítási és tűzfal-szabályokban él, nem a híd belsejében.

Amikor mégis több folyamat a helyes

A külön folyamatokat üzemeltetési igények indokolhatják: eltérő hitelesítési háttérrendszerek, eltérő tanúsító hatóságok, külön frissítési ciklusok vagy összeférhetetlen beállításkészletek. Ezek valódi okok, és függetlenek a kliensek számától.

Ha többet használ, adjon mindegyiknek saját figyelőt és eszköztulajdont, és hangolja össze a címtartományokat. Két kiszolgáló, amelyek mindketten azt hiszik, hogy az övék ugyanaz a készlet ugyanazon a hídon, előbb-utóbb ugyanazt a címet osztja ki.

Ezután több klienssel egyszerre ellenőrizze a kialakítást. Ellenőrizze, hogy a címek egyediek, hogy a szándékolt kliens-közti forgalom működik, és hogy egy pár, amelynek nem szabad kommunikálnia, valóban nem tud. Egyetlen kliens sikeres pingje semmit sem próbál ki a többklienses kialakításból.

Olvassa ki a hidat és a kiszolgáló módját a futó gazdagépből, mielőtt megbízik az ábrában. A fontos konfiguráció az, amelyet a kernel és a démon ténylegesen betöltött, és ez az is, amelyet egy bíráló ellenőrizhet.