Op mijn thuis server draai ik een Gitea server op poort 2222 en deze wordt correct geforward naar het internet.
Vanaf buiten kan ik prima verbinding maken met deze server.
Alleen als ik vanaf mijn interne netwerk op deze poort verbind duurt het sms tot wel 2 minuten voordat een git pull/push en doorheen komt. Voorheen, op mijn Ziggo modem, had ik dit probleem totaal niet.
Met andere services als ssh (22), http (80) of https (443) werkt alles naar behoren en kan ik direct verbinding maken.
Iemand een idee of ik een extra setting moet aanpassen op de FRITZ!Box 7590 ?
Ik kon hier verder niks over vinden.
Vaag, verbindt je intern-client naar buiten om via die FB poort weer naar binnen bij de server te komen ?
Of het is rechtstreeks client direct server doelpoort, waarbij de FB dan geen rol speelt.
Indien je via de FB-portforwarding werkt, kan je proberen met packet-tracing op de FB de (delay ?)oorzaak te achterhalen. Mogelijk staat er iets 10x in een loop te draaien voordat het bij de client/server komt.
Ik heb het idee dat het misschien iets met DNS resolves te maken heeft, kan dat?
In m’n browser zijn deze requests waarschijnlijk gecached dus gaat het snel, maar als ik bijv. op de CLI met Lynx verbind duurt het evengoed rete lang voordat er iets door komt (op http/s dus).
Ik verbind op m’n externe domein naam, omdat ik dat default op m’n repositories mee krijg. Als ik dit vervang met de hostname van die pc gaat het uiteraard wel snel. Maar dan zou ik continue al m’n git configs moeten aanpassen elke keer dat ik buiten/binnen mijn netwerk ben. Dat is natuurlijk niet te doen.
Wat bedoel je met “proberen met packet-tracing”? Welk command kan ik hier voor gebruiken?
Ps ik zei eerder dat SSH wel werkte, maar ik loog. Als ik van binnen het netwerk op mijn externe domein wil verbinden duurt het evengoed 1-2 minuten voordat er iets gebeurd.
Ok met ssh <mijn_domein> -vvv zie ik wat er gebeurd:
Eerst wil deze verbinden op ipv6 … wanneer dit een timeout krijgt probeert deze ipv4 en dit slaagt vervolgens meteen.
Er lijkt dus iets mis te zijn met de ipv6 port-forward configuratie …
DNS resolving lijkt mij niet aan de orde of oorzaak.
Packet tracing van de FritzBox wier output je dan met Wireshark kan bekijken.
Zie http://fritz.box/support.lua → packet-tracing waar)na) je dan trace kunt starten op de verschillende interfaces.
In jouw geval zou je die packet-trace ook kunnen doen op je client/pc die de issues heeft. Uit de trace is mogelijk af te leiden wat er waar zo lang/veel tijd neemt.
Inzake IPv6, zou ik dat gewoon of even helemaal uitzetten… dat - iig bij mij, in mijn ervaring - mogelijk in de verdwalende weg kan zitten.
Voor IPv6 moet je ook port sharing instellen in de fritzbox. heb je dit ook gedaan?
En in theorie zou je via IPv6 rechtstreeks moeten verbinden met het interne systeem. Of heeft de host het verkeerde IPv6 adres in DNS staan?
En moet ik dus in de domein instellingen het volledige ip address van de interface van waar naartoe geforward toe zetten (en dus niet alleen het address van de gateway die de port forward)?
Sorry ik ben erg ipv6 noob, tis tot nog toe niet echt nodig geweest he
Inderdaad IPv6 kent geen port forwarding.
Je benadert een apparaat rechtstreeks op zijn IPv6 adres. Je moet de router / firewall alleen vertellen op welke poorten een apparaat met zijn IPv6 adres van buitenaf benadert mag worden.
Dat is dus geen forward maar een toestemming op een poort.
