Az OpenVPN kliensei nem látják egymást: alhálózat vagy net30?

Két független hiba ugyanazt a panaszt adja. Az elsőben az egyik kliens a másikat még tunelcímen sem éri el, mert a címek nincsenek egy alhálózatban, vagy a kiszolgáló nem továbbítja a partnerek közötti forgalmat. A másodikban a ping működik, az alkalmazás eszközlistája mégis üres marad, mert a felderítés olyan broadcastra támaszkodik, amelyet a 3. rétegbeli tunel nem tud szállítani. Egyetlen ping szétválasztja őket, és a két hiba javítása egyáltalán nem hasonlít egymásra.

Egy ping két részre bontja a problémát

Egy kliensről a másik kliens tunelcímére pingeljen, nem a nevére és nem a LAN-címére. Ha ez meghiúsul, a továbbítás vagy a címzés a probléma, és a felderítés mindaddig lényegtelen, amíg ezt nem javítják. Ha sikerül, a továbbítás már működik, és ami hiányzik, az a broadcast vagy a névfeloldás.

ip addr show tun0

Mindenek előtt olvassa le a kliens interfészét, mert a hálózati maszk nevezi meg a topológiát. A /24 vagy más alhálózati maszk közös címtárat jelent; a partner címmel rendelkező /30 a régebbi pont-pont elrendezés, ahol minden kliensnek pontosan egy szomszédja van, a kiszolgáló.

net30 és alhálózat, a kliens oldaláról olvasva

net30 esetén a kiszolgáló kis blokkot ad minden kliensnek, így nem létezik útvonal egy másik kliens tunelcíméhez, hacsak a kiszolgáló nem továbbítja. Alhálózat esetén a teljes címtár egy hálózat, minden kliens elérhet minden másikat, és a kiszolgáló továbbít közöttük. Ezért tűnhet egy kiszolgálókonfiguráció egészségesnek, miközben a partnerek közötti ping meghiúsul: semmi sem hibás, a kliensek egyszerűen nincsenek egy hálózatban. A kliens működő kapcsolatot és nem válaszoló partner címet lát, ami tűzfalnak tűnik, de valójában címzési elrendezés.

A direktíva átállítása kiszolgálóoldali szerkesztés és újraindítás, és a következő kapcsolatra érvényes, nem a már nyitott munkamenetekre. A változás megítélése előtt csatlakoztassa újra a klienseket. Ha egy eszköz webes felületről újragenerálja a konfigurációt, jegyezze fel a direktívát, a fájlt és a dátumot, és a szerkesztést a felületen keresztül végezze, ha van ilyen, mert az újraépítés a következő mentéskor felülírja a kézi szerkesztést.

a client-to-client külön kapu

Még egy alhálózaton belül is eldobja a kiszolgáló azokat a csomagokat, amelyek egy klienstől érkeznek és egy másiknak vannak címezve, kivéve ha a client-to-client be van állítva. Ez a kulcsszó továbbítóvá teszi a kiszolgálót a partnerek forgalma számára ahelyett, hogy csak elfogadó végpont lenne. Ez a második feltétel, amelyet az emberek a topológia javítása után kihagynak.

Ez nem terjed ki a broadcastra. A beállítás unicastot továbbít a kliensek között; nem teszi a tunelt közös szegmenssé, és semmilyen mennyisége nem juttat el egy multicast felderítési lekérdezést minden partnerhez.

TUN és TAP, és mit tud szállítani mindegyik

Egy tap eszköz LAN-ba hidálása a távoli klienseket az iroda broadcast tartományába helyezi, ami teljesen megoldja a felderítést. Az ár a TAP-ot nem megvalósító platformok, a kiszolgálón léteznie kellő híd, és egy hibaterület, ahol az irodai kábel broadcast vihara minden távoli hordozható gépet elér.

Két vagy három munkaállomásnak, amelyeknek névfeloldás kell, a hosts bejegyzés vagy az unicast cím sokkal olcsóbb, mint egy híd. Akkor nyúljon a TAP-hoz, amikor egy nem helyettesíthető protokoll a 2. rétegbeli felderítéstől függ, és nem előbb.

Ugyanazon alhálózat kliensei híd nélkül

A LAN tartományból adott cím nem teszi a klienst a kábelre. A kiszolgáló a tunel és az Ethernet között útvonalválaszt, így az adott cím ARP-ja a kiszolgáló interfészénél megáll, és a LAN többi része soha nem tudja meg, hol lakik.

ip neigh add proxy 10.50.1.250 dev eth0

A Proxy ARP bezárja ezt a rést azzal, hogy a kiszolgáló a kliens nevében válaszol. Egy tartományhoz a parpd kezeli a bejegyzéseket, ahogy a kliensek jönnek-mennek, míg a sysctl net.ipv4.conf.eth0.proxy_arp=1 minden máshová irányított dologra válaszol, ami elég széles ahhoz, hogy saját meglepetéseket teremtsen egy forgalmas szegmensen.

Bármelyik utat választja, távolítsa el a NAT-ot a tunel és a kábel között. A MASQUERADE szabály pontosan azt a címzési kérdést rejti el, amelyre válaszolni próbál. A következő embernek olyan topológiát is hagy, amelyről az nem tud a kliens oldaláról gondolkodni.

Mielőtt bármit módosít, rögzítsen egy kísérletet a kiszolgálón a tcpdump -ni tun0 paranccsal, és erősítse meg, hogy a partner csomagja egyáltalán megérkezik-e. Megérkezik és eldobják: ez a client-to-client felé mutat; soha nem érkezik meg: ez a topológiára vagy az útvonalválasztásra. Az OpenVPN 2.6 kézikönyve dokumentálja mindkét kulcsszót és az alapértelmezett topológiát, amit érdemes a saját verziójával összevetni, mielőtt egy fórumbejegyzésből sort másol.

• A tun interfész címtármaszkot mutat, nem /30-as partnerpárt.
• A másik tunelcímre küldött közvetlen ping sikerül, mielőtt a felderítést tesztelné.
• A kiszolgálókonfiguráció tartalmazza a client-to-client beállítást, amikor a partnereknek csomagot kell cserélniük.
• Nevezze meg a tesztelt felderítési protokollt ahelyett, hogy azt mondaná, az alkalmazás meghiúsul.
• Csak akkor használjon TAP-ot, ha a csoport minden kliensplatformja támogatja.
• Tartsa a NAT-ot a tunel és a LAN közötti útvonalon kívül, amikor az azonos alhálózaton belüli elérés számít.