IPsec caureja mājas maršrutētājā: ko tā patiešām dara

Maršrutētāja caurejas slēdži ir pārsūtīšanas piekāpšanās aiz tiem esošajai ierīcei, nevis VPN pakalpojumi. Tie nereģistrē maršrutētāju kā klientu, neglabā pieteikšanās datus un nedzen katru mājas ierīci caur attālu izeju. Tie dara to, ka veido, kā viens protokols šķērso adrešu tulkošanu un filtrus. Kad tas ir skaidrs, slēdzi ir viegli pārbaudīt un viegli atstāt izslēgtu.

Ko maršrutētājs patiešām dara

Maršrutētājs atrodas starp klientu un IPsec partneri un pārsūta paketes, kuru saprašanai tas nekad nav bijis paredzēts. Ražotāji funkciju īsteno vismaz trīs veidos: protokola palīgs, kas seko vai pārraksta stāvokli; filtra izņēmums, kas pārtrauc ESP nomešanu; vai saderības režīms vecākiem klientiem. Etiķete tīmekļa saskarnē reti pasaka, kurš no trim jums ir. To pateiks tikai programmaparatūras piezīmes vai pakešu ieraksts.

Palīgs var arī pasliktināt situāciju. Palīdzība, kas rakstīta vecākai plūsmai, dažkārt traucē klientam, kurš tulkošanu jau apstrādā pareizi. Kad moderns klients darbojas ar izslēgtu opciju, atstāt to izslēgtu ir labāka konfigurācija.

Caureja nekad nedod maršrutētājam partneru atslēgas. Tas joprojām redz ārējās adreses un portus un joprojām piemēro tiem savu pārsūtīšanas politiku.

NAT un NAT-T nosaka ceļu

IPsec netika būvēts, lai pārdzīvotu adrešu tulkošanu, tāpēc standarti pievienoja apvalku. NAT traversal ievieto ESP UDP iekšpusē, ļaujot parastai NAT tabulai nest plūsmu, un sarunas par šo pārslēgšanu vienojas IKE laikā (RFC 3948). Pats IKE izmanto UDP 500, bet apvalkotais ceļš parasti izmanto UDP 4500.

Tāpēc ugunsmūra noteikums, kas atļauj tikai protokolu 50, tulkotā ceļā nav pietiekams. 4500 bloķēšana salauž gadījumu, kura dēļ apvalks pastāv, un 500 bloķēšana aptur sarunas pirms jebkura tuneļa izveidošanās. Abi virzieni ir svarīgi, jo stāvokli sekojošs maršrutētājs parasti atļauj atbildi tikai pēc tam, kad ir redzējis pieprasījumu. Sasniegt portu nav tas pats, kas pabeigt autentifikāciju, un nav tas pats, kas pārsūtīt aizsargātu datplūsmu.

Vecāki risinājumi atšķiras pietiekami, lai tiem rakstīta rokasgrāmata varētu maldināt. Kad klients piedāvā abus režīmus, pārbaudiet to, ko dokumentē jūsu partneris, nevis to, kuram ir vairāk meklēšanas rezultātu.

Atrodiet neizdevušos posmu

Sadaliet problēmu sarunās, autentifikācijā, bērna aizsardzībā un iekšējā pārsūtīšanā, pēc tam vāciet pierādījumus vienam posmam reizē. Restartēšana, kas īslaicīgi maina rezultātu, pierāda tikai to, ka bija iesaistīts kāds stāvoklis.

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

Ieraksts parāda, vai apmaiņa sasniedz partneri un vai atbildes atgriežas, kas atdala filtrēšanas problēmu no pieteikšanās datu problēmas. Stāvokļu saraksts parāda izveidotās drošības asociācijas, tāpēc tukšs saraksts pēc mēģinājuma norāda uz sarunām, nevis maršrutēšanu. Politikas saraksts parāda, kuri selektori ir instalēti, un tieši tur tiek izslēgts galamērķis ārpus apakštīkla. Izlasiet abas xfrm izvades pirms maršrutētāja aizskaršanas, jo tās apraksta, ko uzskata resursdators, nevis ko atļauj maršrutētājs.

Ja paketes iziet un nekas neatgriežas, pārvietojiet ierakstu uz maršrutētāja WAN pusi. Abu ierakstu salīdzināšana lokalizē nomešanu bez minēšanas.

Izslēdziet to, kas jums nav vajadzīgs

Viens strādājošs portatīvais dators nepierāda, ka maršrutētājs apkalpo vairākus klientus vienlaikus. Katrs klients veido savu tulkošanas stāvokli un savas sarunas, un daži palīgi seko tikai vienai plūsmai. Pārbaudiet vienlaikus nepieciešamo sesiju skaitu tīklos, kurus patiešām izmantojat. Ja otrais klients neizdodas, kamēr pirmais plaukst, tas ir atradums, nevis nestabils tunelis.

Atstājiet opciju ieslēgtu tikai tad, kad ieraksts parāda, ka tā ir nepieciešama. Pierakstiet programmaparatūras versiju blakus rezultātam, jo šī uzvedība mainās starp laidieniem. Mērķis ir jūsu pārbaudīts klienta tunelis, nevis cerībā ieslēgts slēdzis.