OpenVPN kiszolgálása TCP-n és UDP-n egyetlen hosztról
Egy folyamat a 2.7 előtt egyetlen átvitelt köt. Hasonlítsa össze az áthidalt TAP párt, két TUN alhálózatot és egy közös címkészletet, majd párosítsa az egyes profilokat a saját figyelőjükkel.
A csak TCP 443-at engedélyező hálózatok együtt léteznek azokkal, amelyek az UDP-t gond nélkül átengedik, és egy kiszolgálónak mindkettőt ki kell szolgálnia. A proto udp tartalmazó profil a második csoportnak válaszol és az elsőnél elbukik, és ugyanazon konfiguráció proto tcp-re szerkesztése nem hoz létre második figyelőt. Az utasítás egy folyamat számára egyetlen átvitelt választ. Minden más ebből a korlátból következik.
Vagy egynél több folyamatot futtat, vagy olyan verziót futtat, amely egyszerre több socketet is képes kötni.
Egy folyamat a 2.7 előtt egyetlen átvitelt köt
A közösségi OpenVPN azt a socketet köti, amelyet a proto leír, és ez az utasítás egyetlen átvitelt választ a példány számára. A TCP és az UDP külön verem, ezért ugyanazt a portszámot mindkettő egyszerre foglalhatja, de egy folyamat nem. A 2.6-os sor ezért egy átvitelt ad démononként. Az OpenVPN 2.7 megszüntette ezt a korlátot a kiszolgálók esetében, amelyek több socketet is köthetnek több --local utasításon keresztül egyetlen folyamatban.
A tervezés előtt ellenőrizze a verziót, mert a 2.7-es elrendezés más üzemeltetési modell, saját konfigurációs szintaxissal. A 2.6-hoz írt útmutató két folyamatot ír le akkor is, ha ezt nem mondja ki.
Három mód két példány futtatására
TAP interfészekkel átvitelenként egy példányt futtasson, és hidalja össze a két tap eszközt a hoszton. Mindkét klienscsoport ugyanabba a broadcast tartományba kerül, így egyetlen címkészlet lefedheti őket, és a broadcast-függő protokollok tovább működnek. TUN esetén nincs áthidalás, ezért a legegyszerűbb felosztás minden példánynak saját alhálózatot ad, és az útválasztás tartja külön a két klienscsoportot. Egy harmadik lehetőség egyetlen készletet tart meg úgy, hogy minden példány meghív egy learn-address szkriptet, amely /32 útvonalat telepít az ügyfélnek az adott példány eszközén keresztül.
Ez a harmadik elrendezés az, amit az emberek kérnek, és amelyik a legtöbb gondosságot igényli, mert a szkript az adatút részévé válik, és helyesen kell kezelnie a hozzáadási, frissítési és törlési eseményeket.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Tartsa külön a két példányt
Minden példánynak külön portra vagy címre, külön állapotfájlra és külön naplócélra is szüksége van. Két démon, amely ugyanabba az állapotfájlba fűz, olyan kimenetet állít elő, amely incidens közben nem olvasható, pedig pont akkor van rá szükség. Ha a második példány adott címet köt, annak a címnek léteznie kell a hoszton a folyamat indulásakor; különben kötési hibával lép ki, mielőtt bármit mondana a kulcsokról.
Nevezze el az egységeket és a profilokat úgy, hogy az átvitel nyilvánvaló legyen a fájlnévből. A következő üzemeltetőnek ne kelljen megnyitnia egy konfigurációt, hogy megtudja, melyik a TCP.
Párosítsa a profilt a figyelőhöz
A proto tcp futtató kiszolgáló proto tcp-client kliensprofilt vár, és a még mindig proto udp tartalmazó profil az adott figyelővel szemben olyan hiba nélkül fut ki az időből, amelyre a felhasználó reagálhatna. Tartson két profilt, ha a telepítés mindkét átvitelt kínálja, és címkézze őket, hogy a támogatás tudja, melyiket próbálták. A portszám önmagában nem írja le az átvitelt.
A tűzfal-szabályok ugyanezt a felosztást követik: az UDP 1194-re vonatkozó szabály semmit sem mond a TCP 1194-ről, és az egyik címre vonatkozó szabály nem fedi a másik figyelőt.
Először a kiszolgáló képét olvassa el
Kezdje a ss -lntup paranccsal a kiszolgálón, és erősítse meg, hogy TCP és UDP figyelő is megjelenik. Ezután csatlakoztasson egy-egy klienst mindkét fajtából, és ellenőrizze a státuszkimenetben a két különböző című bejegyzést. Ha a socketek léteznek és egyetlen kliens sem érkezik, az útvonal vagy a tűzfal utasítja el a csomagokat, mielőtt a démon látná őket.
A soha meg nem jelenő socket konfigurációs vagy kötési probléma, a megjelenő, de kapcsolatot soha nem naplózó socket pedig szűrési probléma. A kettő a kliens felől azonosnak látszik, ezért jön először a kiszolgáló saját képe. Ne feledje, hogy a TCP fejsor-blokkolást hordoz, így felkínálása elérhetőségi intézkedés, nem pedig fejlesztés a tiszta UDP-útvonallal rendelkező kliensek számára.