Egy biztonságos vpn hálózat megszervezése az opnvpn segítségével
Az én esetemben több távoli fióktelepet kellett összekötni a helyi hálózatokkal a központi irodába, és bizonyos munkavállalók munkahelyét is biztosítani kellett otthonról.
A hálózati elrendezésnek így kell lennie:
Ebben az esetben a fehér IP csak a központi irodában érhető el. mert az egyszerű beállítás, az összes művelet nem tart tovább, mint egy órát (szerverekhez) - Ahogy a proxy szerver használt számítógépeken OpenSuSE Linux.
Először telepítenie kell az OpenVPN csomagokat minden kiszolgálóra és minden olyan kliensre, amely közvetlenül kapcsolódik a fő kiszolgálóhoz.
Először tanúsítványokat készítünk az ügyfelek és a kiszolgálók számára:
másolja az easyrca szkripteket az egyik felhasználó könyvtárába,
töltse ki az állomány adatait a megfelelő értékekkel (a tanúsítványok kulcshossza és lejárati dátuma, cégnév, helyek stb.)
hajtsa végre a forrás ./vars változókat,
majd törölje az előző beállításokból következő gombokat: ./clean-all
és készítse el a root tanúsítványt: ./build-ca
Most folytathatja a kulcsok létrehozását:
a kiszolgálóhoz: ./build-key-server <имя сервера/сертификата>
az ügyfelek számára: ./build-key <имя клиента/сертификата>
mint a neve a szerver tanúsítvány célszerű meghatározni a «szerver», és az ügyfél - a név az egységet, amelyre a tanúsítvány vonatkozik (pl client_msk_timirjazevskaya, client_msk_marjina_rosha, client_spb_gorkovskaya stb)
Ezután beállítjuk a Diffie-Hellman protokoll titkosítási paramétereit: ./build-dh
Most a kulcsok mappában vannak a szükséges fájlok, amelyeket a szerveren és az ügyfeleken az / etc / openvpn mappába kell elhelyezni az alábbiak szerint:
- ca.crt - root tanúsítvány, kiszolgálónként és ügyfélenként
- ca.key - a tanúsítvány aláírásának kulcsa, hagyja a mappában a kulcsokat, és ne adja meg bárkinek :)
- dh1024.pem - titkosítási paraméterek, a szerverre
- server.crt - szerver tanúsítvány, kiszolgáló
- server.key - a kiszolgálói tanúsítvány privát kulcsát, a kiszolgálónak, a kulcs titkos
- kliens _ * .crt - az ügyfelek tanúsítványa, az ügyfelek megfelelő gépén
- kliens _ *. kulcs - az ügyfél-tanúsítványok privát kulcsja, az ügyfelek megfelelő gépén, a kulcs titok
most másolja a kiszolgáló konfigurációs fájlját a minta mappából az openvpn beállítások mappájába:
cp /usr/share/doc/packages/openvpn/sample-config-files/server.conf / etc / openvpn /
Ebben a fájlban néhány paraméterrel nem vagyunk elégedettek:
push "route 192.168.0.0 255.255.240.0" # útvonal a belső hálózathoz az ügyfelek számára
client-config-dir ccd # konfigurációs mappák az ügyfelek számára (a statikus IP hozzárendeléséhez) (create inside / etc / openvpn)
client-to-client # útvonalválasztás az ügyfelek között
up "szolgáltatás SuSEfirewall2_setup restart" # indítsa újra a tűzfalat a szolgáltatás indításakor
le "szolgáltatás SuSEfirewall2_setup restart" # és ha leállt. Mivel az eszközök,
# az openvpn virtuálisan létrehozott és csak futás közben létezik
útvonal 192.168.1.0 255.255.255.0 10.8.0.2 # útvonal a fiókhálózatba 1
útvonal 192.168.2.0 255.255.255.0 10.8.0.3 # útvonal a fiókhálózatba 2 (lásd Diagram)
# és útvonalak más ágak hálózatában.
most kell konfigurálni a tűzfalat a kiszolgáló és az ügyfelek érdekében, hogy továbbítja a kérést a VPN a belső hálózat (a kliensek nélkül belső hálózat, és nem tesz közzé semmilyen erőforrás nem szükséges) (Feltételezzük továbbá, hogy a tűzfal már be van állítva, mint egy átjáró az interneten a belső hálózat) :
akkor az összes műveletet a / network / Firewall / SuSEfirewall2 /
FW_DEV_INT adjon meg egy üres helyet az openvpn (tap0) felület után, majd adja hozzá a belső zónához
FW_ALLOW_CLASS_ROUTING int - lehetővé teszi az átirányítást a belső belső zóna interfészek között
FW_REJECT_INT nem - ne dobja el a csomagokat a belső zónából - nem feltétlenül
FW_FORWARD_ALLOW_BRIDGING yes - engedélyezi a hálózati hidakat, még akkor is, ha nincs híd típusú felület
most, mentheti az összes beállítást és futtathatja az openvpn-t (a kiszolgálókon és az ügyfeleken):
szolgáltatás openvpn start
vissza kell térnie, a készülék tap0 megjelenik a hálózati eszközök listáján
ifconfig
tap0 Link encap: Ethernet HWaddr 00: FF: A0: B4: 72: BF
inet addr: 10.8.0.1 Bcast: 10.8.0.255 Maszk: 255.255.255.0
FELSZERELÉS MULTICAST MTU: 1500 metrikus: 1
RX csomagok: 611222 hibák: 0 leesett: 0 túllépés: 0 frame: 0
TX csomagok: 539849 hibák: 0 leesett: 0 túllépés: 0 hordozó: 0
ütközések: 0 txqueuelen: 100
RX bájt: 108883515 (103,8 Mb) TX byte: 141 490 615 (134,9 Mb) tap0 Hivatkozás encap: Ethernet HWaddr 00: FF: A0: B4: 72: BF
inet addr: 10.8.0.1 Bcast: 10.8.0.255 Maszk: 255.255.255.0
FELSZERELÉS MULTICAST MTU: 1500 metrikus: 1
RX csomagok: 611222 hibák: 0 leesett: 0 túllépés: 0 frame: 0
TX csomagok: 539849 hibák: 0 leesett: 0 túllépés: 0 hordozó: 0
ütközések: 0 txqueuelen: 100
RX byte: 108883515 (103.8 Mb) TX byte: 141490615 (134.9 Mb)
az útvonalakon automatikusan regisztrálhatja a szükséges adatokat:
ip útvonalon
192.168.2.0/24 keresztül 10.8.0.3 dev tap0
192.168.1.0/24 keresztül 10.8.0.2 dev tap0
10.8.0.0/24 dev tap0 proto kernel köre link src 10.8.0.1
192.168.0.0/24 dev eth0 proto kernel köre link src 192.168.0.100
Minden beállítás munkát, és most a lehető leghamarabb az ügyfelek kapcsolódni a szerverhez, és egy virtuális helyi hálózat, mint a diagram elején a cikk, ahol biztonságosan közzé szerverek és erőforrásokat. Az internet a jövőben is működni fog, ez a rendszer a már létrehozott VPN-kapcsolatok mellett működik. Ha az ügyfelek, akik közvetlen kapcsolatban állnak a szerver segítségével NetworkManagert - szüksége van a csomag NetworkManager-openvpn az ablakok beállítás közel azonos.
miért kell eldobni az L2-et? dev tap? Mint dev tun a topológia alhálózat nem felel meg?
helytelenül definiálja a maszkot, és általában kizárja a vpn-ügyfelek alhálózatát
Mi a hiba, ahogy gondoljátok kell?
a közös terjesztések során iptables.
Itt mindenki magára dönt. 19 ember látszólag hasznos volt, de nem látok mínust tőled :)
proto tcp rugalmasabb, bár kevésbé gazdaságos.
ha 3g-ral keresztül kapcsolódik a vpn-hez, akkor ez a különbség a szem számára látható, és nem támogatja a tcp opciót. A megbízhatóságot pedig biztosítja az a tény, hogy ugyanaz a tcp már az alagút belsejében megy.
Igen, és minden port hozzá van rendelve.
a topológia alhálózattal azonos. Csak a haszontalan adatok kevesebbet keresnek.
Érvénytelen kivétel maszkot és általában nem tartoznak alhálózati a VPN-kliens Mi a hiba, mit gondol, meg kell?
Korlátozás: a belső ügyfélhálózatnak nem szabad átfednie a következő hálózatokat:
192.168.0.0/24
192.168.1.0/24
192.168.2.0/24
UPD csak az ügyfél hálózatán 192.168.0.0/28 a gazdaság nagy része fog működni. A nagyobb maszk útvonalválasztási szabálya szerint.
ha 3g-ral keresztül kapcsolódik a vpn-hez - ez a különbség a szem számára látható, és nem támogatja a tcp opciót
Folyamatosan használom a tablettát, nem látok különbséget, minden nagyon kényelmes. dev tun, topológia alhálózat, proto tcp, tun-mtu 1024.
Plusz, ha egy 3G dumpot, például az úton, újrakapcsolódás történik 10-12 másodperccel később, szemben az UDP 20-30-mal. ping költségek 10
Lehetséges még megírni, hogy a 10.8.0.0 a szolgáltató belsejében használható, és akkor is (bizonyos helyzetben)
Ez csak itt nem valószínű, mert kliens, ez a hálózat nem szükséges. És a maszkok különbözőek. A szolgáltatók ritkán használják / 24 szürke szegmensben, általában kevesebbet.
Azonban, ha jobban szeretne hazatérni a munkatársaknak, akkor állítsa be az útválasztókat - üdvözöljük. De - óra után és ingyen.
Ami az iptables-ot illeti - semmilyen módon nem találja meg az utasításokat további shellek használatára. Az összes iptables -A. Mert ez univerzális csapat, ellentétben.
De ez, sajnálom, pislogott.