Het antwoord verlaat het LAN, niet de tunnel: waarom en hoe

Een dienst die via een gateway is gepubliceerd, werkt vanaf het grootste deel van het internet en faalt vanuit één kantoor. Iemand onderzoekt de tunnel, ziet het verzoek aankomen en concludeert dat het antwoord dezelfde weg terug moet volgen. Linux werkt niet zo, en geen enkele inspectie van de tunnel verandert het antwoord. Het antwoord wordt op bestemming gerouteerd, en die ene falende beller zit op een subnet dat de host al rechtstreeks bereikt.

Wat een uitgaand pakket feitelijk bepaalt

De kernel zoekt een route voor de bestemming van het pakket, raadpleegt beleidsregels in prioriteitsvolgorde en daarna de tabel die een overeenkomende regel selecteert. De interface waarop een pakket binnenkwam speelt geen rol, tenzij een regel of markering is geschreven om dat relevant te maken. Dat is een routingfeit over deze host, geen fout in de tunnel.

Een verzoek dat via de tunnel wordt ontvangen, kan dus een antwoord opleveren dat via de fysieke interface naar buiten gaat, en de stroom wordt eenrichtingsverkeer zonder dat enig apparaat een fout meldt. Controleer beide richtingen voordat je een conclusie over de tunnel trekt. Een antwoord dat de verkeerde kant op gaat, verdwijnt uit de tunneltellers, en daarom zijn de twee uiteinden het oneens over de vraag of er iets is verzonden. Let op welke teller bewoog voordat je een regel aanraakt.

Waarom het lokale subnet wint

Een host met een adres op een lokaal netwerk heeft een verbonden route voor dat prefix in de hoofdtabel, en een verbonden route is een directe overeenkomst. Wanneer de beller uit hetzelfde subnet komt, vindt de opzoeking de lokale verbinding voordat de tunnel überhaupt wordt overwogen.

Het is de asymmetrie die dit verwarrend maakt om te diagnosticeren. Bellers van het bredere internet werken omdat ze op geen enkele lokale route passen, terwijl de ene beller die het kantoorprefix deelt faalt, en dat is precies de beller waarmee iemand test.

Peer-dekking is niet hetzelfde als geïnstalleerde routes

Aan de tunnelkant beschrijven de toegestane bereiken van een peer wat er in de tunnel mag worden gestuurd en welke bronnen daaruit worden geaccepteerd. Ze zeggen niets over waar de lokale routingtabel een pakket naartoe stuurt.

Als de tunnelgereedschap een standaardroute op de host installeert, kan het ongerelateerd verkeer als bijkomende schade de tunnel in slepen. Waar een beleidsregel de beslissing zou moeten hebben, bestaat de optie voor route-installatie juist om dat te voorkomen, en de adressen, sleutels en eindpuntinstellingen blijven precies zoals ze waren. Een standaardroute die voor het gemak is toegevoegd, is een veelvoorkomende manier waarop een host zijn eigen lokale netwerk verliest.

Kies de tabel op basis van het bronadres

Een brongebaseerde regel stuurt antwoorden van het dienstadres naar een privétabel waarvan de standaard de tunnel is, terwijl al het andere de hoofdtabel blijft gebruiken. Kies tabel- en prioriteitsnummers die lokaal niet worden gebruikt, en lees de bestaande regels voordat je iets invoegt. Lees de actieve regels in plaats van een opgeslagen bestand, want die twee kunnen na een herstart verschillen.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

De laatste regel laat een ontbrekende route zichtbaar falen in plaats van terug te vallen op de lokale verbinding. De bron moet echt aan de host zijn toegewezen, en de gewone lokale en hoofdopzoekingen moeten op hun eerdere posities blijven. De regel kiest een tabel op bron; hij vergelijkt geen prefixlengtes tussen tabellen.

Bevestig het pad en dan de dienst

Vraag de kernel wat hij zou doen in plaats van uit een capture af te leiden, met het dienstadres als bronkiezer. Een juist antwoord hier bespaart een volledige pakketrace.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

De uitvoer zou de tunnel moeten noemen. Test dan een bron die je niet hebt aangeraakt en bevestig dat die nog steeds de lokale verbinding neemt, zodat de wijziging beperkt bleef tot één adres. Een bredere kiezer zou niets bewijzen over de oorspronkelijke klacht.

Wat dit niet oplost

Laat doorsturen, firewallregels en ICMPv6-gedrag op de gateway zoals ze waren, want een bronroute vervangt geen van die. Een ontbrekend Packet Too Big-bericht breekt nog steeds grote antwoorden, welke tabel de opzoeking ook won. Repareer dat voordat je routingregels toevoegt, anders overleeft het symptoom de wijziging.

Bevestig het publicatiemodel voordat je iets hiervan toepast. Een omgekeerde proxy die zijn eigen backendverbinding opent, presenteert zijn eigen bron en bewaart de beller niet, dus deze fout kan zich in dat ontwerp niet voordoen. De regel daar toepassen zou een routinguitzondering toevoegen die niets oplost en de echte oorzaak verbergt.

Schrijf ten slotte de regelnummers en de tabel in het configuratiebeheer van de host. Een beleidsregel die met de hand is toegevoegd, verdwijnt bij de volgende herbouw, en de kantoorbeller komt terug met dezelfde klacht.