Hálózatok általános

Telekom internet + IPTV saját rúterrel

Sziasztok!

Jelenleg van 1 Telekom lakossági előfizetés, amihez a T adott 2 db eszközt. Az egyik a rúter+Wifi-t szolgáltatja. Ebbe az eszközbe jön be az optikai kábel. Innen megy tovább 1x UTP a másik T eszközbe, ami pedig a TV-nek adja a képet, illetve ez csinálja a músor felvételt/visszajátszást.

Szeretnék a Telekom rútere helyett sajátot használni, leginkább IPSEC tunnel kiépítése miatt. Azaz a T rúterét lebutítani bridge-only módba. A Wifi-t megtartanám a T eszközén, bár nem egészen látom ez lehetséges-e ilyen topológiában.

Mivel nem vagyok helyben az eszköznél, kérdéseim:

- a Telekom ilyen IPTV-s internetszolgáltatásnál PPPoE-t használ username+password, vagy sima IP kapcsolatot kell állítani a WAN-ra?
- publikus IPv4 címet + a bridge módot hogyan kell kikövetelni az ügyfélszolgálaton keresztül?
- egyéb szopás amibe bele fogok futni?

BIND wildcard aldomainen _belül_

Sziasztok

Elakadtam, google sem segít. Életem könnyítésére ezt szeretném bejegyezni egy bind zónafájlba:

*-teszt CNAME ...

Sajnos csak a *-teszt.domainevem.hu -t oldja fel, ténylegesen csillaggal lekérdezve. Bármit nem helyettesít be.
Ha *.teszt CNAME -t jegyzek be, úgy bármire feloldja a *-t.

Hogyan tudok wildcardot használni subdomain néven _belül_ és nem önállóan?

Köszönöm!

Mikrohullámú internet tapasztalatok

Sziasztok!

 

Kiváncsi lennék, hogy kinek milyen tapasztalata/véleménye van mikrohullámú internettel kapcsolatban? Szeretnék kiköltözni Budapestről az aggolmerációba, meg is találtam azt a házat, ami szimpatikus lenne, viszont jelenleg nincs vezetékes szolgáltató az utcában. Ennek áthidalásán gondolkodnék mikrohullámú internetben, találtam is egy szolgáltatót, aki viszonylag erős (80/25, 30% sávszélesség garantált beföldi irányba, 10% külföldre) csomagot tenne lehetővé. 

Az lenne az elvárt teljesítmény, hogy 2-3 gép folyamatosan VPN-n keresztül kommunikáljon, a lehetőséghez képest stabilan, valamint ne okozzon gondot, ha bármelyik gép, eseteként egyidőben mindegyik videókonferencián vesz részt. 

A távolság/rálátás/időjárás okozta nehézségekkel valemennyire tisztában vagyok. 

Alternatívaként gondolkodtam 4G megoldáson, de helyszíni mérések alapján gyenge eredményt kaptam (20-30Mbit le/fel)

 

Előre is köszi.

vycontrol help

Sziasztok!

Szintet léptem dockerben, fut a vycontrol...

Már egy kicsit recseg nálam a google, de még így sem találtam, mivel lehet belépni?

Vagy, ha csak a nyögvenyelős telepítés miatt átugrottam a login beállítást, hogyan lehet resetelni?

Köszi:

Mukk

opendns furcsaság

Sziasztok!

Freedns.afraid.org-ról frissítek dinamikus ip-t. DNS szervernek opendns-t használok, mert eddig ez tűnt a legjobbnak.

2-3 percen belül már hozta a frissített ip-t a közelmúltig. Újabban szintén hozza az új ip-t, hasonlóan gyorsan,

azután visszatér a régire. Most elkezdtem tesztelni, lassan nő a jó ip-k aránya, de mindig be-becsúszik egyszer-egyszer a

régi ip is. Gentoo, manjaro és debian alól is próbáltam, ugyanaz.

Találkoztatok ilyennel? Saját DNS cache-re azért nem gyanakszom, mert az miért ugrana vissza az előzőre ip-re...

Köszi!

( Megoldva ) - Naponta néhány csomag eltűnik - tcpdump szerint a szerverről kimegy, de kliensre nem érkezik meg

Sziasztok,

jelezte az ügyfél, hogy néha (napota, kétnaponta egyszer) connection timeoutot kap egy két kliensgép az egyik szerverünkről (Red Hat 7).

Az egyik kliensgép (legyen a neve A) a saját környezetünkben fut, ahol az érintett szerver (legyen a neve S) is van. Míg a másik kliensgép (legyen a neve B) egy külső szolgáltatónál fut, erről semmi infónk nincs és hozzáférésünk sincs.

A szerveren futtattam 3 napig tcpdumpot és a "mi" kliensünkön (A) is. 3 nap alatt egyszer fordult elő timeout e két gép között (3 nap dumpja 14 mega, 47 ezer csomag). Ping is ment 3 napig, nem volt packet loss, illetve az összes többi gép többi (tcp) kapcsolata rendben volt.

tcpdump szerint a szerverre bejött a syn csomag, és a szerver válaszolt is a kliensnek, megy ki az ack, de a kliensen nem látszik, hogy bejött volna a válaszcsomag.

A kliens vár, majd küld egy retransmission syn-t, de arra sem érkezik meg a válasz, majd megint megy ki egy rts syn és így tovább... végül 1 perc után timeoutol.

Szerver oldalon minden csomag beérkezik és mindre ki is megy a válasz.


B kliensen, ami nem a mi környezetünkben van, nem tudtam tcpdumpot futtatni, de a szerveroldali dump ugyan úgy néz ki, mint az A kliens esetében. Bejönnek az rts sny csomagok a szerverre, ő válaszol is rájuk, mégis timeout lesz, valószínűleg a B kliens sem kapja meg a csomagokat. Mindez naponta, kétnaponta 1x fordul elő egy tcp kapcsolatnál. Az összes többi kapcsolat a két gép között rendben van, azok is amik ugyan erre a portra (az ügyfélnek valami egyedi alkalmazása figyel rajta) jönnek.

Linux tűzfal kizárva, mert alaposan utánaolvastam és a tcpdump a bejövő csomagokat még az iptables előtt rögzíti. Van központi tűzfalunk is, de azon engedélyezve vannak a szükséges dolgok, illetve máskülönben egyáltalán nem menne a  dolog és nem csak napi 5-10 csomag tűnne el. Alkalmazás hibát is kizárnám, hiszen megy ki válasz. Létezhet, hogy mégsem megy ki a csomag a hálózatra, hanem tcpdump után még eltűnik valamelyik bufferből vagy ilyesmi? Bár néztem a net.ip4.tcp_rmem és wmem paramétereket 6 mega a max, és a timeout időszakban (éjszaka) nem volt semmi extra hálózati vagy cpu terhelés a gépen, ami miatt a buffer tele lett volna...

Van ötletetek, hogy mit lehetne megnézni még OS vagy hálózati szinten?

Köszi előre is! Íme a tcpdump:

Szerveren:

Source  Destination        Protocol              Length  Info

A             S             TCP        74           43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670891310 TSecr=0 WS=128

S             A             TCP        54           10636 → 43832 [ACK] Seq=1 Ack=3370289340 Win=1355 Len=0

A             S             TCP        74           [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670892312 TSecr=0 WS=128

S             A             TCP        54           [TCP Dup ACK 31921#1] 10636 → 43832 [ACK] Seq=1 Ack=3370289340 Win=1355 Len=0

A             S             TCP        74           [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670894316 TSecr=0 WS=128

S             A             TCP        54           [TCP Dup ACK 31921#2] 10636 → 43832 [ACK] Seq=1 Ack=3370289340 Win=1355 Len=0

A             S             TCP        74           [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670898320 TSecr=0 WS=128

S             A             TCP        54           [TCP Dup ACK 31921#3] 10636 → 43832 [ACK] Seq=1 Ack=3370289340 Win=1355 Len=0

A             S             TCP        74           [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670906336 TSecr=0 WS=128

S             A             TCP        54           [TCP Dup ACK 31921#4] 10636 → 43832 [ACK] Seq=1 Ack=3370289340 Win=1355 Len=0

A             S             TCP        74           [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670922368 TSecr=0 WS=128

S             A             TCP        54           [TCP Dup ACK 31921#5] 10636 → 43832 [ACK] Seq=1 Ack=3370289340 Win=1355 Len=0

A             S             TCP        74           [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670954432 TSecr=0 WS=128

S             A             TCP        54           [TCP Dup ACK 31921#6] 10636 → 43832 [ACK] Seq=1 Ack=3370289340 Win=1355 Len=0

 

Kliensen:

Source  Destination        Protocol              Length  Info

A             S             TCP        74           43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670891310 TSecr=0 WS=128

A             S             TCP        74           [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670892312 TSecr=0 WS=128

A             S             TCP        74           [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670894316 TSecr=0 WS=128

A             S             TCP        74           [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670898320 TSecr=0 WS=128

A             S             TCP        74           [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670906336 TSecr=0 WS=128

A             S             TCP        74           [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670922368 TSecr=0 WS=128

A             S             TCP        74           [TCP Retransmission] 43832 → 10636 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=670954432 TSecr=0 WS=128