MOLEHAND Solutions - Nagyvállalati megoldások mindenkinek

 
Nyomtat  
Author: MOLEHAND Created: 2008. 09. 26. 23:33
Hálózat

By Kálmán Dávid on 2015. 07. 24. 1:57

Web Forgalom Ellenőrzése

Rendszer működése: A mikrotik routeren beállítjuk hogy egy megadott ip címre küldjön ki minden rajta áthaladó csomagot, amit mi wiresharkkal elfogunk és lementünk csv fájlba amit meg majd beimportálunk egy access adatbázisba ahol elemezhetjük.

Szükséges dolgok: Mikrotik Router, Wireshark, Microsoft Access

Routeren szükséges beállítások

  • Routeren a Tools > Packet Sniffert válasszuk ki
  • General fülön legyen bepipálva az only headers (csak a fejléceket vizsgálja)
  • streaming fülön a streaming enabled (a megadott ip címre küldi a megadott interfészen átmenő forgalmat)
  • server-hez írjuk be azt az ip címet amire küldeni akarjuk a router megadoot interfészein átmenő forgalmat
  • filter fülön állíthatjuk be mely interfészekről küldje az adatot a szerverünk felé
  • az ip address-nél vehetjük fel hogy mely gépeket vizsgáljuk vagy mely gépeket zárjunk ki, a kizáráshoz tegyük be a kis felkiáltó jelet
  • port résznél állítsuk be hogy mely portokat figyelje
  • direction az rx a kimenő forgalom, a tx a bejövő
  • DHCP dinamikus kiosztáskor érdemes automatikusan egy mentést csinálni a routeren, ehhez scripteket kell írni
  • ezt a system > scripts menüből érjük el
  • az új scripthez menjünk a + jelre, és a source írjuk be a parancsot, ez most legyen az
  • /ip dhcp-server lease print detail file=lease1.txt ami lease1.txt néven elmenti a kiosztásokat
  • időzített futtatásához menjünk be a system > scheduler a + jellel hozzunk létre új feladatot
  • interval dobozban megadhatjuk hogy milyen gyakran fusson
  • on eventnél azt hogy milyen scriptet futtasson
  • ezt mi most a /system script run script1 paranccsal csináljuk
  • Ezzel a routeren beállítottunk mindent.

    Wireshark beállítása

  • A szerverre tegyük fel a Wiresharkot és az Accesst.
  • wiresharkban állítsuk be a nézet fülön az időformátumot utc-re és a névfeloldásokat pipáljuk be szintén ebben a menüben
  • a capture > optionsben választhatjuk ki hogy mely hálókártyán áthaladó forglamat figyelje
  • lejjebb beállíthatjuk hogy milyen időközönként hozzon létre új fájlt és azt is hogy menniy idő vagy darab fájl után álljon le a csomagok elfogása
  • ezt lehet automatizálni egy wireshark.bat fájllal:
  • "C:\Program Files\Wireshark\tshark.exe" -i "Helyi kapcsolat" -t u -b duration:600 -a files:72 -w "C:\Users\molehand\Desktop\WebTraffic\200Packets.pcapng" -F pcapng -W n -N m -N n
  • -i :melyik hálókártyát használj
  • -t milyen időformátumba mentse
  • -b duration: milyen időtartamonként hozzon létre új fájlt (ms)
  • -a files: hány db fájl után álljon le a batch
  • -w hova mentse a fájlt
  • -F milyen formátumot használjon
  • -W n: elmenti a névfeloldásokat
  • -N m: maccím feloldásokta ment
  • -N n: hálózati cím feloldásokat ment
  • a batch file automatikus futtatását a feladat ütemezőben tudjuk beállítani
  • ezzel létre fognak jönni fájlok amiket ha újra megnyitunk a wiresharkban akkor a file > export packet dissecton menüben csv fájlba ki tudjuk exportálni, ami az accessben vagy más adatbáziskezelő rendszerben megnyitható és beimportálható
  • Access használata

  • Az Access-nek 2GB adatbázis határa van, így viszonylag kevés adatot tudunk elemezni a forgalomhoz képest az Accessben
  • Az Accessbe importálás menete:
  • hozzunk létre egy új adatbázist, majd menjünk a külső adatok szalagra és ott válasszuk a szövegfájlt
  • tallózzuk be a csv fájlunkat majd ok
  • válasszuk alul a speciális gombot és a kódolást állítsuk UTF-8-ra valamint a tizdesjelre írjunk be egy . majd OK
  • utána pipáljuk be hogy az első sor tartalmazza a neveket
  • a következő oldalon választhatjuk ki hogy milyen oszlopokkal akarunk dolgozni
  • és az utolsón pedig ellenőriztethetjük az adatbázist az Acces-sal hogy mennyire redundáns
  • Ha adatismétlődések lesznek, felajánlja nekünk az Access hogy az ismétlődést tartalmazó sorokat külön táblába szedje, ezt érdemes megcsinálni, az Access a végén felosztja a táblát és könnyen kereshető lesz benn sql nélkül is

    By Szeifert Gergő on 2015. 04. 17. 15:55

    Van az úgy, amikor egy jól működő rendszerhez nem kell hizzányúlni, és amikor azt gondoljuk be tudunk lépni a management felületére, kiderül, hogy mégsem.
     
    Erre megoldás az alábbi néhány lépés:
    1. Nyissuk meg az UniFi controllert (amikor telepítettük a vezérlő alkalmazást, akkor egy ikont tett ki az asztalra, egyébként pedig: /Users/[username]/Ubiquiti.../)
    2. Töltsük le a mongoDB fájt és tegyük az asztalra.
    3. Nyissuk meg a mongoDB mappát.
    4. Nyissunk egy parancssoros ablakot admin módban, és navigáljunk el a "/bin" mappáig (pl.:/Users/[username]/Desktop/mongodb-osx-x86_64-2​.2.3/bin)
    5. Mielőtt ide bemennénk írjuk be az alábbit a "/bin" után: /mongo --port 27117
    6. Írjuk be: use ace
    7. Majd: db.admin.find()

    A 7. lépésben lévő fájlból kiíródnak a belépési adatok a parancssorba.

    By Nikolett Tóth on 2015. 02. 25. 21:49

    A VPN 800-as Hiba leírások alapján sok problémát takarhat. Ami nekem segített:
     
    Amennyiben VPN-en keresztül szeretnénk csatlakozni egy hálózathoz WiFi-vel csatlakoztatott eszközről (laptopról) és ezt a hibát kapjuk vissza, két lehetséges megoldást is megpróbálhatunk:
    - Csatlakozzunk kábelesen a hálózathoz és próbáljuk meg így létrehozni a kapcsolatot
    - Ha kábelen keresztül működik, akkor frissítsük a WiFi driverét és próbáljuk meg úgy.

    By Szeifert Gergő on 2015. 02. 20. 11:14

    Bizonyos esetekben szükség van a LAN kártya hardver azonosítójának változtatására.
     
    Két gyors megoldással lehet ezt megvalósítani:

    1. Eszköz kezelőben kikeressük a LAN kártyát, majd jobb klikk tulajdonságok -> Specíális -> Hálózati cím (Network Address) -> Az értéket írjuk be ":" és "-" nélkül. -> Indítsuk újra a számítógépet.

    2. regedit

    1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}
    2. Itt több "00xx" mappát látunk. Válasszuk ki azt amelyik a szóban forgó LAN kártyát "tartalmazza".
    3. A mappán jobb klikk majd adjunk hozzá egy új "string Value"-t az alábbi értékkel "NetworkAddress"
    4.  Nyissug meg au új bejegyzést és írjuk be az új MAC címet ":" és "-" nélkül.
    5. Indítsuk újra a számítógépet.

    By Halász István on 2014. 10. 09. 6:41

    1. Töltsük le a programot innen, és installáljuk fel a szerverre úgy, hogy bepipáljuk az OpenSSL Utilities-t és a Certificate Management Scripts-et is.

    2. Indítsunk egy rendszergazdai parancssort és navigáljunk a C:\Program Files\OpenVPN\easy-rsa mappába. (A kiadandó parancsokat félkövérrel írom.)

    3. init-config
    4. notepad vars.bat

    5. Állítsuk át az elérési utat rövidnevesre. Előtte teszteljük, hogy jó helyre mutat-e:
      HOME=c:\Progra~1\OpenVPN\easy-rsa

    6. Állítsuk át 2048 bitre a kulcsméretet
      set KEY_SIZE=2048

    7. Szerkesszük az alábbi sorokat értelemszerűen:
      set KEY_COUNTRY=US
      set KEY_PROVINCE=CA
      set KEY_CITY=SanFrancisco
      set KEY_ORG=OpenVPN
      set
      KEY_EMAIL=mail@host.domain

    8. Mentsük a fájlt, és lépjünk ki a notepadből. Már backupolhatjuk is ezt a fájlt, hogy véletlen törlés esetén ne kelljen újra belőni.

    9. vars
    10. clean-all

    11. Ezután akár érdemes is átnevezni a clean-all.bat-ot pl. clean-all.ba_-ra, hogy ne tudjuk véletlenül kitörölni a tanúsítványokat egy mozdulattal.

    12. build-ca
      Amikor bekéri a script, adjuk be a paramétereket. A default praméterek szögletes zárójelben vannak.
      Ha a default paraméter megfelel, csak Entert kell nyomni.
      Üres stringet úgy tudunk megadni, ha egy pontot írunk, és utána Entert nyomunk. Az OU és a Name nyugodtan lehet üres string, a Common Name az igazán fontos, annak kell egyedinek lennie.
      Ebben a lépésben érdemes Common Namenek "Cégnév-CA"-t megadni.

    13. build-key-server
      Ezzel a paranccsal hozzuk létre a szerver tanúsítványát.
      A build-key parancsok paramétere lesz a fájl neve (jelen esetben .crt, .key, stb.)
      A Common Name nyugodtan lehet szintén .
      A sign the certificate? kérdésnél y és enter
      A commit? kérdésnél y és enter

    14. build-key-pass mike-laptop
      Ezzel a paranccsal hozzuk létre a kliens tanúsítványokat. Ebben a példában Mike laptopjához csinálunk egy tanúsítványt, méghozzá egy jelszóval titkosítottat, mely jelszót az első lépésben be fog kérni a script.
      Lehetőség van rá, hogy jelszó nélküli tanúsítványt hozzunk létre, ekkor az adott gépen nem lesz szükség jelszó megadására a VPN-hez való csatlakozáshoz, szimplán a tanúsítvány szolgál majd azonosításra. Ehhez a build-key mike-laptop parancsot kell használjuk.

    15. build-dh
      Generáljuk le a Diffie Hellman paramétereket.

    16. cd C:\Program Files\OpenVPN\bin
    17. openvpn --genkey --secret ta.key

    18. Másoljuk a létrejött ta.key-t a keys mappába (hogy később meglegyen), valamint tegyük a Config mappába a másik négy konfigurációs fájllal (ca.crt, .crt, .key, dh2048.pem) együtt.

    19. Keressük meg a minta config fájlokat. A következő lépésekben ezeket editáljuk majd.
      Start Menu -> All Programs -> OpenVPN -> OpenVPN Sample Configuration Files
      A parancsok előtti ; szintén "kommentet" jelöl, azaz ezeket a sorokat nem veszi figyelembe a program!

    20. Nyissuk meg a server.ovpn-t, és állítsuk be az alábbi sorokban az elérési utakat az alábbiakhoz hasonlóan, majd mentsük el a Config mappába a végeredményt.

      ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
      cert "C:\\Program Files\\OpenVPN\\config\\hspsrv.crt"
      key "C:\\Program Files\\OpenVPN\\config\\hspsrv.key"
      dh "C:\\Program Files\\OpenVPN\\config\\dh2048.pem"
      tls-auth "C:\\Program Files\\OpenVPN\\config\\ta.key" 0

      A tls-auth direktíva használata nem kötelező, de érdemes használni. Segítségével az összes SSL/TLS handshake csomag integritását ellőrzi a program kapcsolódáskor. Azaz titkosítja ezzel a kulccsal, és ha a másik oldalon nem stimmel a kicsomagolás, akkor eldobálja a csomagokat. (Csak egy példa: amelyik szerver esetén ez be volt kapcsolva, ott nem lehetett a Heartbleed hibát kihasználni...)

    21. Figyelembe ajánlott, opcionális szerver konfigurációs parancsok (a használatukhoz kommenteljük ki őket):

      push "route 172.20.20.0 255.255.255.0"
      A szerver LAN ip tartományáról szerezhetnek így tudomást a kliensek.

      push "redirect-gateway def1 bypass-dhcp"
      Azt mondjuk ezzel a kliensnek, hogy minden internetnek szánt csomagot a VPN kapcsolaton keresztül küldjön. Ahhoz, hogy ki is lásson a kliens az internetre a VPN szerveren keresztül, extra konfigurációra van szükség a szerver oldalon, amelynek utána kell nézni.

      push "dhcp-option DNS 208.67.222.222"
      push "dhcp-option DNS 208.67.220.220"
      push "dhcp-option WINS 10.0.0.100"
      No comment. :)

      duplicate-cn
      Ha egy tanúsítvánnyal többszörös párhuzamos kapcsolódást is szeretnénk engedélyezni, ezt a direktívát kell használjuk.

    22. A client.ovpn-nnel hasonlóképp járhatunk el, azonban macerás elmagyarázni az ügyfélnek, hogy ezt a sok fájlt másolja be ide, ha 64bites a gép, akkor meg oda. Szerenécsere van egy szebb megoldás, be lehet az ovp fájlokba építeni a cert-eket/kulcsokat, így egy db fájlunk lesz kliensenként. Ekkor töröljük ki az elérésí utas sorokat, és az alábbi struktúrába másoljuk bele a notepaddel megnyitott fájlokból a megfelelő részeket:


      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----


      -----BEGIN CERTIFICATE-----
      ...
      -----END CERTIFICATE-----


      -----BEGIN ENCRYPTED PRIVATE KEY-----
      ...
      -----END ENCRYPTED PRIVATE KEY-----


      -----BEGIN OpenVPN Static key V1-----
      ...
      -----END OpenVPN Static key V1-----


    1. Ha az elérési utas megoldást választottuk, akkor a kliens konfigokban a tls-auth direktíva 1-esre végződik (ezzel jelezzük, hogy ez a kliens oldal):
      tls-auth "C:\\Program Files\\OpenVPN\\config\\ta.key" 1

      ha pedig a kulcs "beépítést", akkor a következő sort kell hozzáadnunk a konfighoz:
      key-direction 1

    2. Meg kell még adnunk a kliensnek, hogy hol találja a szervert, és melyik porton:
      remote molehand.eu 1194

    3. remote-cert-tls server
      Amennyiben egy rosszindulatú személy megszerezne egy kliens konfigot, akkor az ahhoz tartozó tanúsítványokat szerver üzemmódban is tudja futtatni, és így man-in-the-middle támadást tud létrehozni, amikor is azt hiszed, hogy a céges VPN szerverhez csatlakozol, miközben az ő szerverként futtatott kliens konfigjához. A build-key-server és build-key scriptek "megjelölik" a tanúsítványokat, hogy "kérem ez a tanúsítvány szervernek / kliensnek lett létrehozva". A fenti direktívával biztosra mehetünk, csak "szerver" azonosítójú tanúsítványhoz lesz hajlandó a kliens csatlakozni.

    4. Ezzel a konfig fájlokkal végeztünk, másoljuk be őket a config mappába. Ehhez a klienseken is telepítsük fel az OpenVPN-t (az OpenSSL Utilities és a Certificate Management Scripts ezeken nem fog kelleni). Ne lepődjünk meg, a kliens és a szerver telepítő teljesen ugyanaz, csak a konfig fájlok döntik el, hogy egy gép szerverként vagy kliensként viselkedik.

    5. Nyissuk ki a routeren az OpenVPN portot, ill. forwardoljuk.
      Alapból ez az UDP 1194-es port.

    6. Ha el kell érni a LAN-t a VPN-en keresztül, azaz használjuk az alábbi direktívát
      push "route 172.20.20.0 255.255.255.0"
      egy statikus útvonalat is fel kell venni a routerben, hogy a csomagok visszataláljanak:
      route add 10.8.0.0 mask 255.255.255.0  metric

      Ezen kívül szükség van még egy dologra: az OpenVPN szervernek is kell tudnia route-olnia, hogy a VPN hálózatból a LAN hálózatba átforgassa a csomagokat és vissza. Ezért amennyiben nem működik a kapcsolódás a LAN-ra a fenti beállítások elvégzése után, úgy a következő registry módosítást kell eszközöljük:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters

      Itt az IpEnableRouter bejegyzést állítsuk 1-re (ill. hozzuk létre, ha nincs).

    7. A szerveren a szolgáltatások között keressük meg az OpenVPN service-t, állítsuk Automatikus indulásúra, és indítsuk is el.

    8. A klienseken az OpenVPNGUI parancsikonnal tudjuk indítani.

      Abban az esetben, ha van a usernek rendszergazda joga, állítsuk be a parancsikont, hogy mindig rendszergazdaként indítsa a GUI-t. Erre azért van szükség, mert az útvonal hozzáadáshoz rendszergazda jogokra van szükség Windows alatt.

      Ha nincs, itt is a service-ként való futtatás jelenti a megoldást. A service-hez tudunk jogosultságot adni, így nem feltétlenül kell ilyen esetben feltétlenül folyamatos VPN kapcsolatot fenntartani.

    A tanúsítványokat/kulcsokat őrizzük meg jól, érdemes a rendszeres mentésbe belevenni a keys mappát! Erre azért van szükség, mert nem szeretnénk MINDEN tanúsítványt újra elkészíteni, amennyiben egy eszközt ellopnak, rajta a VPN konfiggal. Ezt úgy tudjuk megspórolni, ha az adott tanúsítványt visszavonjuk, ezt azonban csak akkor tudjuk megtenni, ha megvan maga a tanúsítvány!

     

    TANÚSÍTVÁNYOK VISSZAVONÁSA

    1. Tanúsítvány visszavonó lista létrehozása (Certificate Revoking List (CRL))

      revoke-full

      A parancs végrehajtása után az utolsó sorban ezt kell lássuk:
      error 23 at 0 depth lookup:certificate revoked

    2. Másoljuk a létrejött crl.pem fájlt a config mappába

    3. Ellenőrizhetjük a fájlt a következő paranccsal

      openssl crl -in "c:\program files\openvpn\config\crl.pem" -text

    4. Adjuk hozzá a következő direktívát a szerver konfigjához:

      crl-verify "C:\\Program Files\\OpenVPN\\config\\crl.pem"

    5. Indítsuk újra az OpenVPN szervert. (Volt, amikor 2x kellett megtenni, hogy a beállítás érvényre jusson.)

    6. Ha mindent jól csináltunk, minden, ezzel a tanúsítvánnyal történő csatlakozás innentől meg fog hiúsulni, és a következőhöz hasonló lesz látható a kliens logban:

      CRL CHECK FAILED: C=US, ST=CA, L=City, O=name, OU=name.example.org, CN=client, name=client, emailAddress=openvpn@example.org is REVOKED

     

    HIBAKERESÉS

    1. Ha a tűzfal kikapcsolt állapotában minden oké, de bekapcsoltan nem működik, akkor valószínűleg a VPN hálózat azonosítatlan (Unidentified) besorolásával lesz a probléma. Erre szép megoldást még nem találtam*, de workaround van: át kell állítani a Local Security Policy-ben, hogy az Unidentified hálózatok alapértelmezés szerint ne Public, hanem Private besorolást kapjanak. Mivel wifi elvétve van a szerverekben, így ez nem tűnik annyira komoly biztonsági kockázatnak.

      *A kézi átállítást úgy tűnik nem jegyzi meg a Windows, újraindítás után újra Public lesz a VPN hálózat...

    2. Ne PowerShellt használjunk a beállításokhoz, azzal nem mennek a scriptek!

    3. Ha nem sikerül kapcsolódni a következőhöz hasonló hibával a logban
      SIGUSR1[soft,private-key-password-failure]

      akkor valószínűleg "beépítős" konfig fájlt használunk, és egy plusz sortörés karakter került a konfigba egy ------ -es sor és maga a cert/kulcs közé. Notepad++-al megnyitva a konfig fájlt, és bekapcsolva a speciális karakterek mutatását, ellenőrizzük le. Általában a [*]
      -vel jelölt helyen lévő sortörés szokott problémát okozni:

      CRLF
      -----BEGIN ENCRYPTED PRIVATE KEY-----LF
      [*]
      xxxxxxxxxxxxxxxxxxxxxxxxxxxLF
      xxxxxxxxxxxxxxxxxxxxxxxxxxxLF
      xxxxxxxxxxxxxxxxxxxxxxxxxxxLF
      -----END ENCRYPTED PRIVATE KEY-----LF
      CRLF



      Az is lehet a probléma gyökere, ha lusták voltunk, és nem egy-az-egyben másoltuk a kulcsot, hanem csak a ------- -ek közötti részt, ugyanis a fejlécek különbözőek jelszavas és jelszó nélküli esetben. Jelszó nélküli esetben ilyen a fejléc:
      -----BEGIN PRIVATE KEY-----
      -----END PRIVATE KEY-----

    4. Script futtatásakor (build-key például) az alábbi hibaüzenethez hasonlót látunk:
      STR_COPY:variable has no value

      Amennyiben a vars.bat-ban valamelyik paraméter default értékének üres stringet adtunk meg, akkor találkoztam vele, ekkor ugyanis nem fog létrejönni az adott környezeti változó!

    5. ERROR: Windows route add command failed: returned error code 1073807366 a kliens logban

      Győződjünk meg róla, hogy rendszergazdaként indítottuk az OpenVPNGUI-t. Ha nem ez a gond, akkor adjuk hozzá a következő direktívát a kliens konfighoz:
      ip-win32 ipapi

    By Halász István on 2014. 09. 13. 18:17

    RDP kapcsolatot próbáltam létesíteni egy géppel, de fél perc után leszakadtam, és vissza se sikerült lépnem.
    Kiderült, hogy UTP-n és WiFi-n is kapcsolódva volt a gép, a reverse rekord a WiFi-s IP-re mutatott, és természetesen a WiFi-s net "megbízhatósága" okozta a problémát.
    A megoldást a probléma ellenkezőjére megoldást kereső Asteriksznél találtam meg:
     
    "... A frissítés után következett az ellenőrzés, amelynek során a gép felhasználója arra panaszkodott, hogy újraindítás után minden alkalommal kézi módon kell csatlakozzon a vezeték nélküli hálózathoz, annak ellenére, hogy jó a jelszó, sőt, bepipálta az automatikus csatlakozást is. Utánajárva a problémának, kiderült, hogy a hordozható eszköznek mindkét hálózati csatolóját használta: a vezetékes és a vezeték nélkülit is – egyszerre.
     
    A megoldáshoz szükséges tudni, hogy a Windows 8 esetén van egy beállítás, amely alapértelmezetten megakadályozza, hogy egyszerre több kapcsolatot létesítsünk akár a tartománnyal, akár az internet felé. Amennyiben tehát a vezetékes kapcsolat csatlakozott állapotban van, a wifi már nem csatlakozik (már felépült állapotban bontja a wifi-kapcsolatot), általában az előbbi ugyanis nagyobb áteresztő-képességű. Természetesen kézzel felül lehet bírálni ezt az elképzelést – ezért működött a kézi csatlakozás.
     
    Előbbi ismeretében már „csak” engedélyezni kell az egyidejű kapcsolatokat (az alapértelmezett tiltás tiltásával), s máris vidám mosolyt látunk a felhasználó arcán. Ezt vagy házirendben (akár helyi, akár csoport-) tudjuk megoldani:
     
    Computer / Admin templates / Network / Windows Connection Manager / Minimize the number of simultaneous connections…
     
    vagy registry-beállítással tudjuk szabályozni:
    HKLM\Software\Policies\Microsoft\Windows\WcmSvc\GroupPolicy kulcs alatt !fMinimizeConnections duplaszó létrehozással."
     
    Tehát az RDP-s problémám Win 8 alatt (alapbeállítás esetén) nem jött volna elő.

    By Halász István on 2014. 07. 09. 20:05

    Két opciónk van, egyrészt a regedit-tel megpróbálhatunk a távoli géphez kapcsolódni, de ehhez futnia kell a Remote Registry Service-nek a gépen.

    A másikhoz csak az kell, hogy PsExec-kel tudjunk programot futtatni a távoli gépen. Ekkor a következő paranccsal ellenőrizhetjük, hogy valóban le van-e tiltva az RDP kapcsolódás:

    psexec \\%1 reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections

    (A %1 helyett természetesen a gép nevét kell írni.)

    Ha a visszaadott érték 0x1, akkor ezzel a két paranccsal engedélyezhetjük az RDP kapcsolódást, és az NLA-t:

    psexec \\%1 reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
    psexec \\%1 reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 1 /f

    By Szeifert Gergő on 2014. 06. 20. 11:27

    Ezen operációs rendszerben már nem annyira kézenfekvő a hálózati profilok megváltoztatása, mint az mondjuk ahogyan a kliens oldali operációs rendszerben megszokhattuk. Az alábbi PowerShell parancsokkal tudjuk mégis könnyedén megváltoztatni azt. A hálózati profilok lekérése: Get-NetConnectionProfile Miután megkaptuk a listát az alábbi módon tudjuk a kívánt hálózatnak a típusát módosítani: Get-NetConnectionProfile -InterfaceAlias [Hálózat neve] | Set-NetConnectionProfile -NetworkCategory [Profil típusa]

    By Halász István on 2013. 02. 19. 14:44

    Úgy néz ki sikerült pontot tenni az ügy végére, mint kiderült a következőképp néz ki a dolog:
     
     
    T-Kábel infrastr. ábra
    A Cisco routert távolról menedzselik, azaz ők konfigolják fel.
     
    WAN IP: publikus, dinamikus
    Privát IP 1: privát, fix, alapesetben 192.168.0.1
     
    A Cisco DHCP-n privát IP-ket oszt, alapesetben a 192.168.0.0/24 tarományból. Azaz eddig a minden a szokásos. Fix IP szolgáltatás esetén azonban felkonfigolódik egy fix, publikus IP a privát mellé a LAN oldalra, és ennek a párját a meglévő routerben felkonfigolva lehet NAT-olás nélkül,tisztán routolva kijutni az internetre. Tehát:
     
    LAN IP 1: publikus, fix (LAN IP tartomány + 1-es cím)
    LAN IP 2: publikus, fix (LAN IP tartomány + 2-es cím)
     
     
     
     
     
     

    By Halász István on 2012. 05. 07. 23:45

    Hibajelenség: A számítógép TCP/IP kapcsolata nem működik, a Hálózat ikonon sárga háromszögben egy felkiáltójel van, valamint "Nem azonosított hálózat" a státusz. Az ipconfig parancsot kiadva azt látjuk, hogy két alapértelmezett átjáró tartozik a kapcsolathoz, az egyik a 0.0.0.0:
     
    Ethernet-adapter Helyi kapcsolat:
       Kapcsolatspecifikus DNS-utótag. . :
       Kapcsolati szintű IPv6-cím  . . . : fe80::f5bd:72a9:5883:54a4%10
       IPv4-cím. . . . . . . . . . . . . : 10.0.0.140
       Alhálózati maszk. . . . . . . . . : 255.255.255.0
       Alapértelmezett átjáró. . . . . . : 0.0.0.0
                                           10.0.0.1
     
    A tüneti kezelés a
     
    route delete 0.0.0.0
     
    parancs kiadása, majd ipconfig release-renew.
     
    Érdemes azonban ellenőrizni, hogy nem a hibásan települt Bonjour okozza-e a problémát. Nyissuk meg a szolgáltatásokat, és ellenőrizzük, hogy van-e ehhez hasonló nevű service-ünk:
    ##Id_String2.6844F930_1628_4223_B5CC_5BB94B879762##
     
    A Tulajdonságokat megnyitva a Futtatható fájl elérési útja bejegyzés alapján valóban egy hibásan települt Bonjour serviceről van szó, ha az a
    C:\Program Files (x86)\Bonjour\mDNSResponder.exe
     
    -re mutat.
     
    A javítás lépései emelt szintű konzolban a következő két parancs kiadása:
    "C:\Program Files (x86)\Bonjour\mDNSResponder.exe" -remove
    "C:\Program Files (x86)\Bonjour\mDNSResponder.exe" -install
     
    Ezután eltűnik a szolgáltatások közül a csúnya nevű service, illetve már a helyes "Bonjour Service" névvel jelenik meg.
     
    Megjegyzés: A fórumok alapján más gyártók mDNS Responder service-i is okozhatják a problémát, pl. a "National Instruments mDNS Responder Service" is, azokra viszont nem vonatkoznak a remove-install hibajavítási lépések.

    Számítsa ki költségeit
      kalkulátorunkkal

    tovább    

    és nyerje meg
    50 000 Ft értékű

    ajándékunkat  

    Akciós ajánlatunk

     Több szolgáltatót is volt szerencsém kipróbálni. Jelenleg minden projektünk a MOLEHAND-nél van elhelyezve, mert Ők nem csak egy szelet számítógépet adnak, hanem valódi szolgáltatást: Akármibe ütközök számíthatok a gyors és szakszerű reakcióra!