Használjon az OpenVPN-ügyfélje nobindet vagy rögzített portot?

Két profil, amely egyetlen sorban különbözik, másképp viselkedik abban a pillanatban, amikor egy második ügyfél elindul ugyanazon a gazdagépen. Az egyik tartalmazza a nobind és bármely helyi portot elfogadja, amelyet a kernel ad; a másik 1194-et foglal le, és a második példány már használatban lévő címmel hal meg. Ez a sor dönti el, ki választja a forrásportot, ami viszont eldönti, hogy a profil együtt létezhet-e bármi mással a gépen. Három kérdés dönti el, és az első a legtöbb profilra válaszol, mielőtt a másik kettőhöz érne.

Mit hagy ki valójában a nobind

Alapértelmezés szerint az ügyfél a hívás előtt helyi socketet köt, és a helyi port 1194, hacsak a profil mást nem mond. nobind eltávolítja ezt a foglalást, így a verem a kapcsolat idején egy használaton kívüli portot oszt ki. Ez kivétel, nem alapértelmezés, és a sor nélküli ügyfél 1194-et tart, ezért ütközik pontosan a nem rögzített második példány. A legtöbb szállított ügyfélprofil ezért tartalmazza az utasítást, és az, hogy egy mintafájl tesz valamit, nem ugyanaz, mint hogy a mechanizmus alapértelmezésként teszi.

Ami nem változik, az a távoli oldal. A kiszolgáló továbbra is ott figyel, ahol a profil mondja, és a konfigurációban a célport továbbra is a célport. A dinamikus forrásport a saját socketed visszatérési címét változtatja meg, a kiszolgálóét nem.

Semmit sem rejt el. A nyilvános címed az, amivé az útvonal lefordítja, a csomag továbbra is áthalad a helyi hálózaton, és aki azt a hálózatot üzemelteti, továbbra is lát egy folyamot. nobind nem adatvédelmi funkció, és nem tűzfal-megkerülés.

Három feltétel, amely eldönti

Egy kérdés dönti el a másik kettőt, ezért válaszolj rá, mielőtt bármit szerkesztenél. Ha a partner kifelé hív, a többi kérdés csak finomít egy már meghozott döntést. Ha bejövő kapcsolatokat fogad, a helyi port semmilyen hangolása nem teszi elérhetővé.

Ez a partner kezdeményezi a kapcsolatot? Ha kifelé hív, a dinamikus forrásport ártalmatlan és általában előnyösebb, mert a válasz ugyanazon a folyamon jön vissza. Ha bejövő kapcsolatokra vár, a dinamikus port elérhetetlenné teszi, hacsak valami előtte közzé nem teszi a portot. Ez az egyetlen válasz választja el az összes ügyfélprofilt az összes kiszolgálóprofiltól.

Szűr-e az útvonal a forrásportra? Egy ismert portra írt szigorú szabály kifejezett helyi portot kényszerít ki, és a profilnak rögzítenie kell, melyik szabálynak felel meg. A legtöbb hálózat csak a cél szerint szűr, ezért ez a feltétel ritkább az elsőnél. Ahol érvényesül, felülírja a dinamikus port előnyét.

Több példány osztozik a gazdagépen? Egyetlen rögzített port nem szolgálhat ki kettőt közülük, és egy újraindított példány még záródó állapotban találhatja az 1194-et. A dinamikus portok megszüntetik ezt az ütközést anélkül, hogy bármi mást változtatnának. Ha erre nem tudsz biztosan válaszolni, feltételezd, hogy igen, és hagyd a kernelt választani.

Ahol a rögzített port a helyes válasz

Egyes hálózatok a cél mellett a forrásportra is szűrnek, ezért az üzemeltető olyan szabályt írt, amely csak egy ismert portról engedi át a forgalmat. A helyi port rögzítése ilyenkor helyes, és a profilnak megjegyzést kell tartalmaznia, amely megnevezi a teljesített szabályt. A rögzítés a kiszolgáló portjával való szimmetria miatt nem indok, mert a két számnak semmi köze egymáshoz. Ha a rögzítés csak azért létezik, mert egy sablonban benne volt, töröld.

Egyébként a rögzített port bajt vásárol: két ügyfél egy gépen nem tudja mindkettő tartani az 1194-et, és a második olyan hibával bukik el, amely a portra mutat, nem a profilra. Egy gyorsan újrainduló konténer ugyanabba a falba ütközik. A javítás az az utasítás, amelyet a szállított profilok már tartalmaztak.

A kiszolgáló és az ügyfél nem szimmetrikus

OpenVPN 2.6 kézikönyv helyezi nobind mellé lport, ami az érv egy sorban: az egyik lehetőség szerint a kernel választ, a másik szerint te. A dinamikus helyi port csak a kifelé hívó partnernek működik, mert a válaszoló oldal nem tudhatja előre a portot. Ezért egy ügyfélprofil kiszolgálóra másolása olyan figyelőt hoz létre, amelyet senki sem ér el.

Több hálózati interfésszel rendelkező gazdagépen a cím külön döntés a porttól. Egy adott helyi cím és egy adott port kötése két külön beállítás, és a két felső kapcsolattal rendelkező kiszolgáló általában mindkettőt rögzíti. Az az ügyfél, amely mindkettőt rögzíti, ugyanazt a merevséget vállalta minden haszon nélkül.

Az összefoglaló a szerepekről szól, nem a biztonságról: aki kifelé hív, rugalmas lehet a saját forrását illetően, aki pedig válaszol, nem. Egyik választás sem változtatja meg, mit tud meg a másik fél az identitásodról. Ezért bukkan fel az utasítás az ügyfélpéldákban és szinte soha a kiszolgáló-példákban.

Ellenőrizd a kernel által választott portot

Kapcsolódás után a socketet olvasd, ne a konfigurációt, mert a konfiguráció a szándékot mondja ki, a socket pedig azt, ami történt. A rögzítésre érdemes tények a helyi port, a távoli végpont, és hogy figyel-e még valami. Egy Linux-gazdagépen mindhárom egyetlen parancsnyira van.

ss -unp | grep openvpn
ss -lunp | grep openvpn
sudo lsof -nP -i | grep openvpn

Egy ügyfél a nobind használatával magas helyi portot és a beállított távoli portot mutat, ami a várt forma. A kiszolgáló figyelő socketet mutat a beállított portján, és ha az a socket hiányzik, a profil vagy nem figyelő, vagy nem tudott kötni. Ha létezik folyam, de nem jönnek vissza csomagok, hasonlítsd össze a választott forrásportot az útvonal bármely portszűrőjével, mielőtt szerkesztenéd a profilt. Változtass egy dolgot, kapcsolódj újra, és olvasd újra a socketet.