Via specifieke switch is een externe url niet te bereiken

[dazzel]

Hoi,

Ik ben al enkele dagen bezig met een netwerk issue waar ik niet uitkom, meestal door veel zoekwerk, oa op dit geweldige forum, kom ik er meestal wel tot een oplossing maar nu heb geen idee waar ik het moet zoeken. Ik weet niet of dit nu een netwerk issue is of een linux issue, op allebei de onderwerpen is mijn kennis beperkt.

Mijn setup:

Nokia Modem (XS-2426G-B) Delta Glasvezel
En deze verbindt door naar twee switches Netgear GS108PEv3 (laatste firmware en standaard configuratie), allebei apart op de nokia modem aangesloten.

Op één van de switches draait een een linux machine, daar draaien diverse dockercontainers op inclusief 'Nginx Proxy Manager'. Ik heb twee poorten op de nokia geforward naar deze machine (80 en 443) welke op basis van de url door proxy manager naar de juiste dockercontainer doorstuurt. Dit werkt allemaal prima vanaf buiten.

Echter op de switch waarop de linuxmachine is aangesloten gebeurt iets vreemd. Als ik nu op deze machine één van mijn websites probeer te benaderen zie ik het volgende in de log van de proxy manager:

- 301 - GET http xx.domein.info "/" [Client 62.xx.xxx.100] [Length 166] [Gzip -] [Sent-to 192.168.1.94]
- 302 302 - GET https xx.domein.info "/" [Client 62.xx.xxx.100] [Length 138] [Gzip -] [Sent-to 192.168.1.94]

..en dan blijft het stil. De browser blijft draaien en toont een leeg scherm. Dit gebeurt ook als ik deze website benader vanaf het het wifi punt dat is aangesloten op dezelfde switch. Als ik op deze linuxmachine het interne ip-adres gebruikt met het juiste poortnummer dan kom ik wel bij de website.

Als ik nu dezelfde url aanroept via ween wifi punt die op de andere switch is aangesloten, krijg ik wel response:

- 200 200 - GET https xx.domein.info "/welcome/" [Client 62.xx.xxx.100] [Length 2152] [Gzip -] [Sent-to 192.168.1.94]

Als ik nu de switch waarop ik het issue heb niet op de Nokia modem aansluit maar op de switch waarop nu alles nog werkt, dan heb ik het exacte hetzelfde probleem op allebei de switches.

Wat gaat hier mis?

[k-janssen]

Ook ik zie niet helemaal waar het fout gaat maar ik denk dat je het beste aan de client zijde kan gaan kijken wat er gebeurt. zoals ik het nu zie gaat er mogelijk ergens iets mis met een hairpin NAT of in DNS.

Ook kan je eens kijken of er ergens iets niet helemaal goed gaat met de redirects. Mogelijk is daar iets gebeurd waardoor dat niet helemaal lekker loopt.

Ik zie op dit moment eerder een aanleiding om daar de fout te zoeken dan in de switch.

[ Voor 37% gewijzigd door k-janssen op 17-03-2024 10:28 . Reden: redirect toevoeging ]

[Will_M]

Een switch werkt alleen op laag 2 van het OSI model dus het is zeer onwaarschijnlijk dat dat apparaat voorkomt dat je een specifiek URL niet kan benaderen omdat je dan al op laag 3 van het OSI model aan het 'rommelen' bent.

Kijk eens wat een pathping naar het IP van de betreffende website voor een resultaat geeft.

[ Voor 13% gewijzigd door Will_M op 17-03-2024 10:38 ]

[dazzel]

Ik werd door de term hairpin NAT getriggerd en ben eens op zoek gegaan. Ik kwam o.a. terecht op een post op de site van de serverfault. Het plaatjes wat door wordt getoond en de beschrijving van een post daaronder is volgens mij het probleem.

Snap alleen even niet hoe ik de probleem kan oplossen in mijn huidige configuratie, worden diverse suggesties gegeven maar mijn kennis is niet toereikend om dit te doorgronden. Kan wel wat dingen uitvoeren maar ik snap graag wat ik aan het doen ben voordat ik bijvoorbeeld iptables ga aanpassen als dit het probleem oplost.

