NAT kwenye seva ya VPN au kwenye router? Zote mbili zinaweza kufanya kazi

Kuweka alama ya muunganisho kama njia chaguo-msingi kwenye kompyuta ndogo ni hatua ambayo kila mtu anaikumbuka, na ndiyo isiyobadilisha chochote kwenye lango. Mteja sasa anatuma maombi ya intaneti ndani ya handaki; ikiwa yatatoka nje ya jengo inategemea upelekaji mbele, sehemu moja ya utafsiri na njia ya kurudi inayofikia anwani ya faragha ya mteja. Mipangilio miwili inaweza kutoa zote tatu, inaweka kazi katika maeneo tofauti, na zote mbili hushindwa kwa njia ile ile ya kimya wakati hakuna anayemiliki mwelekeo wa jibu. Kuchagua kati yao ni swali la nani anapaswa kuona dimbwi la wateja.

Hadithi: njia ya mteja hujenga njia ya kutoka

Uhandakishaji wa kulazimishwa ni sera ya upande wa mteja: inaamua kwamba trafiki iende kwenye adapta ya VPN badala ya ile halisi. Nyaraka za Microsoft kuhusu uelekezaji wa VPN zinaeleza mgawanyiko huo na tabia ya kulazimishwa, na ni tamko kuhusu jedwali la njia la mteja, si kuhusu kanuni za upelekaji mbele za seva. Kwa mtazamo wa mteja handaki ni mahali ambapo intaneti inaishi; kwa mtazamo wa lango pakiti ilifika kutoka anwani ambayo hakuna mtu juu aliyewahi kuisikia. Hakuna upande uliowekwa vibaya peke yake, na ndiyo sababu hitilafu inaonekana kama seva iliyovunjika kwa mtu aliye karibu na kompyuta ndogo.

Tofauti hiyo ni tatizo lote ambalo sehemu iliyobaki ya makala hii inatatua. Kitu lazima kifanye anwani ya faragha ya mteja iweze kurudishwa, na chaguo ni wapi.

Kwanza chora njia ya majibu

Andika njia hiyo kwa anwani halisi kabla ya kugusa mpangilio wowote, na weka alama za sehemu mbili zinazowezekana za utafsiri juu yake. Maabara hii inatumia dimbwi la VPN la 10.70.0.0/24 likiwa na mteja mmoja kwenye 10.70.0.37, anwani ya LAN ya seva 172.16.40.10, router kwenye 172.16.40.1 na njia ya kutoka ya umma 203.0.113.40.

client 10.70.0.37 -- tunnel --> RRAS 172.16.40.10 -- LAN --> router 172.16.40.1 --> 203.0.113.40
                                  (translate here?)                             (or here?)

Seva ambayo tayari inavinjari intaneti inathibitisha njia yake peke yake. Pakiti inayopelekwa mbele kwa niaba ya mteja ni uamuzi tofauti, unaochukuliwa na sera ya upelekaji mbele kwenye mashine hiyo hiyo, na ndiyo kawaida haipo. Kuweka alama za sehemu tatu za uamuzi kwenye mchoro huweka mazungumzo kuhusu moja yao kwa wakati mmoja.

Chaguo A: tafsiri kwenye seva ya VPN

Hapa seva inatafsiri chanzo cha mteja hadi anwani yake ya LAN kabla ya kukabidhi pakiti kwa router, na router inatumia utafsiri wake wa kawaida inapotoka. Kwenye jibu, uchoraji ramani wa router hurejesha anwani ya seva, na uchoraji ramani wa seva hurejesha anwani ya mteja. Utafsiri mbili zenye hali kwa mfululizo ni za kawaida na zinawezekana, mradi zote zimeandikwa; router haitaji kamwe njia ya kufikia dimbwi, na ndiyo mvuto wa mpangilio huu.

Get-RemoteAccess | Select-Object VpnS2SInterface, RoutingDomain
Get-NetNat | Select-Object Name, InternalIPInterfaceAddressPrefix

Tumia usomaji huu kuona kile seva tayari inacho badala ya kudhani kwamba NAT ipo. Kanuni ya masquerade ya Linux iliyonakiliwa kutoka blogi si mpangilio wa Windows, na ruhusa kwenye firewall ya mwenyeji kwa msikilizaji wa VPN si sera sawa na ruhusa ya kupeleka mbele ombi la mteja. Thibitisha jukumu la upelekaji mbele la seva kutoka kwenye uso wake wa usimamizi, kisha angalia utafsiri kwa tofauti, kwa sababu mara nyingi sehemu tofauti za usambazaji huwasha zote mbili.

Chaguo B: hamisha dimbwi hadi kwenye router

Katika mpangilio wa pili seva hupeleka mbele anwani halisi ya chanzo ya mteja, na router inaitafsiri. Hiyo huweka dimbwi la wateja likionekana kwenye ukingo, ambayo husaidia ikiwa router ndiyo mahali sera ya trafiki, ukaguzi wa kumbukumbu au uchunguzi huishi. Inamaanisha pia kwamba router inahitaji njia ya kurudi kwa 10.70.0.0/24 inayoelekea 172.16.40.10, pamoja na sera ya intaneti inayojumuisha kiambishi hicho kwa kweli; kanuni iliyoandikwa kwa subnet ya LAN haienei kimyakimya hadi kwenye dimbwi.

Chagua hili wakati kifaa cha ukingo ndicho mmiliki anayekusudiwa wa sera na kinaweza kukubali kiambishi kingine katika majedwali yake ya uelekezaji na utafsiri. Chagua utafsiri wa upande wa seva wakati dimbwi linapaswa kubaki lisiloonekana juu na router haisimamiwi na timu hiyo hiyo. Hakuna chaguo linalodokezwa na kisanduku chochote cha kuteua kwenye mteja, na hakuna lolote lililo salama zaidi kwa ujumla; zinaweka mwonekano na matengenezo katika maeneo tofauti.

Fanya DNS, IPv6 na upokeaji ziwe wazi

Utafsiri wa anwani hautengenezi utatuzi wa majina. Mteja anaweza kutumia kitatuzi kilichotolewa na profaili ya VPN, kitatuzi cha faragha kwa nafasi za majina mahususi, au kile cha umma kilichoidhinishwa, na kitatuzi kisichoweza kufikiwa chini ya sera hiyo kitaendelea kushindwa baada ya uelekezaji kufanya kazi. Jaribu jina na anwani kwa tofauti ili hitilafu mbili zisiungane kamwe katika ripoti moja.

IPv6 inahitaji aya yake katika muundo. Utafsiri wa IPv4 unaofanya kazi hausemi chochote kuhusu ikiwa wateja wa IPv6 wana njia, chanzo halali cha umma au sera inayowazuia handaki linapoanguka. Kuacha jambo hilo lisitajwe kunamaanisha kwamba nusu ya wateja hupita kimya kimya lango wakati nusu nyingine inafanya kazi.

Kwa upokeaji, fuata ombi moja la mteja lililoruhusiwa na jibu lake katika mipaka yote miwili, na andika anwani ambayo kila mpaka unapaswa kuona wakati huo. Rekodi hiyo ndiyo inayofanya mabadiliko ya dimbwi yajayo kuwa uhariri wa dakika tano badala ya mjadala kuhusu nani anamiliki njia ya kurudi iliyokosekana. Weka rekodi hiyo pamoja na profaili ya mteja badala ya kwenye tiketi, kwa sababu profaili ndiyo kitu ambacho mhandisi ajaye atakikuta kwanza.