VPN na LAN ya nyumbani zinatumia subnet moja: fuata njia kwanza

Unaunganisha kwenye VPN ya ofisi, aikoni kwenye treyi inakuwa kijani, intraneti inapakia, na printa iliyo umbali wa mita mbili inaacha kujibu. Sehemu iliyokuwa ikifanya kazi asubuhi inaisha muda kwenye mashine hiyo hiyo, na hakuna logi inayotaja printa. Mwitikio wa kwanza ni DNS, kwa sababu jina lisilotatuliwa linaonekana kama jina lisilokuwepo, lakini tatizo ni anwani: adapta mbili sasa zinadai 192.168.1.0/24 na njia moja pekee inaweza kushinda kiambishi hicho. Ifuate kwa mpangilio huu na utaona adapta ipi ilichukua kabla ya kubadilisha chochote.

Anza na dalili, si na handaki

Dalili ni wigo. Ikiwa intraneti inafanya kazi na kila kifaa cha ndani kinashindwa, handaki ni nzuri na njia ya ndani sivyo. Ikiwa vifaa vya ndani vinafanya kazi na intraneti inashindwa, ni kinyume. Ikiwa kila kitu kinafanya kazi isipokuwa mwenyeji mmoja, unaangalia anwani moja iliyopo pande zote mbili.

Andika anwani moja ya ndani na moja ya mbali kabla ya kugusa mpangilio. “Printa” haiwezi kujaribiwa; 192.168.1.40 inaweza. Hatua hiyo moja inazuia saa inayopotea zaidi kwenye tatizo hili, ambayo ni kuandika upya mipangilio ya DNS kwa ajili ya uamuzi wa uelekezaji.

Hatua 1: ona adapta zote mbili zikidai kiambishi

Fungua Miunganisho ya Mtandao (ncpa.cpl) na usome adapta mbili kando kando. Adapta ya Ethernet inaonyesha 192.168.1.50/24 na lango 192.168.1.1. Adapta ya VPN inaonyesha 192.168.1.201/24, iliyotumwa na seva. Zote mbili ni halali, zote mbili zinaamini kiambishi ni on-link, na staki itahifadhi njia moja kwa ajili yake.

Get-NetIPAddress -AddressFamily IPv4 inaorodhesha anwani, na Get-NetIPInterface | Sort-Object InterfaceMetric inaonyesha mpangilio ambao staki itazitumia. Safu hiyo ya metriki ni uamuzi unaokaribia kuusoma, kwa hiyo andika namba badala ya kujaribu kuzikumbuka.

Kanusha nadharia ya DNS kwa bei ndogo: Resolve-DnsName printer.office.lan inarudisha anwani ile ile ya jana. Jina lilitatuliwa; kisha pakiti likatoka kupitia adapta isiyo sahihi. Dakika mbili hapa zinaokoa mchana kwenye mipangilio ya kitatuzi.

Hatua 2: soma njia iliyoshinda kwa kweli

Find-NetRoute -RemoteIPAddress 192.168.1.40 inachapisha kiolesura, hop inayofuata na chanzo ambacho staki ingetumia kwa anwani hiyo. Chukulia matokeo hayo kama jibu, si kama dokezo. route print -4 inatoa jedwali lote unapotaka kuona kipengele kipi kilishindwa na kwa kiasi gani.

Umaalumu unashinda nia. 192.168.0.0/25 iliyosukumwa inashinda 192.168.0.0/24 ya ndani kwa sababu kiambishi ni kirefu zaidi, kwa hiyo 192.168.0.0 hadi 192.168.0.127 zinatoka kupitia handaki wakati nusu ya juu inabaki ya ndani. Kutoweka kwa nusu ya LAN bila ujumbe wa hitilafu ni tabia sahihi kwa jedwali hilo.

tracert -d 192.168.1.40 inathibitisha hilo kutoka nje ya jedwali: ikiwa hop ya kwanza ni anwani ya handaki badala ya kipanga-njia chako, njia ndiyo hadithi yote. Kwenye Linux swali lile lile ni ip route get 192.168.1.40, inayochapisha anwani ya chanzo na kifaa kwenye mstari mmoja. Jibu linapotaja tun0, acha kuangalia kivinjari.

Hatua 3: angalia njia ya kurudi kabla ya kumlaumu mteja

Njia sahihi ya mbele bado inashindwa ikiwa upande wa mbali hauwezi kujibu. LAN ya mteja inapofikiwa kupitia handaki, lango la LAN hiyo linapaswa kujua bwawa la handaki liko wapi: ip route add 10.8.0.0/24 via 192.168.1.12 kwenye kipanga-njia hicho, na push “route 192.168.1.0 255.255.255.0” kutoka seva ili wateja wajue njia ya kurudi.

Bila kipengele cha kwanza jibu linaondoka lengo kuelekea lango lake chaguo-msingi, ambalo hupeleka anwani ya kibinafsi kwa mtoa huduma na kuiacha. Dalili ni ya upande mmoja na ni rahisi kuisoma vibaya: maombi yanaonekana kwenye tun0, majibu hayana kamwe.

Sheria ya masquerade kwenye mwenyeji wa VPN inaondoa hitaji la njia hiyo tuli: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Pia inaficha anwani halisi za chanzo, jambo linalofanya kila swali la logi baadaye kuwa gumu zaidi. Mwenyeji lengwa mwenye lango chaguo-msingi lisilo sahihi hutoa ukimya huo huo, kwa ICMP redirect katika hali bora na shimo jeusi katika hali ya kawaida, ndiyo sababu kunasa kunahitajika pande zote mbili.

Hatua 4: chagua tengenezo unaloweza kuishi nalo

Kwa hili matengenezo matano hutumika, na hayabadilishani. Chagua kwa kuzingatia kile kinachopaswa kubaki kifikika kwa wakati mmoja, si kwa kuzingatia amri ipi ni fupi zaidi.

Metriki ni chaguo la bei ndogo na lile ambalo watu hukimbilia kwanza. Badiliko linahusu kiolesura, kwa hiyo hufanya kazi wakati handaki iko juu, na mahali pake ni kwenye skripti kando ya mteja badala ya shell utakayosahau. Haiwezi kutoa ufikiaji wa wakati mmoja kwa anwani moja katika mitandao miwili, na kikomo hicho ndicho kinachowapeleka wengine wote chini ya jedwali.

Kuhesabu upya LAN ya nyumbani hadi 10.10.0.0/24 ndiyo suluhisho safi: uhuishaji mmoja wa kukodisha DHCP pamoja na akiba, foleni za printa na anwani zilizoandikwa kwa mkono zinazotaja masafa ya zamani. Kuhesabu upya upande wa ofisi kwa kawaida si uamuzi wako. IPv6 inaondoa mgongano kabisa ikiwa mitandao yote miwili inaunga mkono, kwa kutumia kiambishi cha ndani cha kipekee kutoka fd00::/8 badala ya kitu kinachokumbukika, lakini jaribu programu kwa TCP, si kwa ping, kwa sababu ICMP inaweza kufanya kazi wakati huduma haifanyi.

Chaguo la utafsiri la OpenVPN lenyewe ni njia ya mwisho, linasukumwa kutoka seva hadi ingizo la saraka maalum kwa mteja. Linachukua vigezo vinne baada ya jina la chaguo — mwelekeo, mtandao, netmask na jina la bandia — na jina la bandia si la hiari: push "route 192.168.2.0 255.255.255.0" na push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". Mtandao na netmask ni masafa ambayo mteja anayaona (192.168.2.0/24), jina la bandia ni masafa halisi ya ofisi upande wa seva (192.168.1.0/24), na njia iliyosukumwa ndiyo inayofanya masafa hayo yanayoonekana yafikike. Ofisi kisha inaonekana kwa mteja huyo chini ya 192.168.2.x. Andika ramani kwenye wasifu, vinginevyo mtu anayefuata ataipima kama hitilafu ya uelekezaji.

Kuchapisha huduma moja ni toleo jembamba la utafsiri, na halihitaji chaguo la OpenVPN hata kidogo. Sheria ya DNAT kwenye mwenyeji wa VPN inachapisha upya bandari moja, kwa hiyo LAN inahifadhi anwani zake na kufikia huduma kwenye anwani ya mwenyeji ambayo tayari inaijua. Gharama ni ile ya kawaida: huduma inaona mwenyeji wa VPN kama chanzo, kwa hiyo logi kwa kila mteja na utafutaji wa kinyume hazina maana tena. Hilo linashughulikia foleni moja ya printa au ukurasa mmoja wa utawala, si wenyeji wa pande zote mbili wanaofikiana.

Nini bado hakitafanya kazi, na nini cha kuandika

Matangazo hayavuki handaki lenye uelekezaji. DLNA, UPnP, kuvinjari NetBIOS na Wake-on-LAN zinategemea matangazo au multicast ambayo kifaa cha tun hakibeba, kwa hiyo hakuna njia inayotengeneza ugunduzi. Daraja la dev tap linapanua sehemu, na pamoja nayo matangazo ya DHCP, ARP na kila pakiti nyingine ya ugunduzi; pendelea njia ya mwenyeji ya unicast kama route 192.168.2.1 255.255.255.255 kwa anwani ya upande wa LAN ya kipanga-njia cha mbali.

Vipanga-njia viwili vinavyotumia vyote 192.168.1.1 kwenye njia moja ni wa familia moja ya tatizo: anwani ya ndani hushinda kila mara, kwa hiyo ukurasa wa kipanga-njia cha mbali unabaki haufikiki hadi LAN moja ihame. Kuongeza adapta ya pili hakubadilishi chochote katika hali zote mbili.

Rekodi ushahidi kabla ya kuhariri chochote: ip route get au Find-NetRoute, ping -c 3 kwa anwani husika, traceroute, na tcpdump -ni tun0 icmp kwenye mteja, kisha jedwali la uelekezaji na vihesabu vya NAT kwenye seva. Ping inayofanya kazi upande mmoja na kufa upande mwingine inaelekeza kwenye njia ya kurudi, si handaki, na tofauti hiyo moja inaamua ni tengenezo lipi hapo juu unalohitaji kwa kweli.