IPsec-beleid sluk jou plaaslike verkeer in: hoe om dit te herken

Die drukker op die lessenaar hou op antwoord die oomblik toe die tonnel opkom, en niks in die tonnelkonfigurasie noem die drukker nie. Wat gewoonlik gebeur het, is dat ’n beskermde reeks so breed geskryf is dat dit hom insluit, so die masjien probeer nou verkeer versifreer wat op die plaaslike segment moes bly. Om die geïnstalleerde beleid te lees verduidelik die onderskepping; om dit op die regte plek te vernou hou die afgeleë verkeer beskerm. Die reis van mislukte versoek na passende beleid neem ’n paar minute.

Volg die vloei voordat jy ’n keurder verander

Begin by die mislukte versoek en skryf vier waardes neer: die bronadres wat die masjien gebruik, die presiese bestemming, die roete wat die kern kies en die beleid wat by daardie paar pas.

Daardie vier feite besluit of die onderskepping doelbewus of toevallig is. ’n Bestemming wat binne die afgeleë keurder val, word volgens ontwerp beskerm, selfs al was die ontwerp verkeerd. ’n Bestemming daarbuite wat steeds onderskep word, beteken iets anders pas, en om die keurder te verander sal nie help nie. Albei gevalle kom algemeen voor, en een opdrag onderskei hulle.

Doen dit voordat jy enigiets wysig, want die interessante geval is die plaaslike subnet wat oorvleuel met ’n private reeks wat die verbinding beskerm. Bekende voorvoegsels soos 192.168.0.0/16 kom in baie netwerke voor, en ’n keurder wat vir een daarvan geskryf is, kan stil jou s’n dek.

Drie soorte plaaslik wat anders optree

’n Bestemming wat aan hierdie gasheer toegewys is, ’n bestemming op dieselfde skakel en ’n bestemming agter ’n ander koppelvlak is drie verskillende gevalle. Die kern behandel elkeen anders wanneer dit besluit of verkeer beskerming nodig het.

Verkeer wat die poort self genereer, is ook nie dieselfde as verkeer wat van ’n kliënt aanstuur word nie. ’n Beleid wat korrek lyk vir aangestuurde verkeer, kan die poort se eie bestuursessie onderskep, en dit is hoe ’n administrateur toegang verloor terwyl hy die tonnel herstel.

Die nuttige gewoonte is om die geval hardop te noem: kom hierdie pakkie van my, na my skakel of deur my? Elke antwoord wys na ’n ander plek om te vernou. Om die geval neer te skryf verhoed ook dat die volgende persoon dieselfde werk weer doen.

Wanneer die beskermde reeks ’n hele private ruimte is, kan al drie gevalle gelyk daarin val, en die simptoom word ’n masjien wat niks bereik behalwe die tonnel-eindpunt nie.

Lees die geïnstalleerde beleid, nie die lêer nie

Konfigurasielêers beskryf die bedoeling; die kern hou die beleide wat werklik pas. Wys albei en behandel ’n verskil as die eerste bevinding.

Hierdie opdragte wys die gekose roete na die bestemming en die geïnstalleerde beleide in elke rigting:

ip route get 192.168.50.20
ip xfrm policy list
sudo swanctl --list-conns

Die roete vertel jou watter koppelvlak die pakkie sou gebruik. Die beleidslys vertel jou of daar dan ’n sjabloon op daardie pakkie toegepas word, en die verbindingslys wys watter keurders die daemon dink hy geïnstalleer het. As die bestemming in ’n afgeleë keurder voorkom, het jy die onderskepping gevind sonder om te raai.

Vernou die keurder of omseil die bestemming

Daar is twee ondersteunde herstellings en hulle beantwoord verskillende vrae. Om die keurder te vernou sê dat hierdie verbinding net ’n kleiner reeks beskerm, wat korrek is wanneer die wyer reeks ’n fout was. Om ’n omseiling by te voeg sê dat hierdie spesifieke bestemming nooit beskerm moet word nie, wat korrek is wanneer die beskermde reeks werklik breed is en een bestemming die uitsondering is.

Kies die eerste wanneer jy kan, want ’n kleiner keurder is makliker om oor te redeneer en verskyn in die verbindingsdefinisie. Kies die tweede wanneer die wye reeks doelbewus is en die uitsondering ’n enkele gasheer of subnet is wat jy kan noem.

Albei hoort in die konfigurasie wat die verbinding besit. ’n Looptyd-reël wat met die hand bygevoeg is, verdwyn by die volgende herverbinding, en die fout kom terug op ’n oomblik wanneer niemand die workaround onthou nie.

Uitsonderings wat herinstallasie oorleef

Herhaal ná die verandering dieselfde onskadelike versoek en kyk na dieselfde tellers. Die plaaslike bestemming behoort te antwoord, en die beoogde afgeleë bestemming behoort steeds versifreerde verkeer te wys.

Hierdie twee kontroles bevestig dat die uitsondering oorleef het en die beskerming nie:

ip xfrm policy list | grep -c out
ping -c 3 192.168.50.20

Koppel dan die tonnel doelbewus af en weer aan, en herhaal albei. ’n Uitsondering wat voor die herverbinding werk en daarna misluk, is op die verkeerde laag toegepas, en dit is die mees algemene manier waarop hierdie probleem terugkom.