Kell minden OpenVPN-peernek remote sor? Nem egészen
a remote megadja, hová megy az első csomag; nem választja ki a kliens-, szerver- vagy TLS-szerepet. Olvassa el az elrendezést, mielőtt mindkét oldalra másolja.
Két peer-konfigurációt hasonlítanak össze egymás mellett, az egyikben van remote sor, a másikban nincs, és a következtetés az, hogy az egyik hibás. Ez a következtetés elég gyakran téves ahhoz, hogy érdemes legyen szétszedni. Az utasítás leírja, hová kell küldeni az első csomagot. Nem választja ki, hogy a folyamat kezdeményező kliensként vagy várakozó átjáróként működik-e, és nem dönti el, melyik fél bizonyítja az identitását a másiknak.
Mit határoz meg valójában a remote
A remote bejegyzés egy gazdagépet, opcionálisan egy portot és egy átvitelt, valamint opcionálisan több ilyen bejegyzést nevez meg, amelyeket sorban próbálnak ki.
Hiányának meghatározott, nem meghatározatlan jelentése van: a folyamat vár, és nem cselekszik egy címről érkező csomagokon, hacsak az a peer nem hitelesíti magát. Ezért a barangoló felhasználókat kiszolgáló átjárónak nincs oka előre megnevezni közülük senkit.
Olvassa a bejegyzést címviszonyként. Hogy a távoli vég megbízható-e, arra a tanúsítványok és az ellenőrzési beállítások válaszolnak, nem az, hogy egy címet leírtak.
Három elrendezés dönti el a választ
A barangoló kliensnek cél kell, mert kezdeményeznie kell, és anélkül nem tudja, hol van az átjáró. A többklienses átjárónak nincs szüksége felhasználónkénti célra, mert a kliensek megérkeznek és hitelesítik magukat. Egy szándékos kétpeer-es kapcsolat ismert végpontokkal rendelkezhet céllal az egyik oldalon, mindkét oldalon vagy egyiken sem, attól függően, melyik fél kezdeményez.
Egy rögzített klienscím beillesztése egy általános átjáróba az a hiba, amely e kategóriák figyelmen kívül hagyásából következik. Működik az egyetlen peer esetében, amelynek címét rögzítették, és mindenki mást félrevezet.
Semmi az utasításban nem alakít egy konfigurációt többklienses szerverré, és semmi a jelenléte nem akadályoz szerver szerepet. Az OpenVPN 2.6 referenciája külön dokumentálja az opcionális argumentumokat és a remote nélküli viselkedést, ami utalás arra, mennyire függetlenek.
| Arrangement | Needs a destination |
|---|---|
| Roaming client | Yes, which gateway to contact |
| Multi-client gateway | No, peers authenticate on arrival |
| Two known peers | Depends on which side initiates |
Az átviteli szerepek más tengely
TCP esetén az egyik fél vár, a másik tárcsáz. Ezek a céltól különálló utasítások, és összekeverésük olyan párt eredményez, amelyben mindkettő vár vagy mindkettő tárcsáz.
Létezik TCP-forrásszűrő szerep is, ezért hibás az a lapos kijelentés, hogy egy szerver soha nem tartalmazhat remote-ot.
UDP esetén nincs kapcsolat, amit létre kellene hozni, ezért mindkét vég a megfelelő UDP-átvitelt használja, és az utasítás csak azt mondja meg, hová kell célozni. Egy hitelesített peer címváltozásait dedikált viselkedés kezeli, nem további bejegyzések hozzáadása. Az átvitel helyes beállítása előfeltétele annak, hogy a cél jelentsen valamit, és a kettő összekeverése olyan konfigurációkat eredményez, amelyek hihetőnek tűnnek, és soha nem fejeznek be egy kézfogást.
Miért nem nyitott ajtó a hiányzó remote
A cél nélküli folyamat továbbra is elutasítja azoknak a peer-eknek a forgalmát, amelyek nem hitelesítik magukat, és éppen ez az a rész, amit az emberek kihagynak, amikor a hiányzó sort mindenki számára nyitott figyelőként olvassák.
A hitelesítés és a cél független, és a bizalom szempontjából az első számít.
A fordított hiba veszélyesebb. Egy rögzített forráscím hozzáférés-vezérlésnek tűnhet, mert konkrét és könnyen ellenőrizhető, de semmit nem bizonyít arról, ki van a másik oldalon. Tartsa meg a tanúsítvány-ellenőrzést és azokat az identitásellenőrzéseket, amelyek a tanúsítványt a szerepéhez kötik. Ezek címegyezéssel való helyettesítése valódi kontrollt cserél annak látszatára.
Írja le, mit feltételez a konfiguráció
Mindkét oldalhoz jegyezzen fel három dolgot: hogyan éri el az első csomag a peert, melyik fél fogadhatja el az átvitelt, és mit ellenőriz mindkét fél a másikról.
Ezek a feltételezések a tervezés. Az utasítások csak a helyesírásuk.
Ha a két fájl eltér, ellenőrizze, hogy különböző feltételezéseket fejeznek-e ki, ahelyett hogy azt feltételezné, az egyik hibás. A szimmetrikus fájlpár sem nem szükséges, sem nem elégséges egy működő alagúthoz, és az aszimmetria gyakran az a rész, amely működőképessé tesz egy topológiát.