Jelentkezett a főnököm, hogy mi a helyzet a Windows Server 2012-es átállásunkal. Én balga elkezdtem vele beszélgetni. Mondtam, hogy a két DC kész van, a FSMO role-okat átbillentettem. Mondta, hogy látni szeretné. Kiderült, hogy az OpenVPN-je nem működik. Miután ezt a kollégám csinálta és még nem tudok eleget róla nem akartam hibakeresni este 7 felé. Mondtam neki, hogy ott a PPTP ami még félkész (DirectAccess-t kell összeraknom, de ha már az ott lesz akkor miért ne menjen rajta más VPN kapcsolat is). Mondtam 2 perc, összerakom. A 2 percből 3 óra kínszenvedés lett.
Az Amazon security policyban ügyesen a 1723-as UDP portot állítottam be a TCP helyett. Amikor erre rájöttem még mindíg problémás volt a kapcsolódás.
Gondolkoz gondolkoz.
A hálózat amiről beszélek a VPC (Virtual Private Cloud) LAN-ja (egy internettől elzárt 10-es IP tartomány)
Az Amazon egy fura szerkezet. Láthatóan minden interface routolt. A DHCP a sajátjuk, ha egy interface-hez nem állítok be egy címet a webes felületen akkor, ha fejem tetejére állok sem fog azon kommunikálni a gépem. Elkezdtem csalni. A VPN szerver hálózati interface-ére felvettem annyi másodlagos IP-t amennyit engedett (összesen 3-at). Az RRAS-on ki akartam kapcsolni a DHCP-t nem ment, az opció szürke. Keresgélek, kiderül, hogy ezt valami policy-ból kapja amit a DirectAccess management felületén lehet állítgatni. Ok. Kikapcsolom ott és megadom neki a static poolnak azt a három másodlagos címet.
Kapcsolat próba.
Beengedi a klienst. Hohó béke van. Működik. Lejelentem a főnöknek - lémer :-(
Főnök jelzi, hogy kapcsolódni ugyan tud, de a belső gépeket nem látja.
Próbálok pingelni. A VPN szerver LAN oldali lábáig jutok. Azt még tudom pingelni, tovább semmit.
Feladom. Este 9 nem akarok már ezzel foglalkozni, a dolog amúgy sem volt se fontos se sürgős. Jelzem, hogy ha nem baj másnap folytatnám.
Második nap:
Elkezdek Netmont telepíteni a kliensre is a szerverre is. Rájövök, hogy tulajdonképpen nem kötelező nekem a static poolt ugyanarról a hálóról osztanom. A routing tábla piszkálásával (az amazon routing táblájáról beszélek) oda tudom irányítani a forgalmat, nem kell hozzá a másodlagos IP címes dolog.
Megcsinálom így. Nem megy.
A kolléga mondja, hogy neki van erre egy ötlete. Állít valamit a szerveren. Változás nincs.
Elkezdem nézni az egészet a NetMonnal. Kiderül, hogy a kliensről a csomag szépen elmegy a LAN-on lévő szerverig, majd onnan vissza is jön és a VPN szervernél eltűnik a levegőben. Ez egyértelműen az RRAS körüli routing hibára utal, hiszen az Amazonon minden irányban keresztül mentek a csomagok.
Kínomban próbálok RDP-vel is kapcsolódni, hátha csak az ICMP-vel van baja. Valami "bad checksum" üzenetek vannak a NetMonban. Ennek nem tulajdonítok különösebb jelentőséget, elvégre még a ping sem megy.
További kemény guglizás. Semmi értelmes. Valahol azt olvasom, hogy az off-lan IP tartományhoz fel kell venni egy címet a hálókártyára másodlagos címet. Felveszem, nincs változás.
Elkezdek a technetklub fórumon kérdezősködni. Semmi értelmes válasz.
Feladom. Más munkám is van.
A főnököm kérdezi, hogy mi ezzel a helyzet. Mondom, hogy még mindíg nem megy és a CRM költségkalkulációt csinálom. Válasz: Jó, a CRM fontosabb. Huhh.
Második nap (este):
Újra nekiugrok. Elkezdek felúzni egy második VPN szervert. Próbálnék összehozni egy kéthálókártyás konfigot (RRAS standard verzió, hátha a NAT-os dologgal van baja). Ez sehogy sem megy. Ha kirakom a netre akkor nem tudom belógatni a VPC-be. Ha a VPC-be rakom akkormeg nem tudok neki közvetlenül internetes címet adni, csak NAT-on kersztül. Végülis felhúzok valamit, amiről kb. a második újraindítás után kiderül, hogy nem tudom többé elérni (RDP only mizéria). Lezúzom.
Újrakezdem az egészet. Marad az egy hálókártya. Próbáljunk meg egy tiszta állapotot, hátha a DirectAccess-es konfig a gond. Mire odajutok, hogy a gép felrakja a security fixeket, nagyon késő van. Másnap folyt köv.
Harmadik nap:
Befejezem a második VPN gép konfigurációját. Csak az RRAS, nincs DirectAccess. A helyzet ugyanaz. Sőtt még rosszabb. Itt még vissza sem jönnek a csomagok a LANon lévő belső szervertől.
Nézem jobbra, nézem balra, semmi. Örjöngök. Két percre vagyok tőle, hogy lezúzzam az egészet és felrakjak egy linuxos PPTP-t.
Szólok a kollégának, hogy nézze meg. A két VPN szerveren ugyanaz van beállítva, ugyanúgy van a routing összerakva. Az egyiknél visszajönnek a csoamgok a LANos gépektől, a másiknál nem. Nézi-nézi, majd eszébe jut valami. Most derül ki, hogy mit állított az előző napon.
Itt kérem security van. A rendszer ellenőrzi, hogy a bejövő és a kimenő IP forgalom megfelel-e a konfiguráltnak. Ezt ki is lehet kapcsolni. Itt ki is kell az off-lan tartomány miatt.
Hurrá. Mostmár mindkét VPN szerveren visszajönnek a csomagok a LAN-ról.
Mit oldott ez meg? Kb. semmit. Ettől még nem megy a VPN.
Feladom. Dél van, el kell mennem elintézni valamit.
Visszajövök és elkezdek AD FS-el, O365-el, Exchange és CRM migrációval foglalkozni. Ezek messze fontosabbak.
Kicsit később még bevillan valami. Mi van akkor, ha annak a NetMonban látott "bad checksumnak" mégis van jelentősége.
Gugli.
Látok olyan bejegyzéseket, hogy más is tapasztalt ilyesmit az Amazon EC2-ben, de azok átmeneti jelenségek voltak és hardver hibára utalnak. Emlegetnek még holmi checksum offload-ot, meg a hálókártya beállítgatásait. Nézzük meg, fájni nem fáj. Irány a Device Manager.
Nézd már, itt van egy olyan beállítás, hogy "Correct TCP/UDP Checksum Value". Ezek tudnak valamit. Ezek szerint el szokott romlani amit javítani kell. Kapcsoljuk be!
És minden elkezd működni.
Épp a Microsoft/Citrix/Amazon jó édes nénikéjét szidom felváltva. Azt, hogy melyik a tettes nem tudom, de ez egy csúnya nagy BUG (jó-jó tudom: feature).
