Oder beachte ich hierbei irgendwas nicht?
Du beachtest die Netzwerkverbindung zwischen den beiden Systemen nicht.
Posts by H6G
-
-
if this is not possible , how we can install an hypervisor on netcup network .
KVM, (Xen) and Proxmox are working fine, because the hypervisor host is a Linux machine where NAT can be used.
I don't doubt that many customers are using ESXi on the network here. But I'm sure there are using a second IP with a routing VM then.
For IPv6 you'll need a neighbor discovery proxy, because not the entire subnet is statically routed to your server.
-
vmk ist das bezogen auf vmware oder allgemein?
Ich weiß leider nicht welchen Unterbau vmware benutzt. Bei Citrix' XenServer ist es offensichtlich, aber welche Linux / Unix Tools unter ESXi zur Verfügung stehen: kein Plan. Ansonsten geht es nur mit zweiter IP und einer VM fürs Routing mit Linux.
Wenn aber ESXi den nötigen Linux Stack hat, dann ist es auch mit einer IP möglich.
-
why not , i can use it as long as ipv4 is disabled on my ESXi host.
That IP is bounded to the physical network card of your host and is terminated there. Your IP cannot be a hop for yourself. There is no way of forwarding that IP to a VM while being used on your primary. If you disable IPv4 on the host, how are the packets supposed to get to the VMs? That would only be possible by bridging the outside NIC to the vswitch and I don't think that is going to work on netcup's network.
problem is not routing or IP , it is related to vswitch and vnic and how the VMs are communicating with external network
Your problem is Layer3 (Routing / IP). vswitch and vnic are Layer2. Forget about Layer2 here. Your solution lays in L3.
-
You cannot assign your only IPv4 to a VM.
You have to use NAT. You can do NAT with the Linux-tools (iptables).
i cannot do NAT on ESxi .
Why?
If you cannot use NAT you'll have to buy a second IPv4 address and use a router-VM which handles NAT then.
In order to use IPv6 you have to install a neighbor discovery proxy on the ESXi machine to tell netcup's routers that this address is used on a machine.
-
Hallo Malte,
timeout gehört nicht zum POSIX-Standard. Da müsstest du über SSH einmal gucken, ob du timeout nutzen kannst.
Das PHP Executable findest du unter /usr/local/php[PHPVERION]/bin/php und gehört vermutlich nicht zur PATH-Variable.
Ich hoffe das hilft dir weiter.
-
Two possibilities:
1st: you have public IPv4 or IPv6 addresses for the VMs.
They need to be connected as point2point via the ESXi machine or you need to setup a route to the ESXi machine and set the default route via ESXi
2nd: you have private IP (RFC1918) addresses for the VMs.
You need to assign the ESXi as gateway. On the ESXi you need to set up a (S)NAT towards your public IP / public interface.
-
Ich denke aber nicht, dass das Sache der Registrar Service Provider ist sondern der Registries. Die Denic verlangt ja explizit die Jahresgebühr erneut.
-
Da bieten wir Systeme mit bis zu 1TB RAM
Angeber
-
was für mich feststeht, dass die DTAG deutlich an ihren Dokumentationen über "wann 'vergessen' wir deine SIP-Pakete" oder auch "welche Protokolle/Standards wir nicht wirklich kennen" arbeiten muss.
Es gibt eine Dokumentation. Nur macht die keinen Spaß: https://www.telekom.de/hilfe/g…reibungen-fuer-hersteller
angeblich eine umgelabelte Fritz!Box
ein gefritzer Speedport. Nix Neues und absolut klar, dass der zu nix zu gebrauchen ist.
-
soweit ich weiß liegt der Speicher als NFS
Du musst doch wissen ob du deine Datenbank auf den lokalen Festplatten (und mit welchem Dateisystem) gespeichert hast, oder ob die Datenbanken auf einem Netzwerkstorage liegen.
Im normalen Betrieb wird das von KVM glaube versteckt
Nein? Du hast eine Image-Datei im qcow2 Format, welches deiner Festplatte entspricht. Und die liegt auf dem gleichen Hostsystem wie auch deine VM / der Hypervisor. Alles andere ist nur gruselige Performance.
-
wie mache ich das denn?
touch /forcefsck -> reboot
nfs? Handelt es sich dabei um keine lokale Platte?
-
Hast du geguckt ob das FileSystem gesund ist und die inodes alle iO sind?
-
Stimmt nicht. T.38 wird mittlerweile unterstützt. Wobei man auch nie weiss, ob das "Empfängernetz" auch T.38 unterstützt, daher schalte ich T.38 immer aus.
Auch im Privatkundensektor und Netzübergreifend? Genau genommen müsste ein Provider ja zwischen T.38 und T.30 übersetzen können.
Die können ja auch Sprachcodecs umcodieren beim Wechsel aufs Mobilfunknetz.
Eigentlich macht man es ja auch so, dass man sich mit T.30 und 2 kHz Ton meldet; und dann einen T.38 reinvite schickt.
Ist halt die Frage, ob die Telekom den ReInvite ohne Manipulation zum anderen Teilnehmer durchgibt.
-
Ich hatte nur von ein paar wenigen Ausnahmen gelesen, wo die vorhandene und bezhalte Laufzeit angerechnet wurde
Die Ausnahmen beziehen sich auf generische Domains. Bei .de ging das bisher nur Anbieter intern (also UDAG / Dopoly intern z.B. - haben die aber auch eingestellt). Dass die Jahresgebühr erneut anfällt, sollte klar sein. Wobei er bei Inklusivdomains keine Jahresgebühr seitens Netcup zahlt.
-
Hallo,
ausgehende Transfers kosten nichts. Du musst lediglich nach dem AuthCode beim Support fragen und dann kannst du die Domain zu einem anderen Anbieter ziehen.
Wenn du dann eine andere Domain als Inklusivdomain nutzen willst, fällt eine kleine Bearbeitungsgebühr an.
-
Während wenn ich mit der Telekom über SIP reden muss... lasse ich es lieber.
DTAG verweigert ja sämtlichen Support für Endgeräte, die nicht durch die DTAG ausgeliefert werden.
Die haben ja schon zu Bundespostzeiten viel Mist mit ISDN gebaut - und setzten sie auch alle möglichen Vorteile von VoIP in den Sand.
Aber wenigstens ist Annex J das bessere Annex A (was man ja nirgens bekommen hat). Telefonieren tue ich eh mit anderen Anbietern.
Was ich besonders scharf finde: die senden keine KeepAlives (Option Pakete), dass muss schön das Endgerät machen.
In Verbindung mit den ReInvites einfach herrlich. Dazu kommt ja noch, dass die DTAG von unterschiedlichen IPs antwortet - welche genau ist Wetterabhängig und nicht öffentlich einsehbar. Die IP hinter tel.t-online.de antwortet jedenfalls nicht.
D.h. Firewallfreigaben zur PBX hin sind total nutzlos, ich kann ja schlecht das gesamte 217.0.0.0/8 er Netz freigeben.
Die DTAG hätte beim Rollout so viel richtig machen können: TLS auf Sprache und Signalisierung: Fehlanzeige - alles wird unverschlüsselt durchs Netz geprügelt
T.38: Fehlanzeige: nur T.30 über G711
Leitungssperrung bei Missbrauch: Fehlanzeige
Sipgate bekomme ich problemlos durch zwei NATs durch. Die machen es nämlich richtig; denen ist nämlich nicht egal was der Kunde da anschließt.
DTAG ist: friss oder stirb.
(aber man kann ja leider nicht immer einen großen Bogen um DTAG + SIP machen)
-
die Telekom uns da nochmal so viel Ärger macht
DTAG und SIP sind manchmal komisch. Da kann ich Stories erzählen...
-
Ich denke für absolute Anfänger die ja bereits zahlen (und keine lokale VM haben (wollen?)) ist der graphische Einstieg leichter.
Die Reaktion "aber das ist ja gar kein Windows" zeigt doch, dass er sich keine 5 Minuten damit beschäftigt hat und stumpf auf kaufen geklickt hat.
Als Anfänger braucht man aber deutlich mehr als 5 Minuten um z.B. solche Fragen zu klären:
- was will ich damit?
- welche Betriebssysteme stehen zur Verfügung
- wie bekomme ich Windows zum Laufen
- wie sichere ich das ganze ab
- wie bedient man eine Firewall für das gewählte Betriebssystem
- wie prüfe ich, dass meine Maßnahmen erfolgreich sind
- etc. pp.
Da hilft auch keine grafische Oberfläche. vServer, die im Netz hängen, haben nichts in den Händen von Anfängern zu suchen.
Deswegen: Fehlkauf, Leerkauf, Lehrkauf -> im Rahmen der Zufriedenheitsgarantie zurückgeben, Herunterfahren, Autostart deaktivieren.
Bei allem anderen wird nichts sinnvolles bei herum kommen. Weil nacher beschweren sich wieder alle: ähm Netcup hat mein Server gesperrt. Wie kann ich den wieder entsperren. Das ist ja ein doofes Unternehmen.
-
So wird dies wahrscheinlich nicht funktionieren, da in der Regel auf dem Server tel.t-online.de keine Verträge laufen, die für die nomadische Nutzung freigeschaltet sind. Auch ein freundliches anklopfen auf Port 5060 mittels telnet zeigt eher, dass Verbindungen außerhalb des DTAG Netz nicht gewünscht ist (drop).
tel.t-online.de ist außerhalb des DTAG Netzes nicht erreichbar (t-dialin / t-ipconnect).
Weiterhin wird tel-t-online.de unverschlüsselt über UDP angesprochen.
Du brauchst einen SIP-Trunk der öffentlich erreichbar ist. Z.B. sipgate (näheres gerne über PN)
Bei VPN brauchst du ein äußerst sauberes NAT, und da darf kein Speedport im Weg hängen.
Ist ja schön, dass du uns SIP erklärst...
