IPsec-gjennomføring på en hjemmeruter: hva den egentlig gjør

Ruterens gjennomføringsbrytere er videresendingsinnrømmelser for en enhet bak dem, ikke VPN-tjenester. De registrerer ikke ruteren som klient, holder ikke på påloggingsinformasjon og presser ikke hver enhet i huset gjennom en fjernutgang. Det de gjør, er å forme hvordan én protokoll krysser adresseoversettelsen og filtrene. Når det er klart, er bryteren lett å teste og lett å la være av.

Hva ruteren egentlig gjør

Ruteren sitter mellom en klient og en IPsec-peer og videresender pakker den aldri var designet for å forstå. Produsentene implementerer funksjonen på minst tre måter: en protokollhjelper som følger eller skriver om tilstand, et filterunntak som stopper å droppe ESP, eller en kompatibilitetsmodus rettet mot eldre klienter. Etiketten i nettgrensesnittet sier sjelden hvilken av de tre du har. Bare fastvarenotatene eller en pakkeopptak vil si det.

En hjelper kan også gjøre tingene verre. Hjelp skrevet for en eldre flyt forstyrrer noen ganger en klient som allerede håndterer oversettelsen riktig. Når en moderne klient virker med valget av, er det den bedre konfigurasjonen å la det være av.

Gjennomføring gir aldri ruteren nøklene til peerne. Den ser fortsatt de ytre adressene og portene og bruker fortsatt sin egen videresendingspolicy på dem.

NAT og NAT-T avgjør veien

IPsec ble ikke bygget for å overleve adresseoversettelse, så standardene la til en innpakning. NAT-traversering kapsler ESP inn i UDP, slik at en vanlig NAT-tabell kan bære flyten, og forhandlingen blir enige om den vekslingen under IKE (RFC 3948). IKE selv bruker UDP 500, mens den innkapslede veien vanligvis bruker UDP 4500.

Derfor er en brannmurregel som bare tillater protokoll 50 ikke nok på en oversatt vei. Blokkering av 4500 ødelegger tilfellet innpakningen finnes for, og blokkering av 500 stopper forhandlingen før noen tunnel dannes. Begge retninger betyr noe, fordi en tilstandsbasert ruter vanligvis først tillater svaret etter å ha sett forespørselen. Å nå en port er ikke det samme som å fullføre autentisering, og heller ikke det samme som å videresende beskyttet trafikk.

Eldre ordninger er forskjellige nok til at en veiledning skrevet for dem kan villede. Når en klient tilbyr begge modiene, test den peer-en din dokumenterer framfor den med flest søkeresultater.

Finn trinnet som svikter

Del problemet i forhandling, autentisering, beskyttelse av barnet og indre videresending, og samle deretter bevis for ett trinn om gangen. En omstart som midlertidig endrer resultatet, beviser bare at en eller annen tilstand var involvert.

sudo tcpdump -ni any 'udp port 500 or udp port 4500'
ip xfrm state list
ip xfrm policy list

Opptaket viser om utvekslingen når peeren og om svar kommer tilbake, noe som skiller et filtreringsproblem fra et påloggingsproblem. Tilstandslisten viser etablerte sikkerhetsassosiasjoner, så en tom liste etter et forsøk peker på forhandling og ikke på ruting. Policylisten viser hvilke selektorer som er installert, og det er der en destinasjon utenfor subnettet utelukkes. Les begge xfrm-utskriftene før du rører ruteren, fordi de beskriver hva verten tror og ikke hva ruteren tillater.

Hvis pakkene forlater og ingenting kommer tilbake, flytt opptaket til WAN-siden av ruteren. Å sammenligne de to opptakene lokaliserer droppet uten å gjette.

Slå av det du ikke trenger

Én fungerende bærbar PC beviser ikke at ruteren betjener flere klienter samtidig. Hver klient lager sin egen oversettelsestilstand og sin egen forhandling, og noen hjelpere følger bare én flyt. Test antall samtidige økter du faktisk trenger, fra nettverkene du faktisk bruker. Hvis den andre klienten feiler mens den første trives, er det funnet og ikke en ustabil tunnel.

La valget stå på bare når et opptak viser at det er nødvendig. Noter fastvareversjonen ved siden av resultatet, fordi denne oppførselen endres mellom utgivelser. Målet er en klienttunnel du har verifisert, ikke en bryter du slo på i håp.