Helyek közötti VPN vagy távelérés: mit köt össze a kettő

Mindkét megoldást VPN-nek nevezik, és különböző problémákat oldanak meg. A helyek közötti alagút két átjárót köt össze, így minden mögötte lévő hoszt elérheti az engedélyezett címeket a másik oldalon anélkül, hogy bármit telepítene. A távelérési alagút egyedi eszközöket köt egy hálózathoz, egyszerre egy klienst. Az összehasonlítás azért fontos, mert a telepítési hibák többsége abból ered, hogy az egyiket konfigurálják, miközben a másik viselkedését várják, és a tünet általában időtúllépés egy olyan szolgáltatásban, amelyet az alagút valóban elért.

Két tervezés, két határ

Egyik megoldás sem terjeszt ki egy LAN-sugárzási tartományt. A túloldali eszközök nem jelennek meg a helyi felderítési listán, és ezt elvárni az első feltevés, amelyet el kell vetni. A szándékosan közzétett privát DNS-nevek kiszámíthatóbbak bármely felderítési protokollnál, és túlélik a szolgáltatóváltást.

Vegyen 10.10.0.0/24-et az egyik helyen és 10.20.0.0/24-et a másikon. Az A átjárónak olyan útvonalra vagy forgalomválasztóra van szüksége, amely a 10.20.0.0/24 előtagot az alagútba küldi, a B átjárónak pedig ennek tükörképére. Ezután a két oldal hosztjai közönséges IP-kapcsolatot használnak, és soha nem tudják meg, hogy létezik alagút. Ez a láthatatlanság a funkció, és ezért néznek ki a hibák közönséges hálózati hibáknak, nem alagúthibáknak.

A házirend-alapú és az útvonal-alapú nem ugyanaz az alagút

Házirend-alapú IPsec-telepítésben a kialkudott forgalomválasztók pontosan meghatározzák, mely forrás-cél párok védettek. Ha egy átjáró mögött új alhálózat jelenik meg, és egyetlen választó sem fedi le, az alagút továbbra is fut, és az új alhálózat egyszerűen nem kerül átvitelre. Útvonal-alapú tervezésnél egy interfész fogadja a forgalmat, és az útválasztási tábla dönt, ami az előtag hozzáadását útvonal-módosítássá teszi az alagút újratárgyalása helyett.

A StrongSwan mindkét nézetet közvetlenül megmutatja, és együttes olvasásuk az a mód, ahogy kiderítheti, melyik modellt telepítette valójában.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

Az a választólista, amelyből hiányzik az Ön számára fontos előtag, minden csomagrögzítés nélkül megmagyarázza a hibát, a rossz interfészre mutató útvonal pedig a visszaúti tükörhibát magyarázza. Olvassa el mindkettőt, mielőtt bármit újratárgyalna, mert a kulcsfrissítés nem ad hozzá olyan választót, amelyet soha nem konfigurált.

Tervezze meg a címzést az alagút előtt

Az átfedő tartományok az a tervezési hiba, amelyet konfigurációval nem lehet kijavítani. Ha mindkét hely 192.168.1.0/24-et használ, annak a hosztnak, amelynek 192.168.1.50 kell, két jelöltje van, és semmilyen módja a választásra. Az alagút hitelesíteni fog, a biztonsági társulások létrejönnek, és az útválasztási döntés ettől függetlenül hibás vagy kétértelmű lesz.

Válasszon egyet három őszinte lehetőség közül: számozza át az egyik helyet, fordítsa le az átfedő tartományt az átjárón, hogy mindkét oldal külön előtagot lásson, vagy mondjon le azoknak a hosztoknak a közvetlen útválasztásáról, és tegye közzé a szolgáltatást más módon. Mindegyiknek van költsége, és az első általában a legolcsóbb kétéves távlatban. Döntsön az alagút létezése előtt, mert utána a változás minden eszközt érint, amelyen a régi cím van.

Az MTU kérdését is korán rendezze. Az alagút csökkenti a hasznos terhelést, és a töredezésre támaszkodó tervezés másként viselkedik, mint amelyik az átjárókon rögzíti az MSS-t.

A továbbítás és a házirend az alagúton kívül van

Az átjárónak hajlandónak kell lennie csomagokat továbbítani az alagút-interfész és a LAN-interfész között, és mindkét iránynak olyan házirendre van szüksége, amely engedélyezi a szolgáltatást. Linuxon ez két külön beállítás, plusz a tűzfalszabályok, amelyek eldöntik, hogy a továbbított folyam egyáltalán engedélyezett-e.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

A fogadó hoszt egy harmadik réteget ad hozzá: a saját tűzfalának továbbra is el kell fogadnia egy klienst a távoli alhálózatból. Egy fájlszerver, amely csak a helyi /24-ét engedi, elutasítja a 10.20.0.7-től továbbított forgalmat, bármilyen egészségesnek is tűnik az alagút, és ezt az elutasítást könnyű útválasztási hibának olvasni.

Hosztról teszteljen, ne az átjáróról

Az átjáró által küldött ping más forrás-címet és más házirendet követhet, mint a továbbított felhasználói forgalom. Ez gyenge tesztté és olykor félrevezetővé teszi: sikerül, miközben az alkalmazás meghiúsul, vagy meghiúsul, miközben az alkalmazás működik.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Használjon valódi hosztot, valódi forrás-címet és az alkalmazás által használt valódi protokollt. Ezután olvassa el külön a visszaútvonalat, mert a működő előre irány visszaútvonal nélkül olyan időtúllépést eredményez, amely pontosan úgy néz ki, mint egy blokkolt szolgáltatás.

A kérdés szerint válassza ki a tervezést, amelyre válaszol: hálózatokat köt össze, vagy eszközöket fogad be? Minden más, beleértve azt is, melyik szolgáltatót konfigurálja, ebből a válaszból következik.