A feladat egyszerűnek tűnik, csak amint beleástam magam rájöttem, hogy a hálózatokhoz még mindig nem értek, és már abban sem vagyok biztos mit akarok csinálni. :) Ebben szeretnék egy kis segítséget kérni.Adott az alábbi topológia:
+----------+ (~~~~~~~~) +--------+ 192.168.1.1 (~~~~~~~~~~~~~~) 192.168.1.2 +-------------+
| Kliens 1 |===( Internet )===| Router |=============( Belső hálózat )===============| VPN szerver |
+----------+ (~~~~~~~~) +--------+ ( 192.168.1.0/24 ) +-------------+
(~~~~~~~~~~~~~~) 192.168.1.100 +----------+
#================| Kliens 2 |
+----------+
Kliens 1 egy Windows 10-et futtató gép, és alapvetően olyan megoldást szeretnék, amit az natívan támogat és megfelelő biztonságot nyújt.
A Router egy egyszerű TP-Link soho router gyári firmware-rel, lehetőleg nem szeretnék a feladat miatt routert/firmware-t cserélni (értsd: port forwardnál bonyolultabb konfigurációt végezni) rajta.
A VPN szerver egy CentOS 7-et futtató gép, libreswan 3.12-t telepítettem rá de egyelőre semmilyen konfigurációt nem végeztem. Ideális esetben ezzel szeretném a problémát megoldani, de nem zárkózom el más megoldás telepítése elől (annál is inkább, hogy ez a verzió sebezhető).
A cél az, hogy Kliens 1 a VPN szerverig kialakított VPN tunnelen elérje a Belső hálózatot, így kommunikálni tudjon Kliens 2-vel. Nem cél, hogy Kliens 2 tudjon kapcsolódni Kliens 1-hez, vagyis nem kell Kliens 1-nek feltétlenül megjelennie a Belső hálózaton. Az első kérdés: ez így egyáltalán lehetséges?
Szerk:
Valahogy úgy képzelem el hogy ennek hogyan is kellene működnie, hogy kiépül Kliens 1 és a VPN szerver között egy VPN tunnel, vagyis Kliens 1 úgy látja, hogy bekerült a 192.168.1.0/24-es hálózatra, amin eléri Kliens 2-t. A Belső hálózaton valójában a VPN szerver fogja a csomagokat továbbítani, vagyis Kliens 2 számára olyan, mintha VPN szerver kezdeményezné a kommunikációt (legalábbis IP szinten). Ezzel kapcsolatban is van egy kérdésem, mi van akkor, ha Kliens 1 már eleve egy ilyen lokális hálózaton van, a címütközések kezelésére van valamilyen megoldás? Leginkább az az érdekes, ha Kliens 1 helyi IP-je megegyezik Kliens 2 Belső hálózati IP címével.
VPN protokoll tekintetében IKEv2-re gondoltam, machine certificate-tel. A wiki alapján bekonfigurálni PITA, de elfogadható biztonságot nyújt, beállítani meg csak egyszer kell. A gondom csak az, hogy a megadott libreswan konfiguráció nem tudom, hogy nekem így megfelel-e, és ahogy értelmezem csak egyre több kérdés merül fel.
# The server's actual IP goes here - not elastic IPs
left=1.2.3.4
Ez nekem nagyon furcsa, miért nem egy interface-t kell megadni?
# DNS servers for clients to use
modecfgdns1=8.8.8.8
modecfgdns2=193.110.157.123
Ezt muszáj megadni? A Belső hálózatban nincs DNS szerver emiatt belül nincs is DNS alapú névfeloldás. Nem cél, hogy Kliens 1 a Routeren keresztül ki tudjon menni az Internetre.
Tényleg csak ennyi a konfiguráció? :) A connection nevén kívül sehol nem látok utalást IKEv2-re.
Ez a konfiguráció azt csinálja egyáltalán, amit én szeretnék?
(BTW mi a különbség a Hálózatok általános és a Hálózatok egyéb kategória között? :))
- 2276 megtekintés
Hozzászólások
Ilyen "néhány géppel érjük el egymást" mókához én egy Softether VPN-t használok, egy ideje már open source, gyakorlatilag a fél világ protokolljait beszéli (Win10-el natívan tud L2TP/IPSec-et és a Microsoft-os TCP 443-on küldjünk VPN megoldását [MS-STP vagy ilyesmi]), van hozzá szép Win-es (wine-kompatibilis) GUI-s admin felület stb.
Graf felületen ki tudod választani, hogy bridge-elni akarod (ekkor ugye Kliens 2 1 (- szerk.) látszik a hálózaton) vagy a VPN egy tényleges szeparált hálózat legyen és maga a SoftEther csináljon DHCP-t/NAT-ot (SecureNAT néven fut, tudsz route-okat is dobálni vele); én - mivel csak a VPN-en belüli gépeket akarom egymás közt elérni - bridge nélkül, engedélyezett DHCP-vel, de letiltott NAT-tal használom.
[off: Windows 10-nél graf felületről nem fogod tudni beállítani a Split tunnellinget - több fórumon is panaszkodnak erre - az %APPDATA%\Microsoft\Network\ környékén lesz a kapcsolathoz tartozó leíró fájl (azt hiszem .pbk), sima text fájl, valami IP4PreferRemote vagy ilyesmi kulcsot kell 0-ra átlőni, akkor békén hagyja a default gatewayt]
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
" Microsoft-os TCP 443-on küldjünk VPN megoldását [MS-STP vagy ilyesmi])"
Mikor utoljára néztem (fél éve) katasztrofális volt az SSTP sebessége a nativ win klienssel. Azt irták az oldalon, hogy nembaj, tedd fel a saját kliensét, de ugye igy az egész értelme veszik el, hogy beépitett win klienssel kapcsolódj. Akkor már rakhatsz openvpn-t is a kliensre, ha már kliens oldalon is telepiteni kell.
Pedig nagyon jó lenne, ha működne, az SSTP az egyik legjobb vpn protokoll, sok helyen csak emiatt kell win server, mert csak az tud SSTP szervert.
- A hozzászóláshoz be kell jelentkezni
L2TP/IpSec kényelmesen megy róla
Pedig nagyon jó lenne, ha működne, az SSTP az egyik legjobb vpn protokoll, sok helyen csak emiatt kell win server, mert csak az tud SSTP szervert.
Vésztartaléknak talán, de afaik alapvetően nagyon rossz ötlet TCP felett VPN-t csinálni.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
Nálam tökéletesen hangolja magát, eddig bármilyen netet kihajtott amin csak próbáltam, SSTP fölött RDP-n gyakran nézek filmet és tökéletes.
Amennyit a vonal bir, azt hozza.
L2TP-vel az a baj, hogy sok helyről nem működik proxy-k, tűzfalak miatt, SSTP mindenhonnan működik.
- A hozzászóláshoz be kell jelentkezni
Amennyit a vonal bir, azt hozza.
AFAIK az elméleti probléma (TCP-over-TCP meltdown) nem is akkor van vele, amikor jó minőségű az alatta levő kapcsolat, hanem ha nem :) [itt most tényleg elméleti síkon beszélgetünk, bár lehet, hogy tényleg nekiállok tesztelni, hogy a sávszél/latency/packet loss közül melyikre érzékeny, ha egyáltalán]
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
- A hozzászóláshoz be kell jelentkezni
igen elméletben ez gond, a gyakorlatban én nem láttam ilyen problémát. Pár éve még volt GPRS, na azon kellett türelem egy RDP-hez, de nem biztos, hogy a tcp meltdown miatt :)
De ma még mobilneten sem probléma ez. Mobilneten gyakran inkább az a gond, hogy nem működik csak a tcp 443.
- A hozzászóláshoz be kell jelentkezni
Nincs is jobb a NAT-olt IPSec-nél...
- A hozzászóláshoz be kell jelentkezni
Mit javasolsz helyette?
Routerben elvileg van erre megoldás, idézet a helpjéből:
VPN - VPN Passthrough must be enabled if you want to allow VPN tunnels using VPN protocols to pass through the Router.
PPTP Passthrough - PPTP Passthrough. Point-to-Point Tunneling Protocol (PPTP) allows the Point-to-Point Protocol (PPP) to be tunneled through an IP network. To allow PPTP tunnels to pass through the Router, click Enable.
L2TP Passthrough - Layer Two Tunneling Protocol (L2TP) is the method used to enable Point-to-Point sessions via the Internet on the Layer Two level. To allow L2TP tunnels to pass through the Router, click Enable.
IPSec Passthrough - Internet Protocol security (IPSec) is a suite of protocols for ensuring private, secure communications over Internet Protocol (IP) networks, through the use of cryptographic security services. To allow IPSec tunnels to pass through the Router, click Enable.
- A hozzászóláshoz be kell jelentkezni