Üdv!
Adott egy Conteptronic C54RC PCMCIA wifi kártya és egy notebook. Elég lassú a hálózat, max 30-40kb/s. Mit lehetne vele csinálni hogy jóval gyorsabb legyen? Távolság nem lehet gond, mert akármilyen közel vagyok a routerhet akkor is ugyan azt produkálja.
Sziasztok,
Debian serveren szeretnek remote access vpn-t kialakitani.
Authentikacoval , NAT-al stb.
Mit ajanlotok ? Melyiket tarjatok a legjobbnak?
Udv Sztupi
Sziasztok!
Olyan problémám van, hogy cisco 4948 switchen SNMP lekérdezéseket a loopbacknek címezek, viszont nem a loopback IPjével, hanem a felém eső fizikai interfész IPjével válaszol. SNMP trap source-interfacet ugyan lehet állítani, de az sajnos csak a trapre vonatkozik, és nekem konkrétan a lekérdezésre kell source-interfacet állítanom.
Van valakinek ötlete, pliz ?
Adott egy szerverszolgáltatónál egy virtuális szerver. Debian GNU/Linux 5.0 frissítve 4.0-ás
verzióból. Rajta virtual domainekkel, email szolgáltatás. Postfix, Courier, Mysql.
Segítségül a howtoforge.
Ügyfél azt szeretné, ha bárhonnan kapcsolódik Internettről "mobilinternettel" tudja használni az SMTP
szerverünket azonosítás után. Persze ez is be lett állítva, sasl, cert fájlok minden.
Ez mégsem működik. Tünetek:
Itthon beállítom a levelezőkliensben (Iceweasel) a SMTP szervert, azonosítás szükséges, TLS,
felhasználónév ilyen formában: felhasznalovnev@virtualdomain.hu
jelszó és ezt kapom:
"Az üzenet küldése sikertelen.
Az üzenet küldése sikertelen, mert nem lehetett kapcsolatot teremteni az SMTP-kiszolgálóval
(mydomain.hu). A kiszolgáló elérhetetlen, vagy visszautasítja az SMTP-kapcsolatot ...
Szerveren:
# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mydomain.hu ESMTP Postfix (Debian/GNU)
ehlo localhost
250-mydomain.hu
250-PIPELINING
250-SIZE 30720000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
Müxik.
Akkor itthonról is megpróbálom:
$ telnet murvaimuvek.hu 25
Trying 88.151.97.148...
telnet: Unable to connect to remote host: Connection timed out
Hosszabb idő után elszál.
Ezek után otthonról:
~$ nmap mydomain.hu
Starting Nmap 4.62 ( http://nmap.org ) at 2009-05-25 19:54 CEST
Interesting ports on i125-47.vps.atw.hu (85.151.97.138):
Not shown: 1703 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
25/tcp filtered smtp
...
Látható, hogy a 25-ös port szűrve van. De tudom, hogy nem a
a szerverünkön. Ha tűzfalat kikapcsolom, akkor is ez a helyzet:
filtered.
Itthon ahol ezt próbáltam T-online van. Más SMTP szerverek mennek itthonról:
dave.interneteurope.eu
smtp.gmail.com
Van egy SMTP szerver amely szintén nem megy, régebben
próbáltam, de nem foglalkoztam vele, az egy sulinetes
hálózatban lévő szerver.
Mellesleg normál SMTP funkciók mennek, tehát fogadja a saját
maga által kezelt domaineket.
Próbáltam tail -f /var/log/syslog, és tail -f /var/log/mail.log miközben "autholni" próbálok a szerveren, de a logokban nem látszik semmi, még a próbálkozás sem.
Az a gyanúm, hogy a T-online szűr. Jól gondolom?
Ha így van csak azt tudnám hogyan tesztelhetem a szervert,
hogy működi-e az SMTP azonosítás. Nem mondhatom az ügyfélnek,
hogy próbálkozzon.
Van valakinek ötlete, véleménye?
Sziasztok!
Segitseget kernek az ugyben, hogy egy Sambat (Icybox NAS Server) tuzfal moge kellett tennem, mert olyan vacak, hogy nem tudom rajta megallitani a telnetet, viszont igy nem ugyanabban az alhalozatban van, mint az egyes (windows) kliens. A tuzfal mindent atenged, az INPUT/FORWARD/OUTPUT lancokat ACCEPTre allitottam, sot meg forwardoltam is az egyes Netbios es SMB portokat. De sajnos igy a tuzfal/router mogott mar nem tudom elerni a kliensekrol a megosztott mappakat.
Mukodik egyaltalan a Samba tuzfal mogott, es csak eddig meg nem talaltam volna meg a hibat ?!
Hali
A problémám a következő, remélem tudtok segíteni:
A topológia úgy néz ki hogy van egy UPC chello-s modem és erre kapcsolódik egy linksys router majd a routerből megy egy kábel a szerverbe és egy másik egy swichbe ami szétossza a netet (DHCP) még vagy 5 gépre.
Na szóval eddig úgy működött a szerver hogy a upc kiosztott egy ipét és a liksys átirányította a kéréseket a szervernek, az ip meg be volt állítva a domainhoz, ez eddig működött is, sőt volt olyan is hogy mivel ez dinamikus ip folyamatosan változott szal ha változott a domain regisztrátor oldalán átírtuk és kis idő múlva újra működött a szerver.
A probléma a következő hogy nem rég volt a upc-nél valami mert mindenhova új ip-ét osztott ki és át is írtuk a domaint az új ipre ami a domain.hu oldalon látszik is mert ott a dns recordban mutatja az újat viszont a upc dns szervere még a régit adja vissza már 2 napja, és ha nem az upc netről nézem az oldalt akkor működik is...
A kérdésem a következő mi lehet a probléma hogy az upc szervere nem frissíti a dns recordot?
JA és megjegyezném nem én terveztem hálózatot hanem az előttem lévő "zseniálisan profi csapat" úgyhogy most én szívok vele...
Üdv
Pár napja furcsaságokat kezdett produkálni a szerveren az iptables (shorewall) és nemtudom hova tenni a dolgot.
Először azt hittem a hálókártyával van a gond esetleg, vagy a cisco 2950-es switch vacakolna. De másik gépen is ugyanez történt, se ping, se net.
Teljesen random, amikor jólesik neki hirtelen megszűnik a laptopon a net a szerveren pedig ha épp bevagyok lépve az alábbit látom a syslogban:
May 22 10:17:20 kubuntu kernel: [52731.139400] Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth2 SRC=192.168.xxx.10 DST=74.125.43.18 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=57457 DF PROTO=TCP SPT=2047 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
May 22 10:17:20 kubuntu kernel: [52731.586843] Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth2 SRC=192.168.xxx.10 DST=74.125.43.18 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=57472 DF PROTO=TCP SPT=2047 DPT=80 WINDOW=65535 RES=0x00 SYN URGP=0
Tegnap leszedtem a 3.x-es shorewallt és felraktam csomagból a 4-est, de ugyanaz történik.
Ha kilövöm a shorewallt megy a ping és az ssh is a szerverre, ha visszakapcsolom akkor amig olyanja van addig se ping, se ssh se net semmi. Más eszközöket a hálóban simán tudok pingelni.
Aztán van hogy pár perc múlva újra megy minden. Ez mitől lehet illetve miért tilt le a saját tűzfalam egy időre? Esetleg jaunty gond?
Sziasztok!
Egy Cat6-os FTP kábeles hálózatot kell kiépítenem a napokban. Mivel eddig csak árnyékoló fólia nélküli kábelekkel dolgoztam, egy picit zavarban vagyok, ezért kérném a hozzáértők segítségét.
Az első kérdésem az volna, hogy elég csak az egyik helyen leföldelni a kábelvéget? Praktikusan a rendezőszekrényhez, vagy mind két végén ajánlott?
A második, kapcsolódik az elsőhöz konkrétan, hogy a földelés hogy történjen? 220-as földelést rákötni a rendezőre, vagy esetleg közvetlen a kábel árnyékolóvezetékére?
Köszönöm a segítségeteket előre is!
Adott a munkahelyen egy gép, amely célalkalmazást futtat. 10.x.x.x-es tartományú belső IP-n van. Az alkalmazás fel van készítve hálózatos működésre. Bárhonnan futtatható, de az adatokhoz, amikkel dolgozik egy windows-os share-ről juthat hozzá.
Cél: otthonról futtatás.
Belépek VPN-nel a munkahelyre. Az alkalmazás sikerrel lekéri a hardware Sentinel-lel rendelkező licenszet és elindul. De sehogyan sem lehet hozzáférni a windows-os share-hez. Talán a munkahelyi tűzfal fogja ezt a forgalmat - ami logikus is lenne.
Gondoltam, hogy amíg az IT-sek megoldják a dolgot, addig is áthidalom egy port-forwardinggal. Egy olyan szerveren, ami publikus IP-n van, megnyitottam a portot és forwardoltam a belső gép felé. A kapcsolat létre is jön és kéri a jelszót. De hiába írom be neki, újra és újra kéri.
Az alábbi iptables szabályokat használtam:
iptables -t nat -A PREROUTING -i $INTERNAL -p udp -s VPN_IP -d $IPADDR --dport 445 -j DNAT --to CEL_IP:445
iptables -t nat -A PREROUTING -i $INTERNAL -p udp -s VPN_IP -d $IPADDR --dport 135 -j DNAT --to CEL_IP:135
iptables -t nat -A PREROUTING -i $INTERNAL -p udp -s VPN_IP -d $IPADDR --dport 137 -j DNAT --to CEL_IP:137
iptables -t nat -A PREROUTING -i $INTERNAL -p udp -s VPN_IP -d $IPADDR --dport 138 -j DNAT --to CEL_IP:138
iptables -t nat -A PREROUTING -i $INTERNAL -p udp -s VPN_IP -d $IPADDR --dport 139 -j DNAT --to CEL_IP:139
iptables -t nat -A PREROUTING -i $INTERNAL -p tcp -s VPN_IP -d $IPADDR --dport 445 -j DNAT --to CEL_IP:445
iptables -t nat -A PREROUTING -i $INTERNAL -p tcp -s VPN_IP -d $IPADDR --dport 135 -j DNAT --to CEL_IP:135
iptables -t nat -A PREROUTING -i $INTERNAL -p tcp -s VPN_IP -d $IPADDR --dport 137 -j DNAT --to CEL_IP:137
iptables -t nat -A PREROUTING -i $INTERNAL -p tcp -s VPN_IP -d $IPADDR --dport 138 -j DNAT --to CEL_IP:138
iptables -t nat -A PREROUTING -i $INTERNAL -p tcp -s VPN_IP -d $IPADDR --dport 139 -j DNAT --to CEL_IP:139
iptables -t nat -A POSTROUTING -o $INTERNAL -d CEL_IP -j SNAT --to-source $IPADDR
A logokban nincs olyan ominózus bejegyzés, hogy a VPN-es címről, vagy a célgépről csomagot fogott volna el a packet filter.
Mi lehet a hiba? Hol rontom el?
BTW: nincs kedvem Samba-t konfigolni. Vagy csak azzal fog menni?
Üdv,
Dw.
2009. május 5.
A kedvenc (vagy egyetlen?) otthoni szolgáltatóm már a sokadik nnn.nnn.0.0/16-os hálózatból oszt ki nekem dinamikus címet.
A routerem jól együtt működik a dyndns.com-mal viszont a munkahelyi tűzfal nincs felkészülve az ekkora változásokra.
2009. május 18.
Annyira ocsmány scriptet raktam ki ide a múltkor,
hogy muszály volt átírnom - már csak azért is, mert az otthoni routeren is akarom futtatni - viszont Asus WL-500gP-n "Oleg 1.9.2.7-10" esetében nincs se host, se dig, se getopts.
#!/bin/sh
# /opt/tracehomeip/thip
opts=false; step_=false; no_force_=true;
case $1 in *-*) opts=true;; esac
if $opts; then
case $1 in *f*) no_force_=false;; esac
case $1 in *s*) step_=true;; esac
shift
fi
if $step_ ;
then
home_name=$(echo $* | awk '{ print $2 }')
most=$(ghost $home_name); volt="?"
if [ "$most" = "" ]; then exit 0 ; fi
ip_file=$0".ip."$home_name
if [ -r $ip_file ];
then volt=$(cat $ip_file | awk '{ print $NF }'); fi
# $1: no_force_
if $1; then if [ "$most" = "$volt" ]; then exit 0 ; fi; fi
echo $most > $ip_file
# tűzfalszabály részletek kiírasa, user/.ssh/config aktualizalasa, stb...
if [ -x $0"fw" ]; then $0"fw" "-s" $most $volt $* ; fi
logger -t HOME_IP $home_name": "$most
echo "." >> $0".ch";
else
echo "" > $0".ch"
# az összes home-gep ip-cím aktualizálása
eval "awk '{ if((\$1!~\"#\")){ system ¬
( \""$0" -s "$no_force_" \"\$0 \"&>/dev/null\" )} }' "$0"_users"
if [ ! -z "$(cat $0".ch" | awk '{ print $1 }')" ]; then
# volt csere - tűzfalszabályok összeszerelése
if [ -x $0"fw" ]; then $0"fw" "-f"; fi
fi
fi
exit 0
Ha -f opcióval inditjuk, mindenképpen újraszerkeszti a tűzfalat - akár volt változás, akár nem.
hozzá a ghost:
#!/bin/sh
# ghost
# ip.cim hostname-ből
# OpenDNS servercímek dig-be bevasalva
# UHU-linux 2.1 (kipróbálva)
# Asus WL-500GP - Oleg 1.9.2.7-10 (kipróbálva)
if [ "$1" = "" ]; then exit; fi
case "$HOME" in
/usr/local/root)
# oleg csak egy csövet bír el egyszerre
# viszont, ha adsl-modemre csatlakozik: lehet ”-m 1”
ipcim=$(traceroute -w 2 -m 1 $1 2>&1 | grep "traceroute" )
ipcim=$(echo $ipcim | awk '{ print $4 }')
lc=”(” ; rc=”),”
ipcim=$(echo $ipcim | sed -e 's/'$lc'//g' -e 's/'$rc'//g')
;;
*)
ipcim=$(dig @208.67.222.222 @208.67.220.220 $1 ¬
| head -n 13 | tail -n 1 | awk '{ print $NF }')
;;
esac
if [ "$(echo $ipcim | awk ' BEGIN { FS = "." } ¬
{ print $1"."$2}')" != "67.215" ]; then
if [ $(echo $ipcim | awk ¬
' BEGIN { FS = "." }{ print NF}') = 4 ];
then echo $ipcim; fi
fi
exit 0
/usr/local/sbin-ben, és /usr/local/bin-ben:
@ghost (symlink az ”/opt/tracehome/ghost”-ra )
@tracehomeip (symlink az ”/opt/tracehome/thip”-re )
/etc/cron.d/cron-ba a következősor ( ha 5 percenként akarjuk ellenőriztetni ):
-*/5 * * * * root tracehomeip &>/dev/null
/etc/tracehomeip_users:
# formatum:
# space-el elválasztott lista
# $1: távoli gep neve
# $2: sshport,tovabbi,portok,vesszővel,elválasztva
# $3-$NF: home_könyvtárak
hostname1 sshport /home/user1
hostname2 sshport,masikport,megegyport /home/user1 /home/user2
/opt/tracehomeip/@thip_users (symlink az ”/etc/tracehomeip_users”-re )
A tűzfalszabály és /home/user/.ssh/config aktualizáló program (alapesetben):
/opt/tracehomeip/thipfwezeket a bemenő paramétereket kapja
step - lépésenként:
-s (ipcim-most) (ipcim-volt) (/etc/tracehomeip_users-megfelelő_sora)
első esetben „”ipcim-volt” értéke: ”?”
vagy - aktualizáláshoz:
-f
egyéni döntés, hogy az /etc/hosts.deny, ~/.ssh/config állományok is szerkesztődnek-é a tűzfalszabályokkal