Beiträge von frank_m

Kannst das Defaultgateway noch pingen? Wie weit kommt ein traceroute auf Google?

Zitat von KrisAusEU

Wie und wo kann ich nun einstellen, das PC XY in meinem LAN nun von außen unter der IP erreichbar ist?

Du meinst die IP vom VPS?

Zunächst musst du sicherstellen, dass du PC XY von deinem VPS aus erreichen kannst, z.B. Ping. Geht das? Wenn das der Fall ist, musst du eine entsprechende iptables Regel erstellen. Nehmen wir an, dein Netz Zuhause benutzt die 10.42.42.0/24 und PC XY ist 10.42.42.21 und soll Port 8080 bekommen:

iptables -t nat -A POSTROUTING -s 10.42.42.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.42.42.21:8080

Das musst du dann für deine Dienste entsprechend anpassen.

Das ganze muss natürlich in dein Firewallkonzept für den VPS eingepasst werden. Alternativ zu iptables kannst du natürlich auch nftables oder ufw oder so verwenden.

Das SCP kommuniziert mit dem KVM Backend auf dem physikalischen Server. Es hat keinen direkten Zugriff in "deine" VM.

Hast du mal versucht, in den OVMF Settings die Auflösung anzupassen?

Nachtrag:

Habs gerade mal auf die Schnelle mit einer Windows Server 2019 Evaluierung probiert. Auflösungen von 1280x720 und 1280x1024 ließen sich problemlos einstellen.

Ihr müsst nur einen intelligenten Weg finden, ins Bios zu kommen. Ich habs auf die Schnelle über das Boot Menu einer Ubuntu Installations-CD gemacht. Aber da gibt es vielleicht auch geschicktere Wege.

Für IPv6 hat sich bei mir die Situation ein Stückweit normalisiert, obwohl ein Traceroute immer noch Amsterdam als Hop anzeigt. Für IPv4 hat sich aber noch nichts getan.

Nachtrag: Wie erwartet geht der Hinweg von mir zu Hause zu Netcup noch über Amsterdam, der Rückweg aber nicht mehr. Daher die Zeitrsparnis.

Ja, seit gestern 17 Uhr hat sich was verändert. Meine Pakete werden wieder über Amsterdam geleitet.

Das Tools prüft nicht SSL, sondern DNS Zonen, vor allem den Zustand von DNSSEC.

Zitat von aRaphael

Gibt es einen Grund der dagegen spricht? Nicht, dass ich mir damit evtl. andere Probleme einhandele.

Ich nutze das auch. Ebenfalls ohne Probleme, davor kann optional ein Pi-Hole geschaltet werden (für meine VPN Clients). Das Setup hat sich als äußerst stabil und flexibel erwiesen.

Aber: Ihr erinnert euch an die DNS Probleme mit dem Auflösen von de.archive.ubuntu.org, die auf eine fehlerhafte DNS Konfiguration der Uni zurückzuführen war, die diesen Dienst bereitstellt (war kein Netcup Problem). In die gleiche Falle, in die damals die Nutzer der Netcup DNS Server liefen, bin ich mit meinem eigenen unbound auch gelaufen, wenn ich DNSSEC als zwingende Voraussetzung konfiguriert hatte.

Zitat von fansari

Dabei hatte ich mich auf das zusätzliche Netz bezogen.

Ach, du hast ein zusätzliches Netz? Das war mir nicht klar. Ich dachte, du arbeitest auf dem mitgelieferten Netz.

Zitat von fansari

Beim Standardnetz hatte ich keine "anfänglichen Paketverluste" sondern es ging überhaupt nicht.

Dann war aber noch irgendwas falsch eingerichtet. Denn grundsätzlich funktioniert das, bis auf die Startschwierigkeiten, die man zwar minimieren, aber nicht beseitigen kann.

Zitat von fansari

Du hast wieder Recht: ich habe das Proxy NDP mal rausgenommen und es funktioniert immer noch

Wann habe ich das gesagt? Du brauchst einen NDP Proxy, entweder durch ip Einträge, ndppd oder den ndpresponder. Sonst ist nach kurzer Zeit Schluss.

Zitat von fansari

Wobei ich mich dann frage, warum denn das Standard Netz nicht auch geroutet wird.

Das ist auch bei anderen Anbietern üblich, und eigentlich auch nicht schlimm. Das Problem sind die anfänglichen Paketverluste. Alles andere kann man lösen.

Zitat von fansari

Den ndppd verwende ich nicht - ich mache Proxy NDP für jede Adresse einzeln.

Das ist ok. Nach meinen Erkenntnissen macht es keinen Unterschied, ob man selber Proxy Einträge erzeugt, den ndppd oder den ndpresponder verwendet.

Zitat von fansari

Mein Routing arbeitet mit einem /96er Netz, das innerhalb des /64er Netzes liegt. Anders geht es nicht, wenn man nur ein /64er Netz hat.

