VPN pas një NAT që nuk mund ta konfiguroni: çfarë funksionon ende

Çdo pikë fundore tuneli ka nevojë për një adresë dhe një port që pala tjetër mund t'i arrijë, dhe një ruter që nuk e administroni është arsyeja e zakonshme pse kjo kërkesë dështon. Pjesa interesante nuk është se ekzistojnë truke, por se secili prej tyre varet nga një veti e një tabele hartëzimi që nuk e shihni nga klienti. Dy nga ato veti vendosin pothuajse gjithçka: si krijohet një hartëzim dhe nëse pranon paketa nga një adresë me të cilën pjesa e brendshme nuk ka komunikuar kurrë. Renditni mjedisin sipas atyre vetive dhe zgjidhjet anashkaluese nuk janë më folklor.

Tabela e hartëzimit vendos gjithçka

Përkthimi i adresave të rrjetit mban një tabelë ku një adresë dhe port i brendshëm regjistrohen përballë një adrese dhe porti publik. Përgjigjet që përputhen me një regjistrim përkthehen mbrapsht, dhe një paketë që vjen nga jashtë pa një regjistrim përputhës nuk ka fare destinacion. Kjo sjellje e vetme shpjegon pse një dëgjues pas ruterit është i paarritshëm nga interneti. Shpjegon gjithashtu pse paketa e parë në çdo drejtim duhet të dalë nga brenda.

Shikoni tabelën nga ana e ruterit dhe zgjidhjet bëhen të dukshme: ose diçka krijon një hyrje të përhershme, ose krijon një të përkohshme dhe e mban të freskët, ose trafiku nuk e merr kurrë atë rrugë. Pjesa tjetër e artikullit janë këto tre raste me radhë. Asgjë këtu nuk varet nga një veçori e prodhuesit përtej asaj që regjistron tabela.

Çfarë mund dhe çfarë nuk mund të bëjë shërbimi i takimit

Hole punching UDP përdor regjistrimin dalës si një hapje të përkohshme në vend që të mundë filtrin. Të dy partnerët kontaktojnë një shërbim takimi, i cili mëson çdo pikë fundore publike dhe i kthen palës tjetër pikën e saj. Pastaj të dy dërgojnë drejt njëri-tjetrit, dhe çdo paketë dalëse krijon ose rifreskon regjistrimin që lejon përgjigjen të hyjë. Rendi është ai që e bën të funksionojë, dhe rendi është gjithashtu ai që e bën të brishtë: një partner që dërgon përpara se pala tjetër të ketë krijuar regjistrimin e saj thjesht hidhet poshtë, ndërsa një provë e re një çast më vonë ka sukses. Shërbimi vetë nuk mbart trafik VPN, kështu që levë e tij e vetme është kohëzgjatja që koordinon.

Sjellja e hartëzimit vendos pjesën tjetër, dhe RFC 4787 emërton tre format: e pavarur nga pika fundore, e varur nga adresa dhe e varur nga adresa dhe porti. Në të fundit, porti që një partner duhet të synojë ndryshon me çdo destinacion, kështu që parashikimi nuk është më i besueshëm. Aty teknika ndeshet me rrugë pa krye, sepse NAT i nivelit të operatorit dhe një firewall korporativ i rreptë të dy heqin parashikueshmërinë që i duhet skemës, dhe asnjë sasi provash të reja nuk e kthen atë.

Keepalive, ristartime dhe pika fundore që lëviz

Një rrugë e shpuar është një rrjedhë dhe jo një dëgjues, prandaj gjithçka që ecën mbi të duhet t'i mbijetojë ndryshimit. Duhet ta mbajë hartëzimin gjallë me trafik periodik, ta vërë re kur pika fundore publike lëviz dhe të rivendoset pas ristartimit të ruterit ose ricaktimit të adresës. Produktet mesh VPN e vendosin atë logjikë në planin e tyre të kontrollit, ndërsa një server i thjeshtë ta lë ty. Keepalive ndihmojnë vetëm sa kohë mbijeton i njëjti hartëzim, dhe harxhojnë bateri në një klient celular, prandaj një interval agresiv nuk është falas.

Një laptop që fle një orë zakonisht kthehet në një pikë fundore publike tjetër. Gjithçka që rivendos rrugën duhet të ecë përsëri nga brenda, gjë që e kthen të njëjtën kërkesë te klienti.

Tri mënyra për të anashkaluar një përcjellje që mungon

Mënyra e parë i kërkon ruterit ta krijojë vetë hyrjen, përmes UPnP IGD, NAT-PMP ose PCP, kur veçoria ekziston dhe është e ndezur. E dyta ia dorëzon trafikun një releje me adresë publike, e cila funksionon gjithmonë dhe kushton gjithmonë gjerësi bande plus një kufi tjetër besimi. E treta e përmbys drejtimin: hosti i brendshëm hap një tunel dalës drejt një serveri publik dhe gjithçka tjetër udhëton brenda tij.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

Një pikë fundore releje e bën atë shkëmbim të dukshëm në konfigurimin e klientit, ku pika fundore është një rele dhe jo adresa e vetë partnerit. Keepalive i përhershëm e mban hartëzimin të ngrohtë, dhe prefikset e lejuara vendosin çfarë mund të dërgojë klienti përmes tij. Një tunel i kundërt nga hosti i brendshëm është e njëjta ide me një pronar tjetër, dhe nuk kërkon fare ndryshim të NAT. Secili nga të tre e heq kërkesën e hyrjes pa mundur një firewall që bllokon nga dizajni trafikun e pakërkuar, sepse trafiku gjithsesi fillon brenda.

Përshtatni zgjidhjen me atë që zotëron ruterin

Nëse e administroni ruterin, një përcjellje statike UDP është më e lehtë për t'u audituar sesa çdo skemë shpimi dhe dështon në mënyra që i shihni. Nëse jo, zbuloni nëse prodhuesi ofron një rele ose një plan kontrolli të strehuar, dhe nëse politika do ta lejonte përdorimin e tij. Nëse asnjëri nuk është i disponueshëm, zgjedhjet e mbetura janë një tunel i kundërt ose pranimi që pika fundore nuk arrihet nga jashtë. Regjistrimi i asaj që përdorët ka më shumë rëndësi sesa duket, sepse opsionet ndryshojnë në atë se kush mund ta vëzhgojë trafikun dhe çfarë ndodh kur një palë e tretë ndryshon diçka.

Vini re nëse rruga me të cilën përfunduat ishte e drejtpërdrejtë ose përmes një releje, sepse ky fakt i vetëm parashikon si vonesën ashtu edhe sjelljen në dështim. RFC 4787 mbetet referenca për sjelljen e hartëzimit nën gjithçka, dhe leximi i seksionit të tij për hartëzimin është më i shpejtë sesa testimi i tre zgjidhjeve me radhë. Tabelës nuk i intereson cilin opsion zgjodhët; ajo regjistron vetëm çfarë lejohet të bëjë paketa tjetër.