MOLEHAND Solutions

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

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.

By Halász István on 2012. 04. 25. 0:52

Az egyik ügyfélnél egy géplefagyás után eltűnt az alaplapi hálókártya az eszközkezelőből az eszközök közül, és nem is működött tovább, mintha nem is létezne.
 
Sem az újraindítás, sem egy disable-enable ciklus a biosban nem változtatott a helyzeten.
A probléma oka a deep sleep nevű működési mód beragadása volt, azaz nem ébredt fel a kártya az alacsony fogyasztású üzemmódból.
 
A felébresztés menete:
  1. kapcsoljuk ki a gépet
  2. húzzuk ki a tápkábelt, notebook esetén távolítsuk el az akkumulátort
  3. nyomjuk meg néhányszor a bekapcsológombot,
    ezzel kimerítjük az alaplapi kondezátorokat, teljesen áramtalanítjuk az alaplapot
  4. dugjuk össze, és kapcsoljuk be a gépet

 

By Halász István on 2011. 12. 20. 0:11

1. Lépjünk be szöveges módban az eszközre Konzol\SSH\Telnet porton.
2. Lépjünk a 24.8-as menüpontba, azaz kérjünk parancs interpreter promptot.
3. Tiltsuk le a felesleges interface(eken) a capture-t:
sys trcp channel  none
sys trcp channel none
... 

4. Engedélyezzük a kívánt interface-en a capture-t:
sys trcp channel bothway

5. Kapcsoljuk be trace loggingot:
sys trcp sw on & sys trcl sw on

6.A Online log
Jelenítsük meg a  kivonatos online logot:
sys trcd brief 

Vagy tekintsünk bele a packetekbe:
sys trcd parse
 
6.B Offline log
Állítsuk le a logolást:
sys trcp sw off & sys trcl sw off
A. Jelenítsük meg a kivonatos offline logot:
sys trcp brief
 
B. Vagy tekintsünk bele a kívánt packetekbe:
sys trcp parse
A Zywall 35 port kiosztása például:
Port 1 = enet0 = enif1 = LAN
Port 2 = enet1 = enif2 = WAN1
Port 3 = enet2 = enif3 = DMZ
Port 4 = enet3 = enif4 = WAN2
Port 5 = enet4 = enif5 = WCard
Port 6 = enet5 = enif6 = WLAN
 

 

Discount offer

 I’ve already tried several providers. Currently all of our projects are placed at MOLEHAND, because they provide real services not only a piece of a computer. Any kind of new problem crops up, I can always count on a fast and expert reaction.