- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- Már a Sparkle is jegyezhet fehérbe öltöztetett videokártyákat
- Háromféle processzor is része lesz a Core 200 sorozatnak
- Steam Deck
- Hobby elektronika
- VR topik (Oculus Rift, stb.)
- ASUS ROG Ally
- Nem indul és mi a baja a gépemnek topik
- A Samsung hazánkban is piacra dob idén egy friss Micro LED tévét
- AMD Navi Radeon™ RX 7xxx sorozat
- Milyen processzort vegyek?
- Melyik tápegységet vegyem?
Hirdetés
-
Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
ph A Kereskedelmi Minisztérium egyelőre csak felméri a helyzetet, egyelőre nem látni, hogy tudnak-e bármit is tenni.
-
Agyi chipes gyártóba fektetett a kriptocég
it A Tether 200 millió dollárt fektet a Blackrock Neurotech agyi chipes vállalatba.
-
Nem fogod kitalálni, mire fókuszál a Dimensity 9300+
ma Spoiler: az AI-ra, ami májusban még az évszakot is megváltoztatja.
-
PROHARDVER!
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
Andralin
aktív tag
Sziasztok!
A napokban telepítettem CentOS 7-et, eddig RedHat 8-ast használtam, erről térek át most CentOS-re.
Az Apache-on futó oldalakat szeretném https-el elérni, ebben kérném a tanácsotokat, általánosságban, nem disztribúciótól függően.
Találtam ezt az oldalt ingyenes SSL certificate-re: [link]
Ismeri ezt valaki, szerintetek érdemes lehet ezen az oldalon egy ingyenes certificate-et csinálni a szerveremnek?
Vagy jobban járok, ha magamnak generálok egyet a "self-signed" módszerrel?[ Szerkesztve ]
-
Andralin
aktív tag
Sziasztok!
Segítséget szeretnék kérni, nem akar működni a NAT.
Egy régi Redhat 8.0-t migrálok át CentOS 7-re.A Redhaton több mint 10 éve futó iptables beállítást átmásolva az új CentOS-en nem működik a NAT-olás.
Van egy pubikus fix IP címe a masinának, illetve egy belső hálózati címe: 172.20.8.1. A belső gépek is az utóbbi tartományban vannak fix IP-vel.
A config, ami eddig stabilan, gond nélkül működött:
iptables -F
iptables -t nat -F
iptables -X
iptables -P INPUT DROP
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -j MASQUERADE
iptables -A INPUT -p tcp -s 172.20.8.0/24 -j ACCEPT
iptables -A INPUT -p icmp -s 172.20.8.0/24 -j ACCEPT
iptables -A INPUT -p udp -s 172.20.8.0/24 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p udp -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p icmp -s 127.0.0.1 -j ACCEPTSzerintetek mi lehet a gond? Mit próbáljak meg változtatni, hogy kilássának NAT-al a belső gépek?
[ Szerkesztve ]
-
Andralin
aktív tag
Mégiscsak rászorulnék egy kis segítségre iptables ügyben.
Az újratelepítés óta egy kínai IP-ről szakadatlan brute force-olják a gépet ssh-n keresztül root userre.
A támadó IP címét letiltottam iptables-el a legjobb ismereteim szerint, mégis folyamatosan próbálkozik.
Ezt a sort parancsot futtattam le:iptables -A INPUT -s 112.85.42.102 -j DROP
Ennek ellenére folyamatosan ott vannak a támadások logjai a /var/log/secure fájlban:
Failed password for root from 112.85.42.102 port 3387 ssh2Már újra is indítottam a gépet, de hiába. Az iptables -L a legvégén ezt írja ki:
DROP all -- 112.85.42.102 anywhereMost akkor mi van, hogyan tud mégis tovább próbákozni?
Elrontottam valamit a kitiltó paranccsal? Hogyan tudnám megoldani, hogy ténylegesen letiltsam a kívánt IP-t tűzfalszinten?
Kérlek segítsetek! -
Andralin
aktív tag
válasz vargalex #25120 üzenetére
Időközben rájöttem, elfelejtettem, hogy számít a sorrend is.
A (#25110)-ben van az alap scriptem, ehhez írtam hozzá a tiltást, és ugye így a chain végére került, a iptables -A INPUT -p tcp --dport 22 -j ACCEPT sor pedig korábban már beengedett mindent a 22-es porton.
Most betettem a tiltó sort a 22-est engedélyező sor fölé, és így már működik ahogy kell, teszteltem mobilnetről, külső IP-ről és így rendben működik a tiltás.
-
Andralin
aktív tag
Köszi a tippet, szemezgettem ezekkel amiket ajánlassz, de közben olvastam azt is, hogy meg lehet az egészet oldani iptables szinten, nem szükséges külső megoldást használni.
Gondoltam akkor megpróbálkozom az iptables-el.
Elvileg ez a két sor azt csinálja, hogy ha azonos IP-ről egy percen belül háromnál több sikertelen csatlakozás indul ssh-n, akkor automatikusan tiltja az IP-t iptables szinten:
/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
/usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROPBe is tettem ezt a két sort, szintén az ominózus iptables -A INPUT -p tcp --dport 22 -j ACCEPT sor fölé, de nem működik sajnos. Simán beenged, próbáltam külső IP-ről elrontani a root jelszót ssh bejelentkezésnél kb. 20-szor is egy percen belül, de semmi, nem tiltott le.
Arra gondoltam, hogy esetleg az ACCEPT sort ki kellene vennem teljesen, akkor talán működhet?
Kicsit necces a dolog, mert tőlem 180 km-re van a szerver, és ha félresikerülnek a dolgok, akkor egyáltalán nem fogok tudni belépni, de mondjuk csinálhatok egy cron scriptet a kísérletezéshez, ami 5 percenként visszatölti a default iptables szabályokat ha valami félremenne és kizárnám magamat.
Ti mit gondoltok?[ Szerkesztve ]
-
Andralin
aktív tag
válasz vargalex #25131 üzenetére
Megtaláltam a hibát, de így sem volt használható ez a módszer.
Az volt a gond, hogy a bannolós sorok alatt volt sorrendben egy ESTABLISHED-et átengedő sor, és így nem működött. Az ESTABLISHED-es sort ártaktam a ban-os sorok fölé és így már jó volt, de mégsem.
Szóval ha magam teszteltem külső IP-ről, putty-al rossz jelszavakat adva meg, valóban letiltotta az IP-t és logolta is a tiltást. Viszont a kínai próbálkozók közül mindössze 1 db IP-t sikerült neki kitiltania.
Az éjszaka során 8 órás időintervallumban volt pl. 700 sikertelen login kísérlet root-ként, ebből csak egy darab IP tiltás született. Szóval valamiért használhatatlan nálam ez a módszer.
[ Szerkesztve ]
-
Andralin
aktív tag
Feladtam, meggyőztél!
Feltettem a fail2ban-t, most játszom vele.
Eddig szuper! Eddig 10 perc alatt már 3 kínai IP-t tiltott le az sshd.
Bekapcsoltam még a apache-auth és openwebmail jaileket és tesztelve teszi a dolgát rendben!
Mit érdemes még bekapcsolni úgy általánosságban?
Pl. sendmail-auth, sendmail-reject, stb? -
Andralin
aktív tag
válasz bambano #25140 üzenetére
Nálam fut a sendmail, úgy van beállítva, hogy csak a belső hálóról illetve webmailről fogad leveleket kiküldésre (SMTP szerverként), illetve a szerveren lévő pár user számára fogad kintről leveleket.
A sendmail logban szokott lenni bepróbálkozás relay-zésre kintről.
Akkor érdemes bekapcsolni ezeket, mind a kettőt? A sendmail-auth-ot meg rejectet?
-
Andralin
aktív tag
válasz bambano #25137 üzenetére
Segítség! Most vettem észre, hogy fail2ban a kitiltásokról automatikusan küld X-ARF e-mail értesítést az érintett IP tartomány adminjának! Pattognak vissza ilyen e-maliek, pedig én nem akarok senkinek semmit küldözgetni kifelé.
Ilyen kezdetű e-mail eket küldözget kifelé:
Dear Sir/Madam,
We have detected abuse from the IP address 211.167.101.137, which according to abusix.com is on your network. We
would appreciate if you would investigate and take action as appropriate.
Log lines are given below, but please ask if you require any further information.A jail.local-ban action-ként ezt állítottam be:
action = %(action_mwl)sEz a leírás szerint csak a destemail-ben megadott címre, vagyis nálam a root-nak küld e-mailt.
Ha jól értem, akkor a külső abuse értesítésekhez a action_xarf kellene, de én azt nem használom:# ban & send an e-mail with whois report and relevant log lines
# to the destemail.
action_mwl = %(banaction)s[name=%(__name__)s, bantime="%(bantime)s", port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
%(mta)s-whois-lines[name=%(__name__)s, sender="%(sender)s", dest="%(destemail)s", logpath=%(logpath)s, chain="%(chain)s"
# See the IMPORTANT note in action.d/xarf-login-attack for when to use this action
#
# ban & send a xarf e-mail to abuse contact of IP address and include relevant log lines
# to the destemail.
#action_xarf = %(banaction)s[name=%(__name__)s, bantime="%(bantime)s", port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]
xarf-login-attack[service=%(__name__)s, sender="%(sender)s", logpath=%(logpath)s, port="%(port)s"]Akkor miért küldi mégis az abuse leveleket kifelé? Hogyan tudnám ezt leállítani?
[ Szerkesztve ]
-
Andralin
aktív tag
válasz Andralin #25150 üzenetére
A fail2ban-os gondommal nem tud senki tanácsot adni?
Azért itt kérdezem, mert ebben a topikban ajánlottátok, hogy ezt tegyem fel.
Vagy esetleg tudtok ajánlani másik topikot, ahol talán értenek hozzá és tudnak segíteni?
Nagyon szép és jó, tényleg fantasztikus a tudása, csak ezeket az automatikus abuse e-mailek kiküldését az IP címtartomány fenntartójának, ezeket kellene valahogy leállítani mihamarabb.
[ Szerkesztve ]
-
Andralin
aktív tag
Nagyon köszi, hogy szóltál, én valahogy nem vettem észre!
Több helyen is ahol két soros volt az action leírás, ezeket a második sorokat elfelejtettem kikommentelni.Tegnap este javítottam, most azóta a maillog alapján nem küldöget kifelé semmit, csak a helyi root-nak a figyelmeztetést a kitiltásokról.
Amúgy találtam egy olyam kiegészítést a fail2ban-hoz, ami egy Google mapre felpakolgatja a kitiltott IP-ket geolocation alapján. Be is állítottam a szerveremre, nagyon jól néz ki, ahogy szépen gyűlnek a zászlócskák minden kontinensen.
-
Andralin
aktív tag
Sziasztok!
Tudnátok nekem segíteni egy makacs problémáét megoldani CentOS 7-en?
A CentOS topikban már kértem tanácsot, de sikertelenül és szerintem elég általános lehet a gond,talán ti is tudtok nekem segíteni.Az alap gond az, hogy be van állítva a yum-cron, óránként lefuttatja a cron kritikus biztonsági frissítéseket keresve. Sajnos nem működik a dolog és a root minden órában kap egy hibaüzenetet e-mailben a Cron Daemontól:
/etc/cron.hourly/0yum-hourly.cron:
Could not get metalink https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=x86_64 error was
14: curl#77 - "Problem with the SSL CA cert (path? access rights?)"Már rájöttem, hogy a probléma gyökere az, hogy a curl.
A curl nem tudja leszedni a kívánt erőforrást, mert nem tetszik neki az SSL certificate. És azt is tudom, miért nem tetszik neki.
Ugyanis csináltam teljes értékű, valós SSL certificate-et a weboldalak https-es eléréséhez a Let's Encrypt által és feltettem a /etc/ssl/certs alá. Az eredeti certificate fájlokat az /etc/ssl/certs/saved_original/ alá mentettem.Az Apache és a https tökéletesen működik, a böngészőn a kis lakat zöld, mutatja rendben az infókat is. De a curl elszáll hibával ha a yum-cron https-es doksit akar leszedni.
Ha lefuttatom ezt a parancsot, a következő az eredmény:
curl -I -v https://google.com
* About to connect() to google.com port 443 (#0)
* Trying 216.58.209.206...
* Connected to google.com (216.58.209.206) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* Closing connection 0
curl: (77) Problem with the SSL CA cert (path? access rights?)Viszont ha megadom opcióként a régi, eredeti ca-bundle.crt fájl elérését, akkor már lefut rendben a curl, nem ad hibát:
curl -I -v --cacert /etc/ssl/certs/saved_original/ca-bundle.crt https://google.com
* About to connect() to google.com port 443 (#0)
* Trying 216.58.209.174...
* Connected to google.com (216.58.209.174) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/ssl/certs/saved_original/ca-bundle.crt
CApath: none
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate:
* subject: CN=*.google.com,O=Google Inc,L=Mountain View,ST=California,C=US
* start date: Feb 01 13:50:27 2017 GMT
* expire date: Apr 26 13:21:00 2017 GMT
* common name: *.google.com
* issuer: CN=Google Internet Authority G2,O=Google Inc,C=US
> HEAD / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: google.com
> Accept: */*Már csak azt kellene megoldani, hogy ha a cron futtatja le (a yum-cron által) a curl-t, akkor is ezt a --cacert opciót vegye figyelembe, de ez sehogy nem jön nekem össze.
Ebben tudnátok nekem segíteni?[ Szerkesztve ]
-
Andralin
aktív tag
válasz Andralin #25219 üzenetére
Két dolgot már megpróbáltam, de sikertelenül.
1. Létrehoztam a /root/.curlrc fájlt az alábbi tartalommal:
cacert=/etc/ssl/certs/saved_original/ca-bundle.crtÍgy rootként futtatva a curl -I -v https://google.com parancsot működik!
Viszont amikor a cron futtja, ugyanarra a #77-es SSL CA cert hibára fut.2. Átneveztem a /bin/curl fájlt /bin/curlexe névre és létrehoztam egy scriptet /bin/curl alatt ezzel a tartalommal:
/usr/bin/curlexe --cacert /etc/pki/tls/certs/saved_original/ca-bundle.crt $@
Ez elvileg a curl parancs kiadásakor mindig hozzáadja a --cacert opciót.
Rootként futtatva a curl -I -v https://google.com parancsot ez is működik, akkor is, ha az 1-es megoldást nem alkalmazom, tahát önmagában is jó megoldásnak tűnik a .curlrc nélkül.
Viszont amikor a cron futtja így a curl-t, akkor megint ugyanarra a #77-es SSL CA cert hibára fut.Most már kezdem feladni, nincs más ötletem.
Tudnátok tanáccsal segíteni, mit próbáljak még meg, hogy yum-cron is használja ezt a szerencsétlen --cacert paramétert a curl-höz?
[ Szerkesztve ]
-
Andralin
aktív tag
-
Andralin
aktív tag
válasz bambano #25227 üzenetére
Az a gond, hogy a yum-cron hívja meg a curl-t és nem valami scriptből, hanem fogalmam sincs miből és hogyan hívja meg.
Az óránkénti cron fájlban ez az egy sor van:
exec /usr/sbin/yum-cron /etc/yum/yum-cron-hourly.confEbből sajnos nem tudom tetszőlegesen módosítani, hogy hogyan futtassa a curl-t.
[ Szerkesztve ]
-
Andralin
aktív tag
Sziasztok!
Tanácsot kérnék sima ethernet kapcsolatról PPPoE kapcsolatra való átálláshoz.
A szolgáltatói végponton egy CentOS 7-es gép van, ami tűzfal és NAT funckiókat szolgáltat a mögötte lévő hálózatnak. A bejövő hálózati interface neve enp9s0. A szolgáltató (Digi) pénteken fog átváltani régi koaxos (DOCSIS) rendszerről optikára (FTTH) és muszáj lesz PPPoE kapcsolatra váltani, én pedig linuxon ilyet még soha nem állítottam be. Jó lenne az egész átállást minnél gördülékenyebben megcsinálni, minimális leállással.Azon kívül, hogy az rp-pppoe csomag segítségével beállítom a PPPoE paramétereket, mire kellene még figyelnem, mit kellene még esetleg beállítani? Milyen esetleges buktatók lehetnek, amire előre felkészülhetek?
A meglévő iptables tűzfalam ugye az PPPoE-re való átállás után is ugyanúgy működni fog és biztosítja majd a NAT-ot is, ahogy eddig?
És mégegy fontos kérdés: a hálózati interface megmarad az eddigi enp9s0? Vagy létrejön mellette egy új interface ppp0 néven is?
[ Szerkesztve ]
-
Andralin
aktív tag
válasz bambano #26750 üzenetére
Szia! Köszönöm a választ!
A digis topikban már túl vagyok az infokérésen. Ott azt mondták, hogy holnap mondanom kell a szerelőnek, hogy a digis eszközt kapcsolja bridge módba és akkor ugyanúgy működhet minden tovább. Természetesen ez azzal jár, hogy nekem kell a szerveren a PPPoE-t beállítanom.
Az nekem nagyon nem lenne jó, ha a szerverem a digis eszköz mögé, egy NAT-olt hálóra kerülne. Mindenképp fontos, hogy a szerver maga kapja a külső IP címet, mivel ő látja el a NAT és tűzfal funkciókat a belső háló számára. Ezért kell a bridge mód.
Ezt a pppoe-conf csomagot amit írtál hogyan tudom feltelepíteni CentOS 7-re? Jó lenne meg addig leszedni, amíg neten van a gép. Próbáltam a yum install pppoeconf-ot, de azt írja: No package pppoeconf available. A Google-el sem lettem okosabb.
A Google legelső helyen amúgy ezt a leírást dobja ki CentOS-re és ez nekem is nagyon szimpatikus, részletesen el vannak magyarázva a lépések a rp-pppoe csomag használatával, és ezt már fel is tettem a gépre:
[link]
Szerinted ez a csomag egyáltalán nem jó? Inkább a pppoeconf-ot használjam helyette? Vagy jó lehet ez is?Erre a kérdésre nem tudod esetleg a választ?
És mégegy fontos kérdés: a hálózati interface megmarad az eddigi enp9s0? Vagy létrejön mellette egy új interface ppp0 néven is?[ Szerkesztve ]
-
Andralin
aktív tag
válasz bambano #26750 üzenetére
Megvolt az átállás, és a linux szerveren a PPPoE kapcsolat első próbálkozásra felépült, megkapta a fix IP címet és kint volt a neten.
Viszont van most egy óriási gondom!
Eddig egy alias IP volt hozzárendelve az egyetlen hálózati csatolóhoz, ez volt az enp9s0:0 egy belső hálós IP címmel. Közvetlen netkapcsolattal tökéletesen működött, NAT-olt a szerver így a belső hálóra.Viszont a PPPoE átállással eltűnt az alias IP cím! Hiába van az \etc\sysconfig\network-scripts\enp9s0:0 file ahogy eddig is, a belső IP nem létezik többé.
A ip addr show sem mutatja már többé.A gép egy régebbi laptop gép, így nem olyan egyszerű a helyzet, mint egy PC-nél, hogy hirtelen belepattintok egy második gigás hálókártyát.
Már órák óra keresgélek a neten, de nem találok semmi megoldást.
Kérlek segítsetek! Van erre bármi megoldás, visszahozni valahogy az alias IP-t PPPoE esetén is? -
Andralin
aktív tag
válasz Andralin #26753 üzenetére
Egy kicsit előre jutottam.
Ha ezt a parancsot kiadom:
ip addr add 172.20.8.1/32 dev enp9s0
akkor megjelenik ez az alias cím az ip addr show alatt is és saját magáról pingelve válaszol is ez az IP.De fizikailag mégsem lát ki, nem úgy, mint korábban, a PPPoE nélkül. Belső hálóról nem pingelhető ez az IP, illetve a szerverről sem tudok másik belső gépet pingelni a 172.20.8.x-es tartományban. Tehát igazából nem veszi fel az interface ezt az alias címet, csak a szerverről néz ki úgy, mintha felvenné.
Mit lehetne még megpróbálni? Van valami ötletetek?
-
Andralin
aktív tag
Köszönöm a válaszokat!
A gond nem a tűzfal, vagy a NAT, hanem hogy az interface fel sem vette a megadott IP aliast (második IP címet). Az alias IP nem látszott, pingre nem válaszolt a belső hálóról, pedig PPPoE kapcsolat nélkül tökéletesen működött.
Én az IPtables-t használom CentOS7-esen is, már másfél éve stabilan, megbízhatóan működik. A FirewallD nem fut egyáltalán.
Viszont feladtam a kísérletezést az alias IP-vel és szombaton beszereztem egy USB-Ethernet átalakítót. A típusa TP-Link TL-UE300. Ez lett a WAN port, ehhez lett hozzárendelve a ppp0 interface, a meglévő régi eth0 interface pedig a LAN port lett a 172.20.8.1-es címmel.
Nos, eddig minden tökéletesen működik, PPPoE kapcsolat létrejön, DHCP-től megkapja a gép az IP címet és a belső gépek szépen látják a netet a NAT-on keresztüll. Viszont a gép folyamatosan hibaüzeneteket dobál a konzol képernyőre meg a rendszerlogba is. Néha percenként 3-4 alkalommal is feldobja:
kernel: cdc_ether 1-3.1:2.0 enp0s26f7u3u1c2: kevent 12 may have been dropped
Az enp0s26f7u3u1c2 az az új USB-s hálózati port. Ehhez van hozzárendelve a ppp0 interface.
Mit jelent ez az üzenet? Én miért dobálja folyamatosan, ha a kapcsolat tökéletesen működik? Hogyan tudnám ezt megoldani?
Ebben tudna valaki segíteni?[ Szerkesztve ]
-
Andralin
aktív tag
-
Andralin
aktív tag
Most vettem ezt az USB cuccot, és akkor egyből kuka? És ha veszek még sorban egy néhányat és azokkal is gond lesz? A linuxnál ez így működne, hogy addig veszed az újabb hardver eszközöket, amíg valamelyik egyszer csak nem működik rendesen a gépben?
Ráadásul ezt a típust kifejezetten azért választottam, mert azt írták róla, hogy linux alatt is plug&play és szerencsére az is volt. Tehát célirányosan válaszottam linux alatt működő eszközt.
A gép az egy laptop, így sajnos hagyományos hálókártya nem jöhet szóba, csak USB csatolós.
Amúgy ha jól értem a linket, ez csak egy bug, szóval szofterhiba, és nem nálam rossz valami, ugye? Mert akkor nem is érdekel, nem kell vele foglalkoznom. Csak akkor valahogy jó lenne letiltani ezeket az üzeneteket, hogy ne dobálja őket folyton terminálra. Le lehet ezt tiltani valahogy?
[ Szerkesztve ]
-
Andralin
aktív tag
válasz bambano #26765 üzenetére
Bocsánat, ezt tényleg írhattam volna, egy Dell Latitude D630-as a gép. CardBus slot van rajta.
Köszönöm a tippet, de PCMCIA kártyát nem szívesen használnék ilyen célra. Tapasztalataim szerint ezeknek a kártyáknak a fizikai stabilitása csapnivaló. Használtam már ilyen kártyát soros portként, elég volt ha egy kicsit megmozdult a csatlakoztatott vezeték, már elmozdult annyira a kártya a helyéről, hogy leállt a kommunikáció. Katasztrófális volt szó szerint, ethernet csatlakozásra sem szívesen használnám ezt a megoldást.
Már be lett ruházva ebbe az USB-s eszközbe és mivel egy kis otthoni szerverről van szó, nincs lehetőség még további tízezres kiadásra, főleg, ha tökéletesen működik ezzel a megoldással.
Abban lenne szükségem segítségre, hogy ezeket a folyamatosan feldobált hiaüzeneteket hogyan tudnám elnyomni, megszüntetni, hogy legalább a konzolra ne dobálja, ha ez lehetséges. Ha nem lehet, akkor így hagyom.> az usb egy megbízhatatlan csatorna, nem arra találták ki, hogy százmegágat áttolj rajta
Azért ezzel én vitatkoznék. Amikor mentést csinálok külső USB-s HDD-re és több tíz gigát tolok át az USB porton, akkor ezek szerint az sem helyes, mert nem erre találták ki az USB-t?
-
Andralin
aktív tag
Ez a kérdésed meglepett, mert bevallom nem néztem jobban utána, hogy van-e olyan router, ami jó lenne nekem. De engem is kíváncsivá tettél, létezik olyan router, ami PPPoE kliensként authentikál a WAN porton, majd bridge módban nyomja tovább a sima ethernet kapcsolatot anélkül, hogy felvenné a végpontra kiosztott fix IP címet, és hagyja, hogy a mögötte lévő gép vegye fel a fix IP-t?
Láttam már néhány egyszerűbb otthoni wifis routert, de azok nem tudtak ilyen módban működni.A másik kérdés meg, hogy egy ilyen router gigás portokkal ellátva kijönne szintén 5000 Ft körüli árból?
[ Szerkesztve ]
-
Andralin
aktív tag
válasz bambano #26770 üzenetére
Én is úgy gondoltam, hogy nincs ilyen.
Ezért csodálkoztam is a fenti kérdésen.Nekem mindenképp kellene a bridge mód, ezt már fentebb írtam, a digis szerelők külön kérésre állították be az eszközüket bridge módba, különben nem kellene a PPPoE-vel foglalkoznom.
Egy NAT-olt hálózatra meg nem szívesen tennék egy fix IP-vel rendelkező szervert, ami tűzfalat és NAT-ot is ad a mögötte lévő gépek számára.Szeretném, ha megértenétek, hogy nem akarom megváltoztatni az eddigi koncepciót. Eszemben sincs ilyesmi. Eddig volt egy CentOS7 szerver, fix IP címmel, domain névvel, amelyen egyebek közt tűzfal fut és NAT-ot ad a belső hálózat számára. Most megváltozott a bejövő link PPPoE-re, de az eddigi koncepciót ettől még nem akarom megváltoztatni, így akarom működtetni továbbra is.
Nem abban kértem tanácsot, hogy milyen más koncepcióval lehetne még működtetni ezt a rendszert, hanem hogy a fentebb említett hibaüzenetektől hogyan tudnék megszabadulni. Ha valaki ebben segíteni tud, azt hálásan köszönöm!
-
Andralin
aktív tag
Sziasztok!
Segítséget kérnék tőletek, nagy bajban vagyok. Mióta a szolgáltatónk bevezette az IPv6 címek támogatását, a tűzfalként használt CentOS 7 gép nem hajlandó csatlakozni az internetre.
A részletek a következők. Digi FTTH szolgáltatáson a CentOS 7-es gép PPPoE felületen csatlakozik a hálózatra és tűzfallal, routerként osztja tovább a netet a háztartás számára a belső hálózat felé. Egy ideig semmi gond nem volt, gond nékül csatlakozott. A rendszer teljesen stabil 6 hónapos uptime után újra lett indítva és azóta nem hajlandó újra csatlakozni a hálózatra.
Pár órás kísérletezés után kiderült, hogy most már IPv6 címeket is osztogat a Digi nálunk is. A WAN interface reboot után csak IPv6 címet kap, IPv4 címet nem kap.
Digi ügyfélszolgálat kérésére le lett tesztelve a végpont egy Windows 10-es gépen. Azon létrehozva a PPPoE kapcsolatot és csatlakozva a Windows kap TCPv4 és TCPv6 címet is! Ezek után a Digi mossa kezeit, szerintük náluk minden rendben van. A linux továbbra is csak TCPv6 címet kap és nem működik rajta az internetkapcsolat.Hogyan lehetne a linxuot rávenni, hogy kérjen a DHCP-től IPv4 címet?
Amit eddig próbáltam: letiltottam a IPv6-ot a linuxon neten talált tippek alapján.
A /etc/sysconfig/network-scripts/ könyvtárban a megfelelő interface konfig fájlba beírtam ezt a sor:
IPV6INIT=noIlletve a /etc/sysctl.conf fájlba beírtam az alábbi sorokat:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1Így reboot után a WAN interface most már semmilyen címet nem kap, se IPv4-et, se IPv6-ot.
Hogyan tudnám rávenni a linuxot, hogy kérjen IPv4 címet? Ha a Windows tud kérni olyat és kap is, akkor gondolom a linux is képes lenne rá valahogy. Mivel, hogyan lehet ezt beállítani?
Előre is hálásan köszönöm a segítséget!
[ Szerkesztve ]
-
Andralin
aktív tag
válasz Andralin #27777 üzenetére
Még az fontos lehet, hogy a DIGI weboldalán a következőket írják az IPv6-al kapcsolatban:
Egymástól függetlenül lehet állítani kliens oldalon hogy milyen módot szeretne:
- dual-stack (ipv4+ipv6)
- ipv4-only
- ipv6-only -
Andralin
aktív tag
válasz Andralin #27777 üzenetére
Nos, kicsit megzavarodtam, teljesen elfelejtettem egy fontos dolgot.
Azt, hogy PPPoE a kapcsolat és a kapcsolat felépülésekor létre kell jöjjön a ppp0 interface.
A helyzet az, hogy az ip a parancs nem listázza a ppp0-t.
Szóval fel sem épül a kapcsolat, itt lesz a kutya elásva.Szerintetek mi okozhat olyat, hogy egy 6 hónapos uptime során végig tökéletesen, stabilan működik a PPPoE kommunikáció, majd egy szabályos, parancssorból kezdeményezett reboot után már nem jön létre a újra a kapcsolat?
Merre induljak el a hibakeresésben?
-
Andralin
aktív tag
válasz bambano #27780 üzenetére
Szia!
Nagyon köszönöm a tippet, sokat segített a logokban kutakodás!Ilyen hibaüzenetekkel volt tele a log:
Using interface ppp0
Connect: ppp0 <--> /dev/pts/0
ioctl(SIOCGIFHWADDR): No such device
Modem hangup
Connection terminated.
Exit.
PPPoE connection lost; attempting re-connection.Egy kis nézelődés után feltűnt, hogy megváltozott a fizikai hálózati csatoló neve, amit a pppd használ!
A régi neve, telepítés óta mindig is enp0s26f7u3u1c2 volt, így szerepelt a saját config fájljának nevében is (/etc/sysconfig/network-scripts/ifcfg-enp0s26f7u3u1c2), illetve a ifcfg-ppp0 fájlban is ez a sor volt: ETH=enp0s26f7u3u1c2
Viszont az ifconfig -a parancs már enp0s26f7u3u1 néven listázta a csatolót, egyszerűen lemaradt róla a "c2" a végéről!
A megoldás az lett, hogy átneveztem az új, "c2" nélküli névre a saját ifcfg fájlját is és átírtam a ppp0 fájlban is az ETH= sort is az új névre. Reboot után azonnal fenn volt a neten!
Ez elég érdekes hiba volt, ilyesmi előfordulhat csak úgy magától? Mi okozhat olyat, hogy egy reboot során csak úgy teljesen random megváltozik egy hálózati csatoló neve?
[ Szerkesztve ]
-
Andralin
aktív tag
válasz sh4d0w #27783 üzenetére
És a systemd miért változtatja meg csak úgy random az NIC nevét?
Valahol be lehet ezt állítani vagy letiltani, hogy máskor ne csináljon ilyet és tartsa meg az eddigi nevét?Elég gáz, amikor az ember 200km-ről újraindítja a szervert és az nem jön vissza a netre, mert éppen valami más lett boot után a hálózati csatoló neve, mint eddig volt.
-
Andralin
aktív tag
-
Andralin
aktív tag
Sziasztok!
Ismét itt vagyok, most letsencrypt.org-os https tanúsítvány frissítéséhez szeretnék segítséget kérni.A kezdő topikban már próbálkoztam, ott azt írták, hogy ez már nem kezdő topikos téma.
Már egy ideje használom az automatikus frissítést három havonta, mindig a certbot renew paranccsal, eddig mindig tökéletesen működött a dolog. Most januárban ismét lejárt a tanúsítvány, meg kellene újítani, de nem sikerült.
Ezt a hibüzenetet kapom:
certbot renew
Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/myhost.hu.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator apache, Installer apache
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for myhost.hu
Cleaning up challenges
Attempting to renew cert (myhost.hu) from /etc/letsencrypt/renewal/myhost.hu.conf produced an unexpected error: Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80.. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/myhost.hu/fullchain.pem (failure)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/myhost.hu/fullchain.pem (failure)Ha jól értem, nem látja a 80-as porton futó Apache-ot, pedig egész biztosan ott van és fut az Apache a 80-as porton, kívülről elérhető, teszteltem.
Csináltam még verbose logot certbot -v renew paranccsal, de az nagyon hosszú lett, ide tettem fel: [link]
(A host nevét átírtam myhostra.)Szerintetek mit lehetne ezzel kezdeni, hogyan tudnám rávenni, hogy megújítsa a tanúsítványt?
Előre is nagyon köszönöm a segítséget.A rendszer CentOS 7 (3.10.0-957.1.3.el7.x86_64), a gép egy Dell Latitude D630 laptop.
[ Szerkesztve ]
-
Andralin
aktív tag
válasz Fecogame #27816 üzenetére
Kipróbáltam. Az Apache leállítása után az előző hibaüzenet még ezekkel a sorokkal egészül ki a certbot renew futtatása során:
Error while running apachectl graceful.
Job for httpd.service invalid.
Unable to restart apache using ['apachectl', 'graceful']Ha jól értem, próbálja ő újraindítani az Apache-ot. És sikerül is neki, mert gyakorlatilag elindul, de mégis a fenti üzenetet adja.
-
Andralin
aktív tag
válasz Jester01 #27819 üzenetére
Belenéztem abba scriptbe, de olyan szinten nem értek hozzá, hogy meg is értsem mi lehet a gond.
Ami érdekes, hogy több mint egy éven át tökéletesen működött a dolog, lefutott a certbot-os megújítás hiba nélkül. Most meg hirtelen leállt ezzel a hibával.
De ma reggel végül sikerült működésre bírnom!
Mivel egyértelmű volt, hogy a certbot valamiért nem tud az Apache-al kommunikálni többé, futottam még pár kört a certbot körül és rájöttem, hogy saját maga is tud kommunikálni a 80-as porton az ellenőrzés lefuttatására a --standalone opcióval, csak ehhez le kell állítani addig a webszervert.Szóval az Apache leállítása után a certbot renew --standalone hibátlanul lefutott és ismét érvényes a SSL tanúsítványom további három hónapra.
Nagyon köszönön a tippeket, tanácsokat!
[ Szerkesztve ]