IPsec-policy sluker den lokale trafikken din: slik kjenner du det att

Skrivaren på skrivebordet sluttar å svare i det augneblinken tunnelen kjem opp, og ingenting i tunnelkonfigurasjonen nemner skrivaren. Det som vanlegvis har skjedd, er at eit verna område vart skrive breitt nok til å omfatte han, så maskinen prøver no å kryptere trafikk som skulle blitt på det lokale segmentet. Å lese den installerte policyen forklarer oppfanginga; å avgrense han på rett stad held fjerntrafikken verna. Turen frå den mislukka førespurnaden til den samsvarande policyen tek nokre minutt.

Følg flyten før du endrar ein veljar

Start ved den mislukka førespurnaden og skriv ned fire verdiar: kjeldeadressa maskinen brukar, den nøyaktige destinasjonen, ruta kjernen vel, og policyen som passar til det paret.

Desse fire fakta avgjer om oppfanginga er medviten eller tilfeldig. Ein destinasjon som fell innanfor fjernveljaren, vert verna ved design, sjølv om designet var feil. Ein destinasjon utanfor han som likevel vert fanga opp, tyder på at noko anna passar, og det hjelper ikkje å endre veljaren. Begge tilfella er vanlege, og éin kommando skil dei.

Gjer dette før du redigerer noko, for det interessante tilfellet er det lokale subnettet som overlappar med eit privatområde sambandet vernar. Kjende prefiks som 192.168.0.0/16 finst i mange nettverk, og ein veljar skriven for eitt av dei kan stille dekkje ditt eige.

Tre slag lokalt som oppfører seg ulikt

Ein destinasjon som er tildelt denne verten, ein destinasjon på same lenkje og ein destinasjon bak eit anna grensesnitt er tre ulike tilfelle. Kjernen handsamar kvar av dei ulikt når han avgjer om trafikken treng vern.

Trafikk som gatewayen sjølv genererer, er heller ikkje det same som trafikk vidaresend frå ein klient. Ein policy som ser riktig ut for vidaresend trafikk, kan fange gatewayen sin eigen administrasjonssesjon, og det er slik ein administrator misser tilgangen medan han reparerer tunnelen.

Den nyttige vanen er å namngje tilfellet høgt: kjem denne pakken frå meg, til lenkja mi eller gjennom meg? Kvart svar peikar på ein annan stad å avgrense. Å skrive ned tilfellet hindrar også neste person i å gjere same arbeid på nytt.

Når det verna området er eit heilt privat rom, kan alle tre tilfella falle inn i det samtidig, og symptomet vert ein maskin som ikkje når noko anna enn tunnelendepunktet.

Les den installerte policyen, ikkje fila

Konfigurasjonsfiler skildrar intensjonen; kjernen held policyane som faktisk passar. Vis begge, og handsam eit avvik som det første funnet.

Desse kommandoane viser den valde ruta til destinasjonen og dei installerte policyane i kvar retning:

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

Ruta fortel deg kva grensesnitt pakken ville bruke. Policylista fortel deg om det deretter vert brukt ein mal på pakken, og sambandslista viser kva veljarar daemonen trur han har installert. Viss destinasjonen dukkar opp i ein fjernveljar, har du funne oppfanginga utan å gjete.

Avgrens veljaren eller omgå destinasjonen

Det finst to støtta reparasjonar, og dei svarar på ulike spørsmål. Å avgrense veljaren seier at dette sambandet berre vernar eit mindre område, noko som er riktig når det breiare området var ein feil. Å leggje til ein omgåing seier at denne bestemte destinasjonen aldri skal vernast, noko som er riktig når det verna området verkeleg er breitt og éin destinasjon er unntaket.

Vel den første når du kan, fordi ein mindre veljar er lettare å resonnere om og viser seg i sambandsdefinisjonen. Vel den andre når det breie området er medvite og unntaket er ein enkelt vert eller eit subnett du kan namngje.

Begge høyrer til konfigurasjonen som eig sambandet. Ei køyretidsregel lagd til for hand forsvinn ved neste gjenoppkopling, og feilen kjem tilbake på eit tidspunkt då ingen hugsar workarounden.

Unntak som overlever reinstallasjon

Etter endringa gjer du om den same ufarlege førespurnaden og ser på dei same teljarane. Den lokale destinasjonen bør svare, og den tiltenkte fjerndestinasjonen bør framleis vise kryptert trafikk.

Desse to kontrollane stadfester at unntaket overlevde og vernet ikkje:

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

Kopla deretter frå og tilbake til tunnelen med vilje, og gjer om begge. Eit unntak som verkar før gjenoppkoplinga og feilar etter, vart brukt på feil lag, og det er den vanlegaste måten dette problemet kjem tilbake på.