RRAS packet filters, 22-es csapdája a VPN-ben és egyéb mókák

Adva volt egy Windows szerver, aki az egyetemi belső hálóra csatlakozik egy lábbal, másik lábbal pedig az egyik laborunk felé néz. A labornak AD-t, DNS-t, DHCP-t szolgáltat. Továbbá, VPN szerverként is funkcionál, hogy kívülről el lehessen érni egyrészt az egyetemi belső hálót, másrészt a labor privát tartományát. S hogy az élet ne legyen egyszerű, még RADIUS szerverként is üzemel egy, a labor hálózatára kötött vezeték nélküli access pointnak. Mivel nem volt ISA, ezért mindezt az RRAS-sal oldottam meg, kicsit fapados, de működött. Ment minden rendesen, csak valami tűzfal szabályokat kellett volna még beállítani, mert az RRAS letiltja a Windows beépített tűzfalát, így csak a külső lábon működött az RRAS beépített alap tűzfala. Próbálkoztam egyszer az RRAS egyszerű állapotmentes csomagszűrőivel, de nem jött elsőre össze, hogy minden menjen, így, mivel nem volt időm megkeresni a hibát, hagytam anno annyiban. Meg is lett az ára:)

image

Kedden szóltak, hogy nem sikerül csatlakozni a VPN-hez kívülről. Pár perc után kiderült, hogy a szerver a tanszéki belső hálózatból látszik, azonban annál kintebbről nem. Mi lehet? Hát szépen fogták és kitiltották az egyetemi hálóból, a megfelelő tiltó listát megnézve az indok port scan volt. No már csak ez hiányzott:) A logok alapján kiderült, hogy volt valaki a laborban, meg páran VPN-nel távolról is be voltak lépve. Ennél részletesebb log a belső hálózati forgalomról nem volt, úgyhogy a hiba okozóját nem sikerült megtalálni, de ahhoz, hogy levegyék a tiltást, meg kellett akadályozni, hogy ez máskor előforduljon. Így kénytelen voltam újra elővenni az RRAS packet filter funkcióját, és megismerkedni alaposan a működésével.

Gyorsan be is állítottam, hogy magára a szerverre a belső hálóból bármilyen forgalom jöhet (az RRAS-ban csak portot lehet megadni, port tartományt nem, viszont pár szolgáltatás a Windowsban dinamikusan rendel a kéréshez valami 1024 feletti portot, így nem volt jobb ötletem, mint hogy mehet akkor minden). Többi címre pedig csak pár portra mehet ki kérés, pl. HTTP, HTTPS, SSH, DHCP, DNS és az ICMP csomagok. A laborból tesztelve jónak is nézett ki, a szerveren látott mindent, kintre meg csak a megadott portok mehettek.

Most jött a feladat nehezebbik része, a VPN forgalom szűrése. Az első dolog, amivel szembesültem az az volt, hogy miután beállítottam a labor felé néző kártyán a szabályokat, nem kaptak a VPN kliensek IP címet. ?? Nem jöttem rá, hogy miért, pedig csak rajzolni kellett volna, meg végiggondolni, hogy pontosan mi is zajlik:) Így aztán végül a Wireshark segített, levettem a szabályokat, aztán néztem, hogy milyen csomagok mennek. Egy kis vizsgálódás után meg is lett a probléma oka. Az jó, hogy a DHCP szerver portját kiengedtem, azonban ez nem elég, ugyanis a következő zajlik le.

image

  1. Az RRAS induláskor elkér a DHCP-től annyi IP címet, ami neki kell. Így felesleges vizsgálódni a VPN kliens csatlakozásakor a DHCP csomagok kapcsán, egy RRAS újraindításkor kell nézni a hálózati forgalmat.
  2. A VPN szerver küld egy DHCP kérést. A szerver úgy van beállítva, hogy a DHCP szerver a labor felé néző lábon figyel, és az RRAS is erre a lábra továbbítja az ilyen kéréseket. Igen ám, de amikor a Labor lábra kirakja a kéréseket, akkor oda már beírja a forráshoz a saját IP címét.
  3. Tehát az a skizofrén szituáció áll elő, hogy a szerver egyben a DHCP kérés kliense és kiszolgálója is. Ezért a Labor lábra nem csak a DHCP szerver (UDP 67), hanem a DHCP kliens (UDP 68) portot is engedélyezni kellett.

