Der Client ist authentifiziert und die UDP-Assoziation ist erlaubt. Antworten schlagen dennoch fehl. Prüfen Sie in Dante die Richtung der Regel, die den Rückverkehr verarbeitet.

Dante trennt einleitende Befehle von der Antwortverarbeitung:

Regelbefehlefromto
connect, bind, udpassociateInterner ClientExternes Ziel
bindreply, udpreplyExterner HostInterner Client

Eine unverändert in beide Richtungen kopierte Subnetzbeschränkung des Clients kann daher in der Antwortregel die falsche Seite treffen. Prüfen Sie die vorgesehenen externen Absender und internen Empfänger, nicht nur, ob das Wort UDP in einer Durchlassregel auftaucht.

Die Authentifizierung hat eine verwandte Grenze. Der externe Dienst, der auf ein UDP-Datagramm antwortet, ist kein SOCKS-Client, der Ihren Austausch von Benutzername und Passwort abschließen kann. Die Dante-Dokumentation erklärt, dass Antwortoperationen aus einer früheren BIND- oder UDP-Assoziation des Clients entstehen; authentifizieren Sie diese einleitende Operation und wenden Sie die passende Richtlinie für zugehörige Antworten an.

Das rechtfertigt keinen uneingeschränkten unverlangten eingehenden Verkehr. Die UDP-Assoziation, die Zielrichtlinie, die Relay-Adresse und der Firewall-Pfad bleiben wichtig. Auch das Aktivieren von bindreply macht aus der UDP-Assoziation keinen allgemeinen öffentlichen Portweiterleitungsdienst.

Halten Sie den SOCKS-Austausch auf Clientseite und den tatsächlichen UDP-Rückweg getrennt sichtbar. Ein erfolgreicher TCP-Login bestätigt weder die Adressrichtung der Antwort-ACL noch die Erreichbarkeit des UDP-Relay-Endpunkts.

Ähnliche Artikel