IPsec met meerdere subnetten verliest retourverkeer? Tel de reqids

Verkeer verlaat de ene locatie en komt nooit terug, beide gateways melden een afgeronde onderhandeling, en de enige aanwijzing is een stapel uitgaande pakketten zonder antwoorden. Op een Linux-endpoint is de gebruikelijke oorzaak niet de versleutelingssterkte, de MTU of een routetabel. Het is de granulariteit van de policy-items en het nummer dat elke policy aan een beveiligingsassociatie koppelt. De onderstaande procedure leest die twee databases voordat iets anders wordt aangeraakt.

Splits het symptoom voordat u iets wijzigt

Een eenrichtingsfout bij een afgeronde IKE-onderhandeling beperkt het probleem tot het datapad. Ofwel de uitgaande policy matchte en het antwoord werd weggegooid, ofwel het antwoord kwam nooit aan omdat de andere kant niets had om het door te sturen. Vanuit een applicatie zien beide er hetzelfde uit, en de xfrm-databases onderscheiden ze.

Begin niet met de MTU. Een verkeerde MTU levert haperingen en fragmentatiesymptomen op, geen schone richtingssplitsing met stijgende uitgaande tellers.

Lees de policy-database en de state-database

Versleuteling op Linux wordt door policy-items bepaald, dus een passende policy, niet een route, brengt een pakket in de tunnel. Voer ip xfrm policy uit om de selectors, richting, prioriteit en template van elk item te zien, en ip xfrm state om de opgebouwde associaties met hun reqids te zien. De policy en de associatie worden door die reqid verbonden.

Kijk naar alle drie de richtingen. Uitgaand en inkomend dekken verkeer van en naar deze host; de forward-richting is van belang wanneer de host voor anderen routeert. Een ontbrekend of afwijkend item in één richting verklaart een eenrichtingsresultaat zonder enige cryptografische fout.

De klassieke asymmetrie: één reqid voor meerdere subnetten

Een veelvoorkomende fout komt van een peer die policies voor alle onderhandelde subnetten onder één reqid installeert, wat gebeurt met racoons generate_policy require. Het verkeer vertrekt dan via de associatie die het laatst is opgebouwd, terwijl de andere kant per subnet een aparte associatie houdt. Antwoorden komen aan op een associatie waarvan de reqid niet de policy aanwijst die ze zou moeten accepteren, en de kernel gooit ze na ontsleuteling weg.

De oplossing is een configuratiewijziging, geen firewallregel: generate_policy unique; geeft elke policy zijn eigen reqid, zodat de associaties per policy van de peer passende partners hebben. Pas het toe, onderhandel opnieuw en tel de afzonderlijke reqids voor de subnetten die u verwacht voordat u succes verklaart.

Delen twee subnetten nog steeds een reqid terwijl de andere kant er twee verwacht, dan hebt u de asymmetrie gevonden. Leg de koppeling vast, want die is het bewijs dat de volgende wijziging haar heeft opgelost of behouden.

Selectors komen uit de onderhandeling, niet uit uw configuratie

De beschermde bereiken zijn wat beide kanten zijn overeengekomen, niet wat een van beide heeft gevraagd. Een client die een hostpaar tegen een breed extern bereik aanbiedt, krijgt de vernauwde versie van de gateway, en de client kan die niet verbreden. Lees de geïnstalleerde selectors in plaats van die in uw lokale bestand.

Is het doel het tegenovergestelde, één bestemming buiten de tunnel houden, voeg dan een bypass-policy met een lager prioriteitsnummer toe zodat die wint van het automatisch geïnstalleerde item. Een policy zonder template staat platte tekst toe, wat er een bewuste uitzondering voor een wijzigingsregistratie van maakt in plaats van een debuggingstap.

Controleer in deze volgorde, en weet hoe u terugdraait

Lijst de policies voor elk subnet in beide richtingen, inclusief forward als de host routeert. Tel de afzonderlijke reqids en bevestig er één per policy aan de kant die dat verwacht. Vergelijk geïnstalleerde selectors met de onderhandelde. Lees de tellers per associatie opnieuw na een rekey, want de associatie die u bekeek kan al weg zijn. Controleer routes als laatste, want een ontbrekende route naar het externe subnet geeft een vergelijkbaar eenrichtingssymptoom met schone policy-tellers.

Bewaar voordat u de peer wijzigt de huidige uitvoer van beide xfrm-opdrachten. Herstelt de nieuwe instelling de retourrichting niet, dan is die uitvoer terugzetten een snellere rollback dan de tunnel uit het geheugen opnieuw opbouwen, en het houdt de vergelijking eerlijk.