und ich dachte schon ein G9.5 auf dem Du alleine bist. 
Beiträge von hoedlmoser
-
-
net schlecht. was ist denn das für einer?
-
Ich denke mal, bei einem upgrade bleibt der Serverstandort erhalten.
das stand ja auch so in den FAQs zum RS G9.5. aber ich war überrascht, daß ich von einem G9 VIE auf einen standortlosen G9.5 upgraden kann. und selbst jetzt nach diesem upgrade kann ich auf VIE- und standortlosen-tarif upgraden.
das würde aber in weiterer folge bedeuten, daß man sich einfach einen RS am gewünschten standort in einer kleineren ausführung bestellt und dann auf die nächsthöhere ausstattung im standortlosen tarif upgraden kann. hm?
am "um" erkennt man den Österreicher
das ist nicht das einzige erkennungsmerkmal von Österreichern.
-
korrekt, um 61 €cent (AT MwSt
) gabs upgrade von zwei auf vier kerne und der server verblieb in VIE. -
huch^2, ich konnte gerade meinen 'RS 1000 G9 a1 VIE 12M' auf den standortlosen 'RS 1000 G9.5 a1 12M' upgraden.
-
Gemessen mit den Parameter von m_ueberall
huch, da hat sich allgemein etwas getan an der performance. ich bin sehr positiv überrascht. mehr performance ohne einen G-.5-upgrade.
VPS 200 G8
vorher: read: IOPS=3214, BW=12.6MiB/s (13.2MB/s), write: IOPS=1074, BW=4298KiB/s (4401kB/s)
nachher: read: IOPS=13.0k, BW=50.9MiB/s (53.4MB/s), write: IOPS=4357, BW=17.0MiB/s (17.8MB/s)
RS 1000 G9 a1 VIE 12M
vorher: read: IOPS=20.4k, BW=79.6MiB/s (83.5MB/s), write: IOPS=6812, BW=26.6MiB/s (27.9MB/s)
nachher: read: IOPS=52.7k, BW=206MiB/s (216MB/s), write: IOPS=17.6k, BW=68.9MiB/s (72.2MB/s)
das ist mehr als ein faktor zwei! entweder hat netcup hier massiv hardware nachgeschmissen und die RS jetzt neuverteilt (brauchen sie dazu diesen neue-KVM-version-restart?) oder limits geändert oder wirklich noch einen parameter gefunden oder ...
ich denke der m_ueberall sollte in sein 'VServer IOPS Comparison Sheet' ein datum der messung einfügen.
-
Mein RS 2000 WSV22 bringt hier aber nur ca 40 MB/s read und ca 15 MB/s write.
deckt sich mit meinen messungen in Nürnberg.
also ich bleib in Wien.
-
das beantwortet die eigentlich Frage aber nicht;
darum sagte ich ja der Aluhut ist auf Deiner Seite
ich blockier kein ICMP.
-
erklär mir, wie so ein Paket zu mir kommen kann, ohne,
dass es das Ergebnis eines zuvor versendeten Paketes ist?
die manpage von iptables und dem status related ist da eindeutig:
ZitatRELATED The packet is starting a new connection, but is associated with
an existing connection, such as an FTP data transfer or an ICMP
error.
-
deswegen ...
aluhut. dann viel spaß mit zb Fragmentation Needed (IPv4) / Packet Too Big (IPv6).
aber wer sein heil in einer accept policy findet, dem ist eh nicht mehr zu helfen.
-
wenn ich hier an Stelle ACCEPT aber DROP nehme, dann bricht die Leitung ein
entgegen der von mir oben verlinkten und zitierten antwort von serverfault muß ich mich korrigieren, DROP verwirft das packerl gänzlich, da antwortet der server mit genau nix!
warum bei Dir im gegenständlichen fall die leitung einbricht wenn der server die packerle verwirft erklärt sich mir nicht, kann aber wahrscheinlich nur in zusammenhang mit Deinem router gesehen werden.
hier seien meine ergebnisse bzgl iptables mit drop und reject zusammengefasst:
client versucht sich am server auf port 23 via TCP zu verbinden, dort lauscht aber kein daemon
- in einem jungfräulichen zustand (policy accept und keine rules) meldet der client ein 'Connection refused', im tcpdump sieht man einen reset und nmap meldet den port als closed.
- mit der policy drop braucht der client 2 minuten und 10 sekunden um ein 'Connection timed out' zu melden, im tcpdump sieht man nur wiederholte syns des client, nmap sieht den port nach knapp 2 sekunden scan als filtered.
- mit einer expliziten reject rule meldet der client ein 'Connection refused', im tcpdump sieht man einen 'ICMP tcp port unreachable' und nmap meldet den port als filtered.
- mit einer tcp reset reject rule meldet der client ein 'Connection refused', im tcpdump sieht man einen reset und nmap meldet den port als closed.
ein interessanter artikel bzgl DROP vs REJECT sei auch noch erwähnt http://www.chiark.greenend.org…rb/network/drop-vs-reject er kommt zu dem konklusio, daß man DROP aus clientsicht wegen timeouts vermeiden möchte.
offensichtlich das einzig Richtige ...
offensichtlich keine ahnung. oder hast Du am ende Deines regelwerks noch eine catch-all reject rule?
wenn ich die paar Ports welche ich von bestimmten Quellen offen brauch,
mit einer 2ten Regel
[...]
terminiere
Du weißt aber schon, daß der erste match greift?! da kannst Du danach rejecten was Du willst.
All 1024 scanned ports on #DNS (#IP) are closed
aus meinen empirischen tests von oben leite ich mal ab, daß nmap dann einen port als closed meldet, wenn mit einem RST geantwortet worden ist. das heißt aber in weiterer folge, daß Du die packerle nicht dropst. sondern entweder in iptables mit einem 'REJECT --reject-with tcp-reset' oder Dein betrübssystem einen TCP RST raus haut.
einzig gewußt hätt ich, wie ich das 'Host is up' auf 'Host is down' hier bring; ICMP wird gedropp'd
wozu dropped man ICMP? ist das schon wieder so ein 'security by obscurity' ding?
und wenn Du das wirklich auf down haben willst, dann könnte man das in der man page von nmap nachlesen, ich hab das mal für Dich getan.
ZitatIf no host discovery options are given, Nmap sends an ICMP echo request, a TCP SYN packet to port 443, a TCP ACK packet to port 80, and an ICMP timestamp request.
-
warum bricht meine Leitung ein, wenn ich alles mit DROP terminiere, und nichts antworte?
man findet auch einiges zum Thema DROP vs. REJECT
ich hab es bis jetzt mit der Default-Regel DROP
die Default Policy von DROP auf ACCEPT geändert
was jetzt? drop, reject oder accept?
wir reden hier schon von der default-policy, ja? könnt noch immer sein, daß Du als letzte rule eine catch-all drinnen hast die dann anders als die default-policy "abweist".
und die default-policy ingres auf accept zu stellen ist imho keine gute idee!
unabhängig davon was Du eingestellt hast, es steht alles in der von mir verlinkten antwort.
CodeWhen using DROP rules: - UDP packets will be dropped and the behavior will be the same as connecting to an unfirewalled port with no service. - TCP packets will return an ACK/RST which is the same response that an open port with no service on it will respond with. Some routers will respond with and ACK/RST on behalf of servers which are down. When using REJECT rules an ICMP packet is sent indicating the port is unavailable. -
man findet auch einiges zum Thema DROP vs. REJECT
die Frage die ich mir stelle - wahrscheinlich macht es einen Unterschied ob UDP od. TCP - wie
'schont' das die Resourcen ...
ich hab das mal für Dich gegoogelt: https://serverfault.com/a/157418
fetten Anbindung mit 200 MBit/20 MBit
das nennst Du fett? wenn da ein portscan mit 200 MBit/s auf Dich hereinprasselt und Du alles brav mit TCP/RST beantwortest hab ich in null komma nix Deinen uplink zugemacht.
-
Das verlagert die Arbeit darauf, dieses Kochrezept zu schreiben.
die werden hier in ansible geschrieben, damit ziehe ich den host und die container hoch.
-
es gibt nicht so viele fertige Container, die man einfach spawnen kann
genau das will ich gar nicht. ich will hier nicht einen zb zoo von mysql servern, nur weil jeder container glaubt er müsse seinen eigenen mithaben.
ZT selbst läuft dafür in einem Host Network Container. [...] Ich route bislang gar nix.
macht dann dieser Network Container NAT? oder wie weiß ein anderer container wo er die rückantworten hin schicken soll? oder ist da der host eh default gateway und kanns dann zum ZT container richtig routen?
-
Was stört dich denn an Docker so?
bei der ersten begegnung hats gleich mal das lokale iptables getötet.
nein, ich will keinen port vom host mappen, der container soll bitte eine eigenständige IP haben.
ich will keine bloat container, die alles mit haben weil der entwickler zu faul ist sich um kompatibilität zu kümmern.
mir ist ein upgrade sympatischer als ein re-deployment.
-
dass man dann kein WLAN mehr braucht, wenn man überall dort wo man die Ufos (a la Access-Points) anbringen will, eine Ethernetverkabelung hinbringen muss; weil dann hat man ja eh das Ethernetkabel
echt? Du spannst dann 5 m ethernetkabel durch die luft? hier im haus gibts in jedem raum zweimal cat6 und es ist entweder falsch positioniert, zu wenig oder unbenutzt. da wären die topferl an der decke die ultimative lösung!
-
Docker Container
ich hasse docker!
hier sinds aktuell handgeschnitzte KVM VMs, es sollen jetzt proxmox container werden, kreiert mit ansible.
https://www.zerotier.com/ , ebenfalls in einem Container
also doch nicht am host. und verbindest Du da dann verschieden LANs, oder doch nur einen client? wenn Du LANs verbindest, routest Du dieses dann zwangsweise übern host, oder bekommt jede(r) container, VM eine entsprechenden routingeintrag?
Und davor hängt für Webanwendungen https://nginxproxymanager.com/ für die SSL Terminierung.
ist eh hypsch, bin hier aber fan von config files und ein wenig magie in bash-scripten.
-
Oder habe ich einen Aspekt nicht verstanden?
ich hab ihn nicht erwähnt: hier gibts keine kunden-spezifischen VMs, nur service-spezifische.
prinzipiell behandle ich den aus VPNs eingehenden verkehr wie von extern. jede VM hat ihre eigene (iptables, nft) firewall.
hauptverwendungszweck hier soll das zusammenschalten des host- und des zuhause-LANs sein (oder aber auch mal die wartung von unterwegs), so gelingt dann auch der direkte zugriff auf die VMs ohne IPv6.
aber ich sehe schon, ihr seht keine sicherheitsrelevanten aspekte einen VPN server am host laufen zu lassen. das bestärkt mich in meiner meinung und bisherigen praxis.
-
Ich nutze WG direkt auf dem Server. Warum die extra Ebene einbauen
ich versuch am host so wenig wie möglich laufen zu lassen. aber gerade bei VPN server bin ich da jedesmal unschlüssig.
eins spricht auch noch dafür es am host laufen zu lassen: ich muss die VPN-netze nicht auch noch in die VM routen.
