- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Milyen okostelefont vegyek?
- Fotók, videók mobillal
- Mobil flották
- Xiaomi 14 Ultra - Leica hercegnő
- Vodafone mobilszolgáltatások
- Samsung Galaxy S22 és S22+ - a kis vagány meg a bátyja
- ReVanced patch-elt alkalmazások és Youtube Android alkalmazás alternatívák reklámszűréssel / videók letöltése
- Elcsípte a Huawei kameratelefonja az első helyet
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
Hirdetés
-
Mégis kap egy utolsó nagyobb frissítést a Redfall
gp A készülő update többe között offline módot is elhoz azok számára akik még mindig kitartanak a játék mellett.
-
Posztapokaliptikus Radeon kártya készül a Sapphire műhelyében
ph A Navi 32 GPU-ra épülő, limitált darabszámú modell a vizuális dualizmus jegyében született, és a 11 Bit Studios láttamozta.
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
-
Mobilarena
ASUS WL-500G Premium
Új hozzászólás Aktív témák
-
AtHoS
nagyúr
AEGA-nál a terhelésre most már három érték olvasható: 1.24,1.58,1.66
Melyik mit takarhat?Közben észrevettem, hogy délutánra az rtorrent forgalma erősen visszaesett, köszönhetően UPC priorizálásos tevékenységének. A múltkoriban már kezdtem kicsit pedzegetni az UDP portok megnyitását, de azt hiszem még nem sikerült maradéktalanul beállítgatnom.
Gondoltam majd most megint bepróbálkozom illetve az rtorrent forgalom titkosítását is meglestem mit lehet kezdeni vele.
Titkosításra a következőket találtam. rtorrent.conf vagy .rc fájlban kell matatni a encryption = sort, ahol a következő paramétereket lehet kombinálni:
• allow_incoming (elfogadja a bejövő titkosított kapcsolatokat)
• try_outgoing (használja a titkosítást kimenő kapcsolatokhoz)
• require (nem fogadja el titkosítatlan kapcsolat kezdeményezést (handshake) másik klienstől)
• require_RC4 (letiltja a sima szöveges (plaintext) adat továbbítást titkosított kapcsolat kezdeményezés (handshake) létrejötte után)
• enable_retry (ha a kimenő kapcsolat létrejötte sikertelen volt, akkor kikapcsolja a titkosítást, ha az be volt kapcsolva vagy bekapcsolja azt ha előtte ki volt kapcsolva)
• prefer_plaintext (sima szöveges adattovábbítást (plaintext) választ ki, amikor a többi kliens (peer) felkínálja a választást sima szöveges adattovábbítás és RC4 titkosítás között. Minden egyéb esetben RC4 titkosítást használ)Na egyből kreáltam egy ilyen sort hozzá:
encryption = allow_incoming,try_outgoing,enable_retry,prefer_plaintextA use_udp_trackers = yes sort azért nem árt aktivizálni hozzá.
Közben leállítottam az összes rtorrent folyamatot ruTorrent webui-n keresztül. Most hagytam neki elég időt a leállításhoz, mivel közben álltam neki szerkeszteni a konfig fájlt illetve gondoltam, hogy az S99rtorrent fájllal fogom leállítani az rtorrent-et. MC-vel kicsit belenéztem az S99rtorrent-be és meglepetten tapasztaltam, hogy IPTABLES részt is tartalmaz. Egyből feltűnt, hogy csak TCP-re van benne sor:
iptables -I INPUT -i "$1" -p tcp --syn --dport $P -j ACCEPT
itt a $P az rtorrent.conf fájl-ból kinyert port tartomány egy eleme, amit egy FOR ciklussal futtat végig a script. Tehát már itt beállításra kerül az rtorrenthez szükséges port.
Gondolom a postfirewall-ban emiatt nincs szükségem külön megnyitni az rtorrent-hez rendelt portokat, mivel az rtorrent indító script ezt ugye megteszi.Nos az UDP működéséhez beszúrtam közvetlen a másik sor alá egy
iptables -I INPUT -i "$1" -p udp --syn --dport $P -j ACCEPT
sort.
Az előbbi fwopen() részhez tartozott, így a fwclose() részt is hasonlóan szerkesztettem át.
Elindítva az rtorrentet az S99rtorrent segítségével viszont arcomba dobott
/opt/etc/init.d/S99rtorrent start
Starting rtorrent
iptables v1.3.8: Unknown arg `--syn'
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.3.8: Unknown arg `--syn'
Try `iptables -h' or 'iptables --help' for more information.
iptables v1.3.8: Unknown arg `--syn'
Try `iptables -h' or 'iptables --help' for more information.Nem tudom mit tesz a --syn, de ha jól veszem ki, akkor nem kellene, hogy ott legyen az iptables sorokban.
Mindenesetre a délután tapasztalt 8-10KB/s le- és feltöltés kicsit megugrott 200KB/s le és 70-80KB/s körüli feltöltésre. Jelenleg 1 torrent van letöltés alatt, ennél 15 peerhez és 3 seed-hez kapcsolódott. A többinél csak feltöltés van, ezeknél 2-3-hoz kapcsolódik.
AEGA-ban megnézve a terhelést 1.29,1.40,1.28 környékén van.Talán most már rendben lesz az UDP és a titkosítás használata is.
A post-firewall fájlhoz most nem nyúltam, de úgy érzem pár sort ki kellene törölni belőle, mivel teljesen fölöslegesen szerkesztettem bele a múltkor.
Így néz most ki a post-firewall fájlom:#!/bin/sh
iptables -I INPUT -m tcp -p tcp --dport 6880:6882 -j ACCEPT
iptables -I INPUT -m udp -p udp --dport 6880:6882 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p udp --dport 443 -j ACCEPT
iptables -t nat -A PREROUTING -i "$1" -p tcp --dport 6880 -j DNAT --to-destination "$4":6880
iptables -t nat -A PREROUTING -i "$1" -p tcp --dport 6881 -j DNAT --to-destination "$4":6881
iptables -t nat -A PREROUTING -i "$1" -p tcp --dport 6882 -j DNAT --to-destination "$4":6882
iptables -t nat -A PREROUTING -i "$1" -p udp --dport 6880 -j DNAT --to-destination "$4":6880
iptables -t nat -A PREROUTING -i "$1" -p udp --dport 6881 -j DNAT --to-destination "$4":6881
iptables -t nat -A PREROUTING -i "$1" -p udp --dport 6882 -j DNAT --to-destination "$4":6882
iptables -t nat -A PREROUTING -i "$1" -p tcp --dport 443 -j DNAT --to-destination "$4":443
iptables -t nat -A PREROUTING -i "$1" -p udp --dport 443 -j DNAT --to-destination "$4":443amiből a 6880-tól 6882-ig terjedő port tartományhoz tartozó PREROUTING sorokat kellene eltávolítani és csak a 443-hoz tartozót meghagyni.
Ha jól sejtem, akkor a PREROUTING oldja meg a portforward-ot, aminél ugye az rtorrent-hez rendelt 6880-6882 portok-at fölösleges forwardolni.
read-only mode on the forum
Új hozzászólás Aktív témák
● Olvasd el az összefoglalót!
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest