Kush përgjigjet në të vërtetë në adresën e dedikuar të VPN-së?

Një adresë që qëndron e papërdorur në caktimin e organizatës nuk është dëgjues, dhe shtimi i saj në një mur zjarri nuk krijon asnjë. Diçka duhet të përfundojë IKE në atë adresë, dhe mekanizmi ndryshon sipas faktit nëse adresën e zotëron porta hyrëse apo e përkthen një pajisje në rrjedhën e sipërme. Është rruga e paketës ajo që i dallon të dyja, dhe ajo përcakton se cila veçori e platformës ju nevojitet përpara se dikush të hapë një kërkesë ndryshimi. Modeloni së pari rrugën, pastaj zgjidhni.

Rruga e paketës prapa adresës

Një palë dërgon IKE në adresën që i është dhënë, në UDP 500 ose në UDP 4500 kur është në lojë kalimi përmes NAT. Cilado pajisje që e mban atë adresë në rrugë ose e pranon datagramin lokalisht dhe i përgjigjet, ose e përcjell diku tjetër. Këto janë të vetmet dy mundësi, dhe gjithçka tjetër në këtë artikull rrjedh nga ajo se cila është e vërtetë.

Pranimi lokal do të thotë që në atë pajisje ekziston një socket, i lidhur me atë adresë. Përcjellja do të thotë që datagrami rishkruhet dhe dërgohet më tej drejt një pike tjetër fundore, e cila atëherë e ka socket-in. Një rregull muri zjarri që lejon UDP 500 nuk ju thotë asgjë se cila nga të dyja po ndodh.

Shkruani regjistrin përpara se të prekni diçka: adresa me të cilën kontaktojnë palët, si e dorëzon rrjeti i sipërm, ndërfaqja lokale ose pika fundore logjike që e pranon, dhe procesi që i përgjigjet IKE. Katër rreshta, dhe secili mund të verifikohet. Kur njëri prej tyre është i panjohur, ai i panjohur është puna e projektimit dhe jo një detaj implementimi për t'u zgjidhur më vonë. Plotësimi i tyre pas miratimit të kërkesës së ndryshimit është mënyra se si një rregull përkthimi përfundon në pajisjen e gabuar.

Modeli A: porta hyrëse e zotëron adresën

Në modelin e parë porta hyrëse e mban vetë adresën, qoftë si adresë dytësore në një ndërfaqe ekzistuese, si adresë në një ndërfaqe të dedikuar, ose si loopback që platforma e mbështet si pikë fundore tuneli. Këto janë tre veçori të ndryshme me tre rrugë konfigurimi të ndryshme, dhe një platformë që mbështet njërën mund të mos i mbështesë të tjerat.

Konfirmoni që platforma dhe versioni mbështesin saktësisht këtë rregullim përpara se të projektoni rreth tij. Një bllok i rrugëtuar, një adresë shtesë në një ndërfaqe dhe një pikë fundore loopback nuk janë të këmbyeshme, dhe dokumentacioni i një versioni nuk premton se versioni tjetër sillet njësoj.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

Socket-i që dëgjon është prova. Nëse asgjë nuk është e lidhur me adresën, porta hyrëse nuk është përfunduesi pavarësisht se çfarë thotë tabela e rrugëtimit, dhe kapja e paketave do të tregojë datagramet që vijnë pa asgjë që u përgjigjet.

Mos vendosni një ndërfaqe të dytë në një nënrrjet që ekziston tashmë diku tjetër në topologji dhe mos supozoni se platforma do ta rregullojë. Nënrrjetet e ndërfaqeve që mbivendosen prodhojnë zgjedhje të paqartë të burimit dhe, në shumë platforma, një refuzim të plotë për t'u konfiguruar.

Modeli B: një pajisje në rrjedhën e sipërme e përkthen

Në modelin e dytë një mur zjarri në rrjedhën e sipërme mban adresën e dedikuar dhe e përcjell trafikun drejt një porte tjetër VPN. Ky është një përkthim destinacioni me rrugë kthimi, dhe është një projekt plotësisht i vlefshëm për sa kohë dokumentohet si i tillë.

Ajo që nuk është, është provë që pajisja e sipërme ka marrë një socket VPN lokal. Përkthimi përcjell paketa; ai nuk e bën kutinë e sipërme një përgjigjës IKE. Nëse rregulli i sipërm hiqet ose rruga e kthimit të tij prishet, VPN ndalon edhe pse porta hyrëse është e shëndoshë dhe dëgjuesit e saj të paprekur.

Regjistroni të dyja adresat: atë me të cilën kontaktojnë palët dhe atë që porta hyrëse sheh vërtet. Më pas regjistroni transportin dhe rrugën e kthimit, sepse një përkthim që funksionon për UDP 500 por jo për ESP të inkapsuluar do të lidhet dhe më pas do të dështojë të mbajë trafikun, gjë që është një dështim konfuz për t'u korrigjuar më vonë.

Identiteti nuk është adresa e jashtme

IPsec e ndan pikën fundore të tunelit nga trafiku që mbron, dhe arkitektura i mban ato vendime në vende të ndryshme. Ndryshimi i adresës me të cilën kontaktojnë palët nuk ndryshon automatikisht cilat prefikse të brendshme lejohen, cilat rrugë instalohen ose cilat burime mund të arrijë sesioni.

Identiteti i vërtetuar është sërish i veçantë. IKEv2 mbart një ngarkesë identiteti dhe një shkëmbim vërtetimi që nuk kanë pse përputhen me adresën e jashtme të paketës, dhe pikërisht për këtë një projekt i përkthyer mund të vërtetojë ende saktë.

Ajo pavarësi është e dobishme dhe njëkohësisht kurth. Dy emra DNS që zgjidhen në një dëgjues të zakonshëm nuk zgjedhin backend-e të ndryshme VPN, dhe një certifikatë që emërton një identitet nuk do të kënaqë një palë që pret një tjetër. Konfirmoni çfarë validon pala përpara se të supozoni se vetëm adresa e vendos atë.

Pranojeni projektin duke vëzhguar një lidhje

Inspektoni ku dorëzohet vërtet një lidhje e re e autorizuar, cili identitet përgjigjet dhe cili rrjedhë private lejohet më pas. Tre vëzhgime, tre shtresa të ndryshme, dhe një kërkim publik i suksesshëm i adresës nuk teston asnjërën prej tyre.

Mbani edhe rastin negativ: një palë që nuk duhet të pranohet, ose një prefiks të brendshëm që nuk duhet të jetë i arritshëm, i verifikuar pas ndryshimit. Regjistri që shkruat në fillim është ai që e bën të mundur atë test pa rindërtuar projektin nga kujtesa.

Qëllimi i gjithë kësaj është t'i lejojë pronarit të rrjetit të zgjedhë një metodë caktimi të mbështetur, në vend që të mbështetet në një pohim të përgjithshëm se çfarë mund të bëjë çdo mur zjarri me një adresë shtesë. Pikërisht ai pohim është vendi ku këto projekte dështojnë, sepse tingëllon i besueshëm në çdo platformë dhe në përgjithësi nuk është i vërtetë në asnjërën. Regjistri prej katër rreshtash e zgjidh atë për platformën tuaj në dhjetë minuta.