Twee onafhankelijke beslissingen gebeuren op hetzelfde pakket, en elk van beide kan het verzoek stil beëindigen. De routeopzoeking kiest een interface en een volgende hop, daarna bepaalt het pakketfilter of die combinatie is toegestaan. Een time-out vertelt u dat een van de twee weigerde, niet welke. Doorloop de fasen op volgorde en de reparatie is meestal geen gok meer.

Twee beslissingen, één pakket, twee eigenaren

De routeopzoeking raadpleegt eerst de policyregels, dan de tabel waarnaar ze wijzen, en kiest het meest specifieke prefix dat bij de bestemming past. Een client die een tunnelroute heeft geïnstalleerd, bezit die beslissing, en niets in een firewallregel kan die vervangen. Wanneer de opzoeking naar een onverwachte plek wijst, werkt elke latere fase op het verkeerde pakket.

Filtering staat apart. Op een Linux-host splitsen de netfilter-hooks verkeer op basis van voor wie het pakket is: output verlaat de machine, input eindigt erop, forward gaat erdoorheen. Een gateway die VPN-clients accepteert en naar een LAN routeert, heeft het forward-pad nodig, en dat is precies de keten die de meeste standaardconfiguraties leeg laten.

Bronselectie hoort bij dezelfde beslissing, en daar schuilen de meeste afwijkingen. De kernel kiest een bronadres van de uitgaande interface tenzij de route er een noemt, dus een filterregel voor het LAN-subnet komt nooit overeen met een pakket dat met het tunneladres naar buiten gaat.

Lees wat de opzoeking werkelijk koos

Druk de beslissing af in plaats van ze af te leiden. Het onderstaande commando lost de route op die de kernel voor die bestemming zou gebruiken, inclusief de interface en de bron die hij zou kiezen:

ip route get 10.8.0.5
ip route get 10.8.0.5 from 192.0.2.44
ip rule show
ip route show table all | sed -n '1,40p'

VPN-clients installeren vaak policyregels op prioriteiten onder de hoofdtabel, dus een schone hoofdtabel bewijst op zichzelf niets. Vergelijk de regelprioriteiten met de tabellen die ze selecteren, en controleer of de tunnelroute een herverbinding overleeft in plaats van één keer handmatig te worden toegevoegd.

Policygebaseerde IPsec voegt een derde overeenkomstfase toe die routing niet dekt, zoals strongSwans forwardnotities beschrijven voor tunnel- en transportopstellingen. Het beveiligingsbeleid selecteert verkeer op prefix en protocol, terwijl de route alleen bepaalt waar een onbeschermd pakket heen zou gaan. Een subnet dat wordt gerouteerd maar geen passende selector heeft, blijft ofwel onbeschermd of wordt weggegooid, afhankelijk van de configuratie, en geen van beide uitkomsten ziet eruit als een firewallprobleem. Druk het beleid af en vergelijk de selectors met de prefixen waarvan u verwachtte dat de tunnel ze zou dragen.

Filtering geldt bij een hook, niet bij een route

Een regel die de VPN-listener toestaat, is een regel over verkeer dat aan de gateway zelf is geadresseerd. Ze zegt niets over clients die hosts achter die gateway bereiken, omdat doorgestuurd verkeer een andere keten doorloopt. De regelset als één platte lijst lezen is de gebruikelijke reden waarom een correct uitziende regel nooit afgaat.

Tellers beslechten de vraag snel. Een regel met een pakketteller van nul werd nooit bereikt, wat wijst op de verkeerde keten, de verkeerde interface of een eerdere drop. Een regel met een groeiende teller onder een dropbeleid is de grens die u zocht, en het pakket wordt weggegooid in plaats van verkeerd gerouteerd.

Stuur een probe via het pad dat de client gebruikt

Tests die op de gateway zelf draaien, gaan via output en input, met het eigen bronadres van de gateway. Dat is een ander pad dan het doorgestuurde verzoek van een client, dus een geslaagde lokale curl bewijst minder dan het lijkt. Test vanaf de machine die faalt, of pin de interface en de bron expliciet vast.

nc -vz -w 3 10.8.0.5 443
ping -c 3 -W 1 10.8.0.5
tcpdump -ni any host 10.8.0.5 and port 443
iptables -vnL FORWARD --line-numbers
nft list ruleset | sed -n '1,60p'

Een capture aan beide uiteinden scheidt de resterende gevallen. Een SYN die de client verlaat en nooit aankomt, betekent routing, versleuteling of een toegangslijst stroomopwaarts. Een SYN die aankomt en geen antwoord krijgt, betekent de dienst of zijn hostfilter, en de tunnel was nooit het probleem.

Retourverkeer verdient een eigen blik. Asymmetrische routing plus reverse-path filtering gooit antwoorden weg die op de verkeerde interface aankomen, wat zich toont als een eenrichtingsverbinding in plaats van een geblokkeerde poort. Controleer de sysctl-waarde voordat u de firewall de schuld geeft van een symptoom dat hij niet veroorzaakte.

Logging werkt als tweede mening, niet als eerste stap. Een tijdelijke logregel op de forward-keten noemt de interface en de adressen die hem raakten, en is achteraf makkelijk te verwijderen. Laat hem permanent staan en u hebt een logvolume probleem gebouwd in plaats van een antwoord.

Plaats elke wijziging waar ze een herverbinding overleeft

Een route die met ip route add is toegevoegd, leeft tot de interface down gaat. Bewaar haar in het verbindingsprofiel: NetworkManager accepteert extra routes op de verbinding, en netplan houdt ze over herstarts heen. Dezelfde regel geldt voor een firewalluitzondering aan clientzijde, die na de volgende herlaadbeurt weg is.

Regels aan serverzijde horen in het configuratiebestand dat de dienst bij het starten laadt, niet in een interactieve sessie die eindigt wanneer u ze sluit. Schrijf de regel, herlaad en bevestig dat de teller bewoog, want een herlaadbeurt die de syntaxis verwierp, laat de oude regelset stilzwijgend staan.

Herhaal daarna het oorspronkelijke applicatieverzoek van begin tot eind en noteer welke laag veranderde. Een routereparatie die ook een filterwijziging nodig had, zal alsnog mislukken, en de tweede fout leest veel makkelijker zodra u weet dat de eerste weg is. Noteer de datum en de clientversie naast het resultaat, want standaardwaarden voor routing en filtering bewegen beide tussen releases. Houd die notitie op het ticket zodat de volgende persoon begint waar u stopte in plaats van de tweestapsronde te herhalen.

Gerelateerde artikelen