Így már a VPN kliensek legalább csatlakozni tudtak, viszont elvileg a szűrő szabály nem volt érvénye rá. Vagy mégis? Le kéne tesztelni! Itt jött a nap 22-es csapdája. Ugyanis úgy tudom letesztelni, hogy nem tudok kifelé csatlakozni pl. az smtp portra a szerveren keresztül VPN kapcsolatból, ha megpróbálok elérni egy külső szervert. Igen ám, csak a VPN szerver ki van tiltva az egyetemi hálózatból, tehát a tanszéki háló és az egyetemi háló közti routeren egyébként se megy át semmi forgalom eleve tőle. Tehát ahhoz, hogy tesztelni tudjam a külső szerverek felé menő kéréseket, fel kéne oldani a tiltást. Viszont ehhez bizonyítani kéne, hogy leteszteltem, hogy szűröm a forgalmat:) Jó, mi?

Tehát VPN kapcsolatot csak a tanszéki hálózatból tudok indítani, és a "külső" szerver is csak a tanszéki hálóban lehet, odáig látok el. Megpróbáltam a tanszéki email szerver smtp portjára csatlakozni VPN kapcsolatból, és ment. Igen ám, de hiába volt beállítva, hogy a VPN kapcsolat átjáróját használja a forgalomhoz, az email szerverhez nem a VPN-en keresztül csatlakozott, hisz az a gépem fizikai IP-jével egy alhálóban van:) Újabb fejtörés, elő a route paranccsal! Az alapértelmezett route útvonalakat viszont nem lehet kitörölni, bárhogy is próbálkozunk. Így annyi maradt, hogy kézzel beállítottam egy szűkebb alhálót a gépemre, hogy a VPN szerverrel még egy hálóban legyenek, azonban az email szerverrel már ne (mázlim volt, hogy pont jó volt az IP elrendezés:). (Lehetett volna még azt, hogy a route táblához adunk hozzá egy olyan útvonalat, aminek szűkebb alhálózati maszkja van, mint az alapértelmezett útvonalnak.) No most akkor mehet a teszt, most már tényleg a VPN kapcsolaton keresztül ment a kérés, és így is simán engedte. Ez érthető is, hisz a kérés az Internal lábra megy be, a Labor lábra definiált szűrőkön nem megy át.

Most akkor lehetett újra próbálkozni a csomagszűrőkkel. Az Internalra definiált inbound vagy outbound szűrőknek nem látszott túl sok haszna. Ez érthető is, hisz ott PPTP tunnel megy, ha átengedtem az ahhoz szükséges portokat és protokollokat, akkor már vígan ment minden. Maradt tehát az utolsó lehetőség, a Remote Access Policy-ban is lehet szabályokat definiálni, itt input és output filternek hívják. Mint kiderült, az input filter a VPN kliens felől jövő forgalom, az output filter a VPN kliens felé menő. Próbálkoztam állítani, és végül sikerült egy elégé instabil állapotot elérnem, változtatgattam innen-onnan a szabályokat, hogy lássam mikor szűr pontosan, és elég random eredmény lett. Később rájöttem miért:

A Remote Access Policy-kat lehet az RRAS konzolról és az IAS konzolról is szerkeszteni. Ha nem nyomunk frissítést, mielőtt megnyitunk egy házirendet, akkor nem frissül a másik eszközben elvégzett módosítás, így látszólag a felületen teljesen elcsúszhat a két eszközből látott szabálykészlet. Tehát, szerkesszük csak az egyikből, vagy nyomjunk frissítést mindig!

Így aztán sikerült kitotózni, hogy tényleg a policy-ben megadott Input filter az, ami nekem kell, ez szépen szűr már a VPN forgalmon belül is.

Most már csak az az egy kérdésem maradt, hogy naplózza-e valahol ezeket a szabályokat az RRAS, a hibakeresést jelentősen megkönnyítette volna, ha látom, hogy melyik szabály miatt akad meg egy forgalom. Megkérdeztem a Technet fórumon, egyelőre nincs válasz.

No így leírva nem is tűnik már annyi bonyolultnak, de azért vagy 6 órám elment vele:)

Reklámok
Kategória: Tech | Közvetlen link a könyvjelzőhöz.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s