Ja, das ist grundsätzlich ok. Es funktioniert sogar, wenn man /64 auf dem WAN Interface des Servers aktiv lässt, wobei man dort theoretisch auch mit einem kleineren

Subnetz arbeiten kann.

Wichtig ist, dass die Routen zum Interface mit dem /96 Netz stimmen. Hast du das kontrolliert? Und iptables (bzw. vergleichbare Tools) erlauben ebenfalls das Zustellen weitergeleiteter Pakete?

Zitat von fansari

Was es mit dem "Cache der Infrastruktur" auf sich hat weiß ich nicht. Auf die habe ich ja eh keinen Einfluss.

Doch, hast du. Siehe den verlinkten Beitrag.

Zitat von fansari

Eigentlich müsste doch das komplette /64er Netz an meinen Host durchgereicht werden. Oder verstehe ich da etwas falsch?

Es werden natürlich nur Pakete durchgereicht, für die es ein Neighbor Advertisement gibt. Es gibt keine Gateway Adresse, an die alle Pakete zugestellt werden, wie bei einem gerouteten Subnetz.

Zitat von fansari

Dann müsste ich doch zumindest mit tcpdump ankommende Pakete sehen.

Ja, die sieht man auch, wenn alles richtig eingerichtet wird. Aber wie im anderen Beitrag dargestellt: Anfänglich kommt es zu masiven Paketverlusten, wenn du keine Gegenmaßnahmen ergreifst. Hast du das bedacht?

Zitat von fansari

Was ich aus dem Post, den du geschickt hast herauslese: ist es richitg, das man ein zusätzliches IPv6 Netz buchen muss, damit Proxy NDP funktioniert?

Nein, wenn du ein zusätzliches IPv6 Netz buchst, dann brauchst du keinen NDP Proxy mehr. Den braucht man nur fürs mitgelieferte Subnetz.

Zitat von przla

wieso macht Netcup eigentlich sowas per default und ohne Hinweis?

Warum hast du beim Installieren des Images nicht einfach angegeben, dass du die ganze Platte nutzen willst? Danach wird man ja gefragt.

Zitat von przla

Diesen Hinweis findet man in solchen Foren leider immer. Immer ein bisschen von oben herab formuliert.

Wir sind halt hier bei Netcup gebrannte Kinder, weil die Netcup Subnetze immer wieder auf Blacklists landen, weil über die Server Schadsoftware verteilt wird. Über die öffentlichen IPs kommt im Schnitt ein Hack-Versuch pro Sekunde rein. Und jemanden, der nicht mal mit den Partitionierungstools umgehen kann, den fragt man schon gar nicht mehr nach iptables ...

Denk dran: Du wirst vor Gericht landen und zahlst für den Scheiß, den andere mit deinem Server machen. Der Hinweis war kein Scherz.

Ich nehme mal an, IP-Forwarding, Routing und Firewall hast du entsprechend aufgesetzt? Das würde auch zuverlässig erklären, warum die Pakete nicht ankommen.

Wenn die Einträge aus dem Cache der Infrastruktur weg sind, kommt es zu Paketverlusten, vor allem am Anfang der eingehenden Verbindungen. Je nach Maßnahmen, die man ergriffen hat, mal mehr und mal weniger:

Wie äußert sich das alles denn? Bekommt der Server keine IPs? Oder funktioniert das Routing nicht? Was ergeben Pings und Traceroutes auf google.com?

Bitte mal ins Wiki schauen, die Lösung für dieses Problem wurde da erklärt. Wurde die Installations-CD nach der Treiber-CD wieder eingelegt?

Bitte beachten: Windows Server direkt am Internet zu betreiben, kann sehr gefährlich sein. Stimmt das Firewall Konzept? Das sollte vor der Installation angepasst werden.

So you have created the network configuration manually and are now trying to convince proxmox using it as foreseen? That is risky. I would do it the other way around: let proxmox create the network config and adjust it if needed.

Well, it should also work with two bridges, vmbr0 and vmbr1, if the vmbr0 is the external interface and vmbr1 is the internal interface.

It is crucial to have NAT activated, otherwise the containers won't get internet access.

Is it always the case that Proxmox puts the main LAN port in a bridge (ens3 in vmbr0)? Which ports are additionally in vmbr0? If ens3 is the only port: Why do you need this bridge?

As far as I remember the main LAN port of the server was active as usual having the public IPs of the server. Additionally, there was one bridge (vmbr0) containing the ports of the containers having a private network for IPv4 as well as for IPv6. Finally, NAT for IPv4 and IPv6 was activated in order to bring the containers on the internet.

It's hard to estimate what a table shall show you if you can't see what's the columns are meaning.

Für die Zone ist dnssec aktiviert. Aber das hilft mir ja nicht für den Nameserver der Subdomain weiter.