Ich habe ein ziemlich merkwürdiges Problem mit PHP-Remote-Debugging im LAN: Ein Ubuntu-Server läuft unter qemu/kvm und hostet die PHP-Seite, die ich testen will. Der Server ist per Browser vom Host aus erreichbar. (ssh funktioniert auch problemlos.) XDebug scheint auf dem Server korrekt installiert zu sein: wenn ich XDebug auf Localhost leite und im Ubuntu-Server das Testprogramm debugclient (von PHP) starte, bekomme ich dort die erwartete Reaktion von XDebug, wenn ich auf dem Host die PHP-Seite aufrufe. Setze ich als remote_client die Host-IP-Adresse ein und starte debugclient vom Host aus, kommt nichts, wenn ich auf dem Host die PHP-Seite aufrufe. Netbeans 11 bekommt auch keine Verbindung zum Debugger, wobei Wireshark auf Host und Server nur Pakete anzeigt, die von XDebug an den Host geschickt werden; in umgekehrter Richtung sehe ich keinerlei Traffic. Debug-Port ist Port 9000 – das ist auf beiden Seiten eingestellt. Gibt es eine einfache Möglichkeit, den Verkehr zwischen Host und Server über einen bestimmten Port zu testen?
Erster Fehler aus meiner Sicht: PHP Ansonsten: - firewall - netstat - tcpdump als Anfang.
Voodoo schrieb: > - tcpdump Das kann Wireshark auch… Ich suche was, womit ich über <ip>:<port> eine (Text-)Verbindung aufbauen kann, um dann die verschiedenen Fehlermöglichkeiten zu untersuchen.
Netcat/nc mag ich für sowas auch gerne. Mit -l kann es auch auf eingehende Verbindungen warten.
Eigentlich kann jedes Programm genutzt werden das eine Client-Server Architektur hat. Netcat oder nc ist natürlich auch ein Klassiker oder Socat Auch hilfreich kann ein Portscan mit Nmap sein.
Uhu U. schrieb: > Ein Ubuntu-Server läuft unter qemu/kvm und hostet die PHP-Seite, die ich > testen will. Der Server ist per Browser vom Host aus erreichbar. (ssh > funktioniert auch problemlos.) Läuft der Guest im bright mode oder bekommt er das Netzwerk per NAT? wenn NAT ist dann das Port forwarding für die Debug Ports aktiviert, und beim Host als Target localhost im XDEBUG eingetragen?
imonbln schrieb: > Läuft der Guest im bright mode oder bekommt er das Netzwerk per NAT? Letzteres. > wenn NAT ist dann das Port forwarding für die Debug Ports aktiviert, und > beim Host als Target localhost im XDEBUG eingetragen? Nein. Kannst du einen Tipp geben, wo das genauer beschrieben ist?
Uhu U. schrieb: > Kannst du einen Tipp geben, wo das genauer beschrieben ist? Klar z.b hier https://www.linux-kvm.org/page/Networking vermutlich musst du denn teil für dich adaptieren. > You can still access one specific port on the guest using the "hostfwd" > option. This means e.g. if you want to transport a file with scp from host > to guest, start the guest with "-device e1000,netdev=user.0 -netdev > user,id=user.0,hostfwd=tcp::5555-:22". Now you are forwarding the host > port 5555 to the guest port 22. After starting up the guest, you can > transport a file with e.g. "scp -P 5555 file.txt root@localhost:/tmp" from > host to guest. Or you can also use the other address of the host to > connect to.
Angehängte Dateien:
-
Wireshark.png
72 KB
imonbln schrieb: > und beim Host als Target localhost im XDEBUG eingetragen? Ich benutze auf dem Host Netbeans 11. Dort wird lediglich der Debug-Port 9000 eingetragen. XDebug läuft nur auf dem Gastsystem (Server) Im Server ist als xdebug.remote_host die IP-Adresse des Hostsystems 192.168.178.101 eingetragen. Anhang: Wireshark läuft auf dem Hostsystem (.178.101), tshark auf dem Server (.179.230). Wie man sieht, schickt XDebug 2 Frames an den Host. Von dort kommt nichts, obwohl auf Port 9000 Netbeans lauscht. Der Server hat als "Network source" Virtual network 'host': NAT eingestellt. Wenn ich auf dem Server nc -l 9000 laufen lasse, kann ich vom Host aus mit nc 192.168.179.230 9000 eine bidirektionale Verbindung aufbauen. Umgekehrt mit nc -l 9000 auf dem Host und nc 192.168.178.101 9000 auf dem Server geht nichts: nc terminiert sofort ohne irgend eine Meldung. Interessant: Der Aufruf auf dem Server (Portscan mit nc) nc -zv 192.168.178.101 9000 bringt eine Meldung:
1 | nc: connect to 192.168.178.101 port 9000 (tcp) failed: No route to host |
Ein
ping 192.168.178.101
vom Server aus funktioniert.
Was ist der Übeltäter?
:
Bearbeitet durch User
Der Übeltäter war die Firewall auf dem Hostsystem: Nach Freigabe des Port 9000 für tcp funktioniert es.
Uhu U. schrieb: > Der Übeltäter war die Firewall auf dem Hostsystem: > Nach Freigabe des Port 9000 für tcp funktioniert es. Gut wenn es jetzt geht, ansonsten finde ich "sudo lsof -i -n" hilfreich... Die Firewall kann man mit -j LOG garnieren. "dmesg -wHT" bringt dann geblockte Inhalte.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.