UDP/TCP hole punching (Router Firewall legal löchern)

[DarkDragon]

Frag ma nach...dann guck ich mri auch den Stream an

Kann ich nicht, ich bin nicht dort.

[Joel]

Hach schade...ok, jetzt aber zurück zum Thema, wie geht TCP hole punching?

Wenn jemand auch Interesse an der technik hat, dann bitte mir eine PN schreiben, dann können wir das mal probieren. Brauche nur eine 2. PC, der nicht hinter mienem NAT ist...

[Joel]

Ich habe das jetzt mal probiert, erstmal mit UDP. Aber leider klappt das nicht. Ich habe 2 PCs hinter nem Router gehabt und beide Router unterstützen UDP hole punching, aber der Code schafft es nicht. Positive Connections bestimme ich durch ein Empfangenes Teststring.

Server:

Code: Alles auswählen

If InitNetwork() = 0
  MessageRequester("Error", "Can't initialize the network !", 0)
  End
EndIf

  Procedure Conn(l.l)
Shared ConnectionID
ConnectionID = OpenNetworkConnection("0.0.0.0", 9000, #PB_Network_UDP)
SendNetworkString(ConnectionID, "aaa")
EndProcedure 

*Buffer = AllocateMemory(1000)

If CreateNetworkServer(0, 9000, #PB_Network_UDP)
  
  Repeat
  


Conn_Thread = CreateThread(@Conn(), 77)
Delay(50)
  
      
    SEvent = NetworkServerEvent()
  
    If SEvent
    
      ClientID = EventClient()
  
      Select SEvent
      
        Case 1
          MessageRequester("PureBasic - Server", "A new client has connected !", 0)
  
        Case 2
          MessageRequester("PureBasic - Server", "Client "+Str(ClientID)+" has send a packet !", 0)
          ReceiveNetworkData(ClientID, *Buffer, 1000)
          MessageRequester("Info", "String: "+PeekS(*Buffer), 0)
    
      EndSelect
    EndIf
    
  Until Quit = 1 
  
  MessageRequester("PureBasic - Server", "Click to quit the server.", 0)
  
  CloseNetworkServer(0)
Else
  MessageRequester("Error", "Can't create the server (port in use ?).", 0)
EndIf

  
End   

Client:

Code: Alles auswählen

If InitNetwork() = 0
  MessageRequester("Error", "Can't initialize the network !", 0)
  End
EndIf

Procedure Conn(l.l)
ConnectionID = OpenNetworkConnection("0.0.0.0", 9000, #PB_Network_UDP)
Debug ConnectionID
SendNetworkString(ConnectionID, "testa")
EndProcedure 

Repeat
Conn_Thread = CreateThread(@Conn(), 77)
Delay(1000)
ForEver 

Der Code ist normal verständlich. Die Prozesse Bombadieren sich mit Verbindungsversuchen und der Cleint sendet immer dateien, die beim Server aber nicht ankommen. Es muss an meinem Code liegen, da beide Router UDP udn TCP punching unterstützen und eien normale TCP Verbindung mit Portforwarding auch klappt.[/quote]

[Joel]

Gibts schon neue Ansätze für TCP- oder UDP hole punching?

[Joel]

Also heißt das jetzt, das UDP/TCP Hole Punching nicht mit PB möglich ist?

[DarkDragon]

Also heißt das jetzt, das UDP/TCP Hole Punching nicht mit PB möglich ist?

Du musst etwas auf dem Port 9000 senden, damit die NAT Box wieder zum Port 9000 zurücksendet. Das geht ohne API nicht (SOCK_RAW -> UDP Header selbst hinzufügen).

>> OpenNetworkConnection("0.0.0.0", 9000, #PB_Network_UDP)

Der Port auf dieser Seite ist damit nicht 9000 sondern liegt wohl irgendwo jenseits der 50000.

[Joel]

Achso, udn wie mach ich das mit der API bzw. Wie bekomme ich so einen Header usw...

[DarkDragon]

Achso, udn wie mach ich das mit der API bzw. Wie bekomme ich so einen Header usw...

Schau mal mein Beispiel hier, wie man es ohne API macht, aber mit einem Introducer, der die Port-Schätzung übernimmt.

Mit API könnte man den Port für einige wenige NAT-Boxen festlegen, dann kann man den u.U. besser "erraten" ohne Introducer.

[Joel]

Wieso erraten?

Wie meinst du das jetzt genau?

Versteh ich da jetzt was falsch?

Also ich habe gedacht: Ich habe gedacht ich mach auf PC1 einen Port z.B. 7000 und PC2 bombadiert den mit anfragen auf Port 7000. Dann stellt PC1 einen Verbindung zu PC2 auf Port 7000 her.....Dadurch kann PC2 nun wieder durch die Firewall von PC1 durch....

[DarkDragon]

Wieso erraten?

Wie meinst du das jetzt genau?

Versteh ich da jetzt was falsch?

Also ich habe gedacht: Ich habe gedacht ich mach auf PC1 einen Port z.B. 7000 und PC2 bombadiert den mit anfragen auf Port 7000. Dann stellt PC1 einen Verbindung zu PC2 auf Port 7000 her.....Dadurch kann PC2 nun wieder durch die Firewall von PC1 durch....

Im Prinzip ist das auch richtig (Nur das bombadieren stimmt nicht). Doch leider kann man dabei nur systematisch raten, welcher Port jetzt außen, also nach der NAT Box das Paket hat, außer man hat einen Introducer, der einem genau das sagt. Mit API gibt es da noch eine Möglichkeit den Port Clientseitig einigermaßen festzuhalten, aber da muss die NAT-Box auch mitspielen, ansonsten wird wieder systematisch geraten.