Arritja e një stacioni pune pas NAT pa përcjellje porti

Dy pika fundore pas NAT-it të operatorit dhe një router zyre i kyçur nuk lënë asnjë port hyrës për t’u përcjellë, dhe refleksi është të kërkosh një gjithsesi. Pyetja më e mirë është cila anë mund të telefonojë jashtë dhe cilit shërbim të arritshëm i lejohet të mbajë trafikun. Katër projekte i përgjigjen asaj pyetjeje në mënyra të ndryshme, dhe dështojnë në mënyra të ndryshme kur bllokohet një shteg. Zgjedhja mes tyre është krahasim garancish, jo emrash protokollesh.

Katër projekte, katër premtime të ndryshme

Tabela më poshtë është versioni i shkurtër. Lexoni kolonën e mesme si premtimin që mund të provoni, dhe kolonën e djathtë si premtimin që askush nuk e dha.

Cila rresht zbatohet varet nga detyra dhe jo nga preferenca. Një sesion desktopi në distancë, një guaskë administrative dhe akses në të gjithë një nënrrjet privat janë tre kërkesa që nuk kanë nevojë për të njëjtën pikë hyrjeje, edhe kur rastësisht përfshijnë të njëjtën makinë.

Një hub ndryshon kush telefonon jashtë, jo çfarë lejohet

Në një projekt me hub të rrugëzuar, laptopi në distancë dhe stacioni i punës, ose porta e vendit përpara tij, hapin secili një tunel dalës drejt një shërbimi që të dy mund ta arrijnë. Asgjë nuk pranon një lidhje të pakërkuar në routerin e stacionit të punës, dhe pikërisht për këtë ky projekt i mbijeton NAT-it dhe funksionon edhe kur vendi nuk ka adresë statike. Më pas hub-i rrugëzon trafikun mes dy adresave të brendshme sipas politikës së vet.

Kostoja është që hub-i duhet të ekzistojë, të jetë i arritshëm nga të dyja anët dhe dikush duhet ta operojë. Filtrimi dalës duhet të lejojë transportin, dhe një rrjet që e bllokon do ta mposhtë projektin edhe pse nuk nevojitej përcjellje porti.

Pjesa delikate është se arritshmëria dhe autorizimi janë vendime të ndara të marra në vende të ndryshme. Një rrugë në një prefiks nuk thotë asgjë se cilin shërbim në stacionin e punës identiteti mund të përdorë, dhe një rregull firewalls që lejon tunelin nuk thotë asgjë se a mund të hyjë llogaria. Konfiguroni të dyja, provoni të dyja, dhe mbani vendimin e autorizimit te sistemi që zotëron burimin dhe jo te tabela e rrugëzimit.

Kalimi funksionon vetëm kur të dy stogët e zbatojnë

Kalimi mes palëve të barabarta është aftësi e një sistemi të caktuar, jo një cilësim që përmirëson një VPN. Interactive Connectivity Establishment mbledh disa adresa kandidate dhe provon çifte derisa një të funksionojë: kandidatë hosti në ndërfaqet lokale, kandidatë refleksivë të serverit të ndërtuar nga ajo që zbulon NAT-i, dhe kandidatë të përcjellë të alokuar në një rele. Një adresë private vetëm nuk është shteg, sepse pala tjetër nuk mund të rrugëzojë drejt saj.

Rasti i përcjellë meriton të kuptohet para se të hidhet poshtë. RFC 8656 e përshkruan TURN si një protokoll në të cilin një klient i kërkon një serveri një adresë transporti të përcjellë dhe serveri përcjell trafikun mes atij klienti dhe palëve të tij. Prandaj releja i mban të dhënat, gjë që ndryshon thelbësisht nga një drejtori që thjesht ndihmon pikat fundore të takohen. Shkëmbimi i adresës së relesë me palën tjetër është një hap koordinimi që aplikacioni duhet të kryejë.

Ajo që nuk mund të premtoni është një shteg i drejtpërdrejtë. NAT simetrik dhe disa firewalls ndërmarrjesh i mposhtin shpimet e vrimave, dhe kur e bëjnë këtë sistemi ose kthehet në një rele ose dështon. Nuk mund të konkludoni as se dy pika fundore të përkthyera nuk do të mund të flasin kurrë; një stog i mbështetur me rezervë rele ekziston pikërisht sepse shpesh munden. Vendosni nëse ka më shumë rëndësi disponueshmëria apo drejtpërdrejtësia, pastaj verifikoni cilin shteg zgjodhi në të vërtetë vendosja në vend që të supozoni rastin e favorshëm.

Një broker është më i ngushtë se një rrjet

Kur kërkesa është një aplikacion i vetëm, një broker aplikacionesh ose një lidhje e kundërt e nisur nga stacioni i punës mund të jenë përgjigjja më e vogël. Stacioni i punës telefonon jashtë drejt një brokeri, brokeri vërteton përdoruesin në distancë, dhe transportohet vetëm ai sesion aplikacioni. Nuk krijohet asnjë rrugë drejt nënrrjetit të stacionit të punës, kështu që një kompromis i sesionit në distancë nuk trashëgon një shteg drejt çdo pajisjeje pranë.

Kjo ngushtësi ka një çmim: çdo aplikacion shtesë kërkon integrimin e vet, dhe çdo gjë që aplikacioni supozon për një rrjet lokal, si një ndarje skedarësh që hap në një server të afërt, mund të mos jetë e arritshme. Brokerët gjithashtu përqendrojnë politikën dhe regjistrimin në një vend, gjë që është e dobishme derisa ai vend të bëhet ndërprerja.

Krahasoni kufijtë e besimit, pastaj provoni shtegun

Një hub që përfundon tunelet mund të lexojë trafikun që rrugëzon. Një rele mund të mbajë një shkëmbim të mbrojtur në mënyrë të pavarur kur aplikacioni kripton nga fundi në fund, dhe një broker zakonisht përfundon sesionin që paraqet. Përcaktoni ku mbaron në të vërtetë mbrojtja para se të vendosni që dy projekte janë ekuivalente sepse të dy janë të kriptuar.

Pastaj kontrolloni deri ku arrin në të vërtetë stacioni i punës nga jashtë, sepse çdo projekt më sipër varet nga kjo. Ekzekutoni këtë në stacionin e punës, duke zëvendësuar emrin e hostit që synoni të përdorni.

ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com

Pranojeni projektin vetëm pasi operacioni i synuar në distancë të ketë sukses nën identitetin e lejuar, një identitet i paaprovuar të refuzohet, dhe sjellja kur shtegu i drejtpërdrejtë ose i përcjellë nuk është i disponueshëm të jetë e njohur dhe e dokumentuar. Përfshini një rilidhje dhe kontekstin normal të nisjes së stacionit të punës, sepse një sesion që filloi në zyrë përmes LAN-it nuk provon asgjë nga të cilat varet aksesi në distancë.