VPN i folezuar: cili tunel mbart lidhjen e jashtme?

Dy klientë VPN që punojnë njëkohësisht nuk prodhojnë një tunel të folezuar; prodhojnë dy tunele dhe një grindje për routingun. Një tunel i folezuar ekziston kur lidhja e klientit të brendshëm me serverin e vet mbartet vetë nga tuneli i jashtëm, dhe ky është një rregullim që ndërtohet me qëllim. Nëse del mirë, serveri i brendshëm sheh adresën e serverit të jashtëm; nëse del keq, një klient rilidhet në heshtje përreth tjetrit. Tri kushte vendosin nëse folezimi është i vërtetë apo aksidental.

Tri kushte vendosin folezimin

E para është cila pikë fundore ka nevojë për cilën rrugë. Emërto adresën e serverit të brendshëm, emërto adresën e serverit të jashtëm dhe deklaro shprehimisht se serveri i brendshëm arrihet vetëm përmes tunelit të jashtëm. Gjithçka tjetër rrjedh nga ai fjali, duke përfshirë cilat rrugë shkojnë në cilën tabelë.

E dyta është nëse mund ta shohësh rrugën në çdo shtresë. Nëse nuk mund ta pyesësh kernelin cilën rrugë do të përdorte një destinacion i caktuar, po e nxjerrim zinxhirin nga një IP e fundit dalëse, dhe pikërisht kjo është prova që nuk mund të dallojë folezimin nga rastësia.

E treta është çfarë ndodh kur tuneli i jashtëm bie. Tuneli i brendshëm mund të ndalet bashkë me të, të rilidhet përmes rrjetit të zakonshëm ose të mbetet i bllokuar derisa rruga e jashtme të kthehet, dhe të treja janë politika të mbrojtshme. Nuk janë e njëjta politikë, dhe sjellja e parazgjedhur e shumicës së klientëve është e dyta. Një klient që rilidh pikën e vet fundore përmes rrjetit fizik ndërsa shfaq një lidhje të shëndoshë është mënyra më e zakonshme se si një zinxhir i synuar bëhet në heshtje dy tunele të palidhura.

Kushti një: cila pikë fundore ka nevojë për cilën rrugë

ip route get 203.0.113.10 i përgjigjet drejtpërdrejt asaj pyetjeje: printon rrugën, adresën burimore dhe ndërfaqen që kerneli do të përdorte për atë destinacion tani.

Ekzekutoje për serverin e brendshëm përpara se klienti i brendshëm të niset dhe përsëri pas, pastaj krahaso. Nëse përgjigja ndryshon nga ndërfaqja fizike në ndërfaqen e tunelit të jashtëm, folezimi është i vërtetë në atë moment. Nëse nuk ndryshon, klienti i brendshëm po lidhet drejtpërdrejt, çfarëdo që thotë paneli. Përsërite për adresën e serverit të jashtëm, e cila ende duhet të zgjidhet përmes ndërfaqes fizike, sepse një rrugë që kap të dyja pikat fundore në mënyrë rekursive është defekti që e nxjerr makinën plotësisht nga rrjeti.

Kushti dy: inspekto rrugën në çdo shtresë

Zgjedhja e rrugës është më shumë se tabela kryesore në një klient modern. Rregullat e politikës mund të dërgojnë paketa të shënuara në një tabelë tjetër, një klient mund ta lidh soketin e vet me një ndërfaqe, dhe një kontejner ose namespace ka tabela të vetat. ip rule dhe ip route show table all janë mënyra për të zbuluar cili prej këtyre mekanizmave është në lojë.

Një klient që vendos SO_MARK në soketin e vet, ose që është konfiguruar të lidhet me një pajisje të caktuar, anashkalon rrugën e parazgjedhur që mendonit se e kishit rregulluar. Ky është funksion dhe jo defekt, dhe do të thotë se kontrolli i vetëm i besueshëm është ai që ekzekutohet në të njëjtin namespace me klientin. Nëse klientët ekzekutohen në kontejnerë, ekzekuto kontrollet brenda atyre kontejnerëve në vend të hostit.

Kushti tre: çfarë ndodh kur tuneli i jashtëm bie

Sjellja në defekt kërkon një vendim, jo një vlerë të parazgjedhur. Shkruaj çfarë duhet të ndodhë me tunelin e brendshëm kur ai i jashtëm zhduket, pastaj bëj që klientët ta zbatojnë.

Opsionet janë konkrete. Ndalimi i klientit të brendshëm kur zhduket rruga e jashtme jep një zinxhir të pastër dhe një ndërprerje të dukshme. Lënia e tij të rilidhet drejtpërdrejt jep disponueshmëri dhe heq në heshtje vetinë për të cilën u ndërtua zinxhiri. Bllokimi derisa rruga e jashtme të kthehet është më i rreptë dhe më i bezdisshëm për t'u operuar, sepse çdo lëkundje e tunelit të jashtëm bëhet një incident i dukshëm.

Testo të treja me trafik të padëmshëm dhe një defekt të qëllimshëm të tunelit të jashtëm, sepse leximi i konfigurimit nuk të thotë cilën ke. Vrite tunelin e jashtëm, shiko çfarë bën klienti i brendshëm dhe kontrollo rrugën përsëri ndërsa është poshtë. Pastaj kthe tunelin e jashtëm dhe konfirmo se zinxhiri riformohet në vend që ta lërë klientin e brendshëm në rrugën e drejtpërdrejtë që zgjodhi ndërkohë.

Çfarë nuk të jep zinxhiri

Shtresat shtesë shtojnë pika fundore, çelësa dhe mënyra defekti; nuk shtojnë asnjë garanci anonimiteti dhe nuk e bëjnë operatorin e jashtëm të paaftë të shohë se ekziston një tunel. Çdo pohim për atë që mbron folezimi duhet të emërtojë vëzhguesin kundër të cilit mbron.

Dorëzimi është një dokument i shkurtër dhe jo një lidhje që funksionon: cila pikë fundore përdor cilën rrugë, çfarë ndodh në një defekt të jashtëm dhe tri komandat që tregojnë gjendjen aktuale. Dokumentacioni i strongSwan për përçimin është një referencë e dobishme për mënyrën se si trafiku i tunelit përçohet midis ndërfaqeve në një host Linux. Ekzekuto kontrollet përsëri pas çdo përditësimi të klientit, sepse vlerat e parazgjedhura që krijuan zinxhirin tënd nuk janë kontratë. Një tunel i folezuar që nuk mund ta inspektosh është një thashethem me një dritë statusi.