VPN nga lokacioni në lokacion ose akses në distancë: çfarë lidh secili

Të dyja zgjidhjet quhen VPN dhe zgjidhin probleme të ndryshme. Tuneli nga lokacioni në lokacion lidh dy porta, kështu që çdo host pas tyre mund të arrijë adresat e lejuara në anën tjetër pa instaluar asgjë. Tuneli i aksesit në distancë lidh pajisje individuale me një rrjet, një klient në një herë. Krahasimi ka rëndësi sepse shumica e gabimeve të vendosjes vijnë nga konfigurimi i njërës zgjidhje duke pritur sjelljen e tjetrës, dhe simptomi është zakonisht një skadim kohe në një shërbim që tuneli e arriti vërtet.

Dy zgjidhje, dy kufij

Asnjëra zgjidhje nuk zgjeron një domen transmetimi LAN. Pajisjet në anën e largët nuk shfaqen në një listë zbulimi lokale, dhe pritja e kësaj është supozimi i parë që duhet braktisur. Emrat privatë DNS që publikoni me qëllim janë më të parashikueshëm se çdo protokoll zbulimi dhe i mbijetojnë një ndryshimi furnizuesi.

Merrni 10.10.0.0/24 në një lokacion dhe 10.20.0.0/24 në tjetrin. Porta A ka nevojë për një rrugë ose një përzgjedhës trafiku që dërgon prefiksin 10.20.0.0/24 në tunel, dhe porta B ka nevojë për imazhin e saj pasqyrë. Pastaj hostet në të dyja anët përdorin lidhje IP të zakonshme dhe nuk e mësojnë kurrë se ekziston një tunel. Kjo padukshmëri është funksioni, dhe për këtë arsye dështimet duken si gabime të zakonshme rrjeti dhe jo si gabime tuneli.

I bazuar në politikë dhe i bazuar në rrugë nuk janë i njëjti tunel

Në një vendosje IPsec të bazuar në politikë, përzgjedhësit e negociuar të trafikut përcaktojnë saktësisht cilat çifte burimi dhe destinacioni janë të mbrojtura. Nëse shfaqet një nënrrjetë e re pas një porte dhe asnjë përzgjedhës nuk e mbulon, tuneli mbetet aktiv dhe nënrrjeta e re thjesht nuk transportohet. Në një zgjidhje të bazuar në rrugë, një ndërfaqe e merr trafikun dhe tabela e rrugëzimit vendos, çka e bën shtimin e një prefiksi një ndryshim rrugëzimi dhe jo një rinegociim tuneli.

StrongSwan i shfaq të dyja pamjet drejtpërdrejt, dhe leximi i tyre së bashku është mënyra për të kuptuar cilën model keni vendosur në të vërtetë.

swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'

Një listë përzgjedhësish që lë jashtë prefiksin që ju nevojitet shpjegon dështimin pa asnjë kapje paketash, dhe një rrugë që tregon ndërfaqen e gabuar shpjegon dështimin pasqyrë në kthim. Lexoni të dyja përpara se të rinegocioni çdo gjë, sepse një rinovim çelësi nuk shton një përzgjedhës që nuk e keni konfiguruar kurrë.

Planifikoni adresimin përpara tunelit

Intervalet e mbivendosura janë gabimi i projektimit që nuk mund të rregullohet me konfigurim. Nëse të dy lokacionet përdorin 192.168.1.0/24, një host që ka nevojë për 192.168.1.50 ka dy kandidatë dhe asnjë mënyrë për të zgjedhur. Tuneli do të vërtetohet, asociacionet e sigurisë do të krijohen, dhe vendimi i rrugëzimit do të jetë gjithsesi i gabuar ose i paqartë.

Zgjidhni një nga tre opsionet e ndershme: rinumeroni një lokacion, përktheni intervalin e mbivendosur në portë që secila anë të shohë një prefiks të veçantë, ose hiqni dorë nga rrugëzimi i drejtpërdrejtë për ata hoste dhe publikoni shërbimin në një mënyrë tjetër. Secili ka një kosto, dhe i pari është zakonisht më i lirë në një horizont dyvjeçar. Vendosni përpara se tuneli të ekzistojë, sepse më pas ndryshimi prek çdo pajisje që ka adresën e vjetër.

Zgjidhni edhe çështjen e MTU herët. Tuneli zvogëlon ngarkesën e dobishme, dhe një zgjidhje që mbështetet në fragmentim sillet ndryshe nga një që fikson MSS në porta.

Përcjellja dhe politika qëndrojnë jashtë tunelit

Porta duhet të jetë e gatshme të përcjellë paketa midis ndërfaqes së tunelit dhe ndërfaqes LAN, dhe të dyja drejtimet kanë nevojë për politikë që lejon shërbimin. Në Linux këto janë dy cilësime të veçanta, plus rregullat e firewall-it që vendosin nëse fluksi i përcjellë lejohet fare.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPT

Host-i marrës shton një shtresë të tretë: firewall-i i tij duhet të pranojë akoma një klient nga nënrrjeta e largët. Një server skedarësh që lejon vetëm /24 e tij lokal do të refuzojë trafikun e përcjellë nga 10.20.0.7, sado i shëndetshëm të duket tuneli, dhe ky refuzim lexohet lehtë si dështim rrugëzimi.

Provoni nga një host, jo nga porta

Një ping i dërguar nga vetë porta mund të ndjekë një adresë burimi dhe një politikë të ndryshme nga trafiku i përdoruesit i përcjellë. Kjo e bën atë një provë të dobët dhe ndonjëherë mashtruese: ka sukses ndërsa aplikacioni dështon, ose dështon ndërsa aplikacioni funksionon.

ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/null

Përdorni një host të vërtetë, një adresë burimi të vërtetë dhe protokollin e vërtetë që përdor aplikacioni. Pastaj lexoni veçmas rrugën e kthimit, sepse një drejtim përpara që funksionon pa rrugë kthimi prodhon një skadim kohe që duket identik me një shërbim të bllokuar.

Zgjidhni projektimin sipas pyetjes që po përgjigjeni: po lidhni rrjete apo po pranoni pajisje? Çdo gjë tjetër, përfshirë cilin furnizues konfiguroni, rrjedh nga ajo përgjigje.