Maar kwam met een redelijk simpel alternatief op basis de geschetste situatie. Ik had nog een Raspberry PI aan een switch gekoppeld en deze heb ik direct op de modem gekoppeld en daarop de nginx proxy manager gezet. Nu werkt het wel aangezien het doorverwijzen niet op dezelfde machine of switch gebeurt. Het is misschien niet de ultieme oplossing, want waarom zou het niet gewoon op de oude manier werken, maar het is werkbare oplossing.

[dion_b]

Eerste om te beseffen is dat hairpin NAT betrekkelijk ingewikkeld is en het allerminst een sinecure is dat het bij een willkeurige router gaat werken. Dat is gelijk ook eerste vraag over je setup: je hebt het over "modem" (blij glas is er helemaal geen spraken van moduleren en demoduleren, dus ik ga ervan uit dat je ONT bedoelt), maar dat is een layer 2 apparaat. Ergens heb je ook een router die layer 3 dingen doet waaronder NAT. Wil je hairpinnen. dan moet dat daar ondersteund en (voorzover van toepasseing) correct ingesteld zijn.

Veel eleganter is natuurlijk om verkeer voor lokale hosts ook lokaal af te handelen. Getuige je voorbeeld gebruik je DNS, dan zou ik dit op niveau van DNS afhandelen: in je DNS config (als je zelf een server draait) deze hosts toevoegen op basis van lokaal IP, of anders in de HOSTS file van je clients. Dan kun je URL gebruiken zoals je gewend bent, maar blijft lokaal verkeer gewoon lokaal zonder vreemde toeren op je router.

[RobIII]

Will_M schreef op zondag 17 maart 2024 @ 10:36:
Een switch werkt alleen op laag 2 van het OSI model dus het is zeer onwaarschijnlijk dat dat apparaat voorkomt dat je een specifiek URL niet kan benaderen omdat je dan al op laag 3 van het OSI model aan het 'rommelen' bent.

offtopic:
Er zijn wel degelijk Layer 3 switches

[Ben(V)]

Nee dan is het een switch met router functionaliteit die onterecht layer 3 switch genoemd wordt.
Een switch is enkel layer 2

[Kabouterplop01]

- 301 - GET http xx.domein.info "/" [Client 62.xx.xxx.100] [Length 166] [Gzip -] [Sent-to 192.168.1.94]
- 302 302 - GET https xx.domein.info "/" [Client 62.xx.xxx.100] [Length 138] [Gzip -] [Sent-to 192.168.1.94]


Als ik nu dezelfde url aanroept via ween wifi punt die op de andere switch is aangesloten, krijg ik wel response:

- 200 200 - GET https xx.domein.info "/welcome/" [Client 62.xx.xxx.100] [Length 2152] [Gzip -] [Sent-to 192.168.1.94]

het zijn 2 verschillende requests: De 1e is een http request die wordt geredirect naar https
de 2e request lijkt onmiddelijk naar https://xx.domein.info/welcome te gaan en krijgt 200 OK.


probeer dat ook eens via de 1e situatie.
en andersom probeer eens op de 2e situatie http://xx.domein.info en zie je dan hetzelfde beeld? (maar dan omgekeerd)

want je krijgt reactie van de server terug

[laurens0619]

Zover ik weet kan die XS-2426G-B van delta helemaal geen hairpin nat dus ik
Zou verwachten dat het uberhaupt niet zou moeten werken?

[nicodier]

Wellicht dat de laag 2 MTU niet hetzelfde is over je hele netwerk?

Om er echt achter te komen wat er gebeurd, kan je het beste aan beide kanten een wireshark/tcpdump laten lopen terwijl je test.

[ChaserBoZ_]

nicodier schreef op dinsdag 19 maart 2024 @ 20:22:
Wellicht dat de laag 2 MTU niet hetzelfde is over je hele netwerk?

Om er echt achter te komen wat er gebeurd, kan je het beste aan beide kanten een wireshark/tcpdump laten lopen terwijl je test.

Bij dit soort vage problemen denk ik ook vaak aan MTU. Sluit dat in ieder geval uit, met bijvoorbeeld https://tecnobits.com/nl/...de-moet-worden-ingesteld/