Når IKEv2 returnerer TS_UNACCEPTABLE, sammenlign de rigtige subnet

Læs TS_UNACCEPTABLE som en uenighed om dækning, ikke som en beskadiget profil. Gatewayen siger, at de to parter ikke kunne blive enige om, hvilke adresser denne tunnel må bære. IKE SA kan allerede være oppe på det tidspunkt, og derfor kan en klient se ud som forbundet uden nogen underordnet SA bag sig. Når du stiller det sådan op, bliver arbejdet mekanisk. Skriv begge parters tilsigtede præfikser ned, sammenlign dem i én retning, og indsnævr, indtil de skærer hinanden.

Skriv de tilsigtede par ned først

Før du rører konfigurationen, list fire værdier: initiatorens kildeområde, dets destinationsområde og det samme par set fra responderens side. Notér også adressefamilien for hver af dem. Et IPv4-område og et IPv6-område er forskellige selectortyper, og ingen af dem kan foldes ind i den andens nyttelast.

Tilføj enhver protokol- eller portbegrænsning, som politikken bærer. En regel, der kun tillader TCP 445 til en filserver, beskriver et snævrere sæt end det subnet, den ligger i. Udelader du det af dine noter, vil forhandlingsresultatet se inkonsistent ud af grunde, du ikke kan se.

Vend betegnelserne om, før du sammenligner dem

Lokal og fjern er relative betegnelser. Klientens lokale præfiks er gatewayens fjernområde, og gatewayens lokale område er klientens fjerne. Derfor stemmer skærmbilleder fra de to ender aldrig overens, og at sammenligne dem bogstaveligt er den standardmåde at tabe en eftermiddag på.

En responder kan indsnævre et tilbud til en acceptabel undermængde i stedet for at afvise det. Det udfald er værre end en ren fiasko, fordi det virker halvt. Bed om 10.0.0.0/16, når politikken tillader 10.0.5.0/24, og du kan ende med en underordnet SA, der kun dækker det /24. Én vært svarer, alt andet falder udenfor, og intet i klienten siger det. Læs de accepterede selectors frem for de anmodede, før du konkluderer, at forhandlingen lykkedes.

Road-warrior-profiler, der anmoder om en standardrute, lander her konstant. En gateway bygget til delt adgang indsnævrer et tilbud med fuldt område til sine egne subnet, og klienten må acceptere det indsnævrede resultat eller fejle højlydt.

Læs afvisningen fra ét forsøg

Indsaml begge logfiler fra det samme forbindelsesforsøg. En gemt profil viser, hvad du konfigurerede, ikke hvad der blev foreslået, og på strongSwan udskriver swanctl --log den modtagne notifikation sammen med de selectors, den bar.

Undersøg derefter, hvad der faktisk blev installeret. swanctl --list-sas viser den underordnede SA's selectors, og ip xfrm policy viser de samme områder som kernepolitikposter. En underordnet SA i den liste med selectors, du ikke havde til hensigt, er en indsnævringshændelse; ingen underordnet SA plus TS_UNACCEPTABLE i loggen er en afvisning.

Adskil de nære naboer, mens du er derinde. INVALID_SELECTORS klager over en selector inde i en etableret underordnet SA, mens INTERNAL_ADDRESS_FAILURE betyder, at responder ikke kunne tildele en virtuel adresse, hvilket er et poolproblem snarere end et dækningsproblem.

Tjek, hvad der lydløst skrumper sættet

Tre ting skrumper et selectorsæt uden at sige noget. Responderpolitik er den første, gennem subnetlister, grupperegler eller autorisation pr. bruger, der reducerer tilbuddet til en undermængde. Adressefamilie er den anden: en dual-stack-klient foreslår ofte IPv6 ved siden af IPv4 og får en afvisning for områder, som gatewayen aldrig har konfigureret.

Protokoll- og portbegrænsninger er den tredje. Hvor politikken kun tillader TCP 445, kan en underordnet SA komme op, mens ICMP og UDP forbliver udenfor, og brugeren rapporterer en brudt tunnel, når én protokol var alt, hvad der nogensinde var tilladt.

Derfor kan udvidelse af adresser alene ikke reparere en portbegrænset politik, og det er netop det tilfælde, der mest sandsynligt overlever tre runder fejlsøgning uændret.

Bevis dækning med trafik, der passer

Efter at den underordnede SA er installeret, send én anmodning, der bestemt falder inden for de accepterede områder. Hold øje med tællerne i stedet for statusikonet: ip -s xfrm state og tællerne bag ip xfrm policy stiger, når en pakke matches og beskyttes. Et bytetælling, der bliver på nul efter rigtig trafik, betyder, at kernen aldrig valgte den politik.

Det nul er et routing- eller politikrækkefølgeproblem, ikke et krypto-problem. Det ser også identisk ud med en selectorafvisning fra brugerens synspunkt, og derfor er tællerne værd at indsamle, før du åbner profilen igen. Tællere, der kun stiger i én retning, peger i stedet på returvejen.

Afslut med at skrive det accepterede par ind i billetten, ved siden af det område, der oprindeligt blev anmodet om. Hold valget så snævert som kravet, fordi at fjerne fejlen ved at erstatte et privat område med alle adresser giver langt mere adgang, end kontoen blev godkendt til.