Két szolgáltatáscím egy OpenVPN-ügyfélen: iroute és lo

Az alkalmazás a saját alagútcímén válaszol, a hozzá dokumentált cím pedig sehová nem vezet. Semmi sem panaszkodik az OpenVPN naplójában, a peer csatlakozottnak látszik, és a hub pontosan egy ügyfelet listáz. A rés az, hogy egy második cím az ügyfélen két külön tény: a gazdagépnek birtokolnia kell, és a hubnak tudnia kell, melyik peer birtokolja. Kezelje az egyiket a másik nélkül, és a forgalom vagy meghal a hubnál, vagy visszaút nélkül érkezik meg.

Az alias helyi, a birtoklás távoli

Az alagútcímről tárgyalás folyik, így mindkét fél a kézfogás során megtanulja. Egy további szolgáltatáscímről egyáltalán nem tárgyalnak, ezért hozzáadása önmagában semmit sem változtat a hubon. Az ügyfél azonnal birtokolhatja a címet, és a kiszolgáló továbbra is az alapértelmezett útvonalára küldi ezt a forgalmat, vagy eldobja. Két rekordot kell létrehozni, két különböző helyen.

Az ügyfélen a cím a gazdagéphez tartozik, és a loopback a természetes otthona egy olyan szolgáltatásidentitásnak, amelynek soha nem szabad fizikai kapcsolaton megjelennie. A hubon a peer-előtag leképezés külön nyilatkozat, amelyet csak a kiszolgáló olvas. Egyik rekord sem feltételezi a másikat.

Tartsa a két tartományt külön a jegyzeteiben is. Egy példa címei dokumentációs értékek, és ezek átfedése egy valódi LAN-nal a leggyorsabb módja annak, hogy egy működő beállítás töröttnek tűnjön.

Adja hozzá a címet az ügyfélhez tartósan

Helyezze a szolgáltatáscímet a loopbackre gazdagép-előtaggal, hogy a gazdagép helyi bemenetként kezelje, ne elérendő alhálóként. ip address add 10.66.0.10/32 dev lo ezt egy címre teszi meg, és a parancs megismétlése egy második címre két szolgáltatást modellez.

Futtassa ezt egyszeri tesztként, majd helyezze át abba, ami a gazdagép hálózati konfigurációját birtokolja, mert a futásidejű hozzáadás újraindításkor eltűnik, és az ismételt csatlakozások között másolatok halmozódnak fel. A hálózat után sorolt systemd-egység az egyik lehetőség, a disztribúció hálózatkezelője a másik. Bármelyiket választja, a címnek léteznie kell, mielőtt az alkalmazás kötődik, különben a szolgáltatás a rossz socketen indul el. Ellenőrizze ip address show dev lo segítségével újraindítás után, ne a kézi parancs után.

A kötődés az címzéstől külön döntés. Egy minden címen figyelő alkalmazás olyan interfészeken fogad forgalmat, amelyeket soha nem szándékozott, ezért irányítsa a konkrét szolgáltatáscímre. Akkor a helyi bemeneti szabályzatnak van mihez pontosan illeszkednie.

Követelje meg abban a CCD-fájlban, amelyet a hub valóban olvas

A kiszolgálón a birtoklási nyilatkozat az ügyfelenkénti fájlba kerül, amelyet a hitelesített közös név választ ki, a client-config-dir által megnevezett könyvtárban. A sor iroute 10.66.0.10 255.255.255.255, címenként egy, és megmondja a kiszolgálónak, melyik peernek kell fogadnia az adott cél forgalmát.

Két részlet csendben megtöri ezt. A fájlnévnek meg kell egyeznie a kiszolgáló által valóban használt névvel, amely eltér, amikor username-as-common-name van játékban. És iroute csak TUN módban, beállított ügyfélkonfigurációs könyvtárral lép érvénybe, így ugyanaz a sor semmit sem tesz hidas telepítésben. Sorokat adjon a meglévő fájlhoz ahelyett, hogy lecserélné, mert már hordozhat fix címet vagy push-beállításokat. Az OpenVPN 2.6 referencia dokumentálja a könyvtárat és a birtoklási direktívát is.

A hub saját kernelének is szüksége van útvonalra ezekhez a célokhoz, hogy a helyben generált forgalom belépjen az alagútfolyamatba. A kiszolgáló konfigurációjában a route 10.66.0.10 255.255.255.255 lefedi a kiszolgáló által létrehozott forgalmat, míg más ügyfeleknek push "route 10.66.0.10 255.255.255.255" kell, hogy maguk tanulják meg a célt.

Az útválasztás és az engedélyezés külön marad. A küldött útvonal megmondja az ügyfélnek, hová küldje a csomagokat, és semmit sem ad; a szolgáltatásnak továbbra is el kell fogadnia a hívót a saját feltételei szerint.

Ellenőrizze a bemeneti szabályzatot és a válaszutat

Az aliasra címzett csomag helyi bemenetként érkezik a birtokló gazdagépre, így a kérdés az, hogy a helyi tűzfal engedélyezi-e ezt a forrást és portot. Engedélyezze a konkrét szolgáltatásportot a VPN forrástartományából, nehogy az egész címet megnyissa.

A válaszoknak visszaút kell a hívóhoz. A normál alagútpoolon belüli hívó számára ez az útvonal már létezik, mert az alagút-eszköz hordozza. Egy másik útválasztott hálózat mögötti hívónak az adott hálózat visszaútjára is szüksége van, és itt veszítenek csomagokat az aszimmetrikus beállítások.

Figyeljen egy második hallgatóra ugyanazon a porton, más címhez kötve, mert a kernel ahhoz a sockethez szállít, amelyik illeszkedik, és az eredmények véletlenszerűnek tűnnek. Ellenőrizze ss -lntp segítségével, és erősítse meg, hogy a kötött cím a szolgáltatás aliasa. Forrás-NAT itt nem szükséges, és hozzáadása elrejti a hívó identitását, amelytől a naplói függnek.

Tesztelje a címeket és a birtoklást külön

Tesztelje két lépésben. Először erősítse meg, hogy a birtokló gazdagép eléri a szolgáltatást az aliasán önmagából, ami elválasztja a kötési és tűzfalproblémákat az útválasztástól. Aztán teszteljen egy valódi VPN-hívóról az alkalmazás saját hitelesítésével. Amikor az első átmegy és a második meghiúsul, a hiányzó darab a hub oldalán van.

Ellenőrizze azokat a hibaállapotokat is, amelyek túlélnek egy kapcsolatot: az alias hozzárendelve marad, amikor az alagút le van állva, és a hub megtartja az útvonalát, amikor a peer hiányzik. Egyetlen objektum sem bizonyítja önmagában, hogy a szolgáltatás elérhető, ezért a kétlépéses teszt jobb egyetlen pingnél egy laptopról.