Wateja wa VPN wanaunganishwa lakini hawana intaneti: sehemu tatu zinazokosekana

Mteja anapata anwani, seva inajibu ping, na kila ukurasa bado unaisha kwa muda. Watu wengi huanza kuhariri wasifu wa mteja wakati huu, jambo ambalo kwa kawaida ni juhudi bure: pindi tuneli inapoinuka, seva lazima ifanye kama kipanga njia. Masharti matatu lazima yatimizwe kwa wakati mmoja kabla pakiti haijatoka na jibu kurudi, na dalili ni sawa iwe ipi inayokosekana.

Kwa nini tuneli inayofanya kazi bado haina njia ya kutoka

Kiini lazima kipeleke pakiti kati ya violesura, jambo ambalo limezimwa kwa chaguo-msingi katika usambazaji mwingi wa Linux. Trafiki lazima itafsiriwe kwenda anwani ambayo ulimwengu wa nje unaweza kuijibu, isipokuwa kila kipanga njia cha juu tayari kinajua njia ya kurudi kwenye subneti ya tuneli. Njia ya upelekaji ya kinga lazima iruhusu trafiki katika pande zote mbili, ikiwa ni pamoja na majibu.

Kila moja ya haya inaweza kurekebishwa kivyake, na hapo ndipo mtego ulipo. Kuwasha upelekaji bila kanuni ya tafsiri huwaacha pakiti zikitoka na chanzo cha faragha na bila njia ya kurudi. Kuongeza tafsiri bila kanuni ya upelekaji humfanya kiini kutupa pakiti hatua moja baadaye.

Kwa hiyo jaribu tabaka tatu badala ya mteja, na badilisha moja kwa wakati ili matokeo yawe na maana.

Upelekaji ni swichi ya kiini ambayo lazima uifanye ya kudumu

Angalia thamani ya sasa kabla ya kuibadilisha, kisha iweke na uthibitishe kuwa mabadiliko yameanza kutumika.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Amri ya kwanza inaripoti thamani ya sasa, ya pili inaiweka wakati wa utekelezaji, na ya tatu inathibitisha kuwa uandishi ulifanya kazi. Thamani ya wakati wa utekelezaji hupotea kwenye uzinduzi upya unaofuata, ndiyo sababu kikao kinachofanya kazi kinaweza kuvunjika baada ya matengenezo bila mabadiliko yoyote ya usanidi.

Ifanye ya kudumu katika faili chini ya /etc/sysctl.d/, kisha tumia faili hiyo badala ya kuzindua upya ili kujua. Kwenye FreeBSD kifani ni net.inet.ip.forwarding, na kwa udumu gateway_enable=YES katika rc.conf. Kifaa kinachoripoti upelekaji umezimwa kinaeleza tabaka zima la ripoti «pakiti zinafika na hakuna kinachorudi». Angalia mpangilio pia baada ya kila uboreshaji, kwa sababu kiini kilichojengwa upya au taswira ya kifaa iliyobadilishwa inaweza kuiweka upya bila kumwambia mtu yeyote.

Chagua masquerade au anwani moja ya tafsiri isiyobadilika

Ukiwa na anwani ya nje inayobadilika, masquerading ni aina sahihi rahisi zaidi. Taja subneti ya tuneli kama chanzo na kiolesura cha nje kama njia ya kutoka.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Ukiwa na anwani ya umma isiyobadilika, tafsiri ya chanzo kwenda anwani hiyo hasa inatabirika zaidi na ni rahisi kukaguliwa.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Aina ya pili ina mtego wa matengenezo: anwani iliyowekwa kwa nguvu ambayo baadaye inabadilika huiweka tuneli ikifanya kazi wakati ufikiaji wa intaneti unakoma kimya. Ama tumia masquerade au sasisha kanuni kila wakati mtoa huduma anapokuhama. Kiolesura pia ni muhimu, kwa sababu kipanga njia kinachoshiriki tuneli yake ya juu lazima kitafsiri kupitia tuneli hiyo na si kupitia WAN halisi.

Jedwali la vichujio ni lango la tatu

Upelekaji na tafsiri zinaweza kuwa sahihi zote mbili huku pakiti ikifa kwenye jedwali la vichujio. ufw ni mkosaji wa mara kwa mara: sera yake ya upelekaji huja kama DROP, na usanidi mwingine unaweza kuonekana sahihi kabisa huku mpangilio huo mmoja ukizuia trafiki. Kuipandisha ni uamuzi wa usalama wa makusudi na si kisanduku cha kuteua.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Kanuni ya kwanza inaruhusu trafiki mpya kutoka tunelini kwenda nje, na ya pili majibu tu kurudi. Punguza zote mbili hadi subneti ya tuneli na mahali panakokusudiwa, kwa sababu idhini ya jumla kwenye kiolesura cha tuneli hugeuza VPN kuwa sehemu ya kutokea wazi kwa yeyote anayeweza kuthibitisha utambulisho.

Tuneli iliyofungwa kwa daraja inahitaji jibu tofauti. Anwani ni ya daraja, si ya bandari halisi, kwa hiyo kufanya kiolesura kuwa mtumwa huondoa anwani iliyokuwa nayo awali na mwenyeji anaonekana asifikiki hadi daraja lenyewe lipate moja, ambayo dhclient br0 inaweza kutoa. Hitilafu hiyo inaonekana kama tatizo la VPN lakini ni tatizo la tabaka la pili. Angalia anwani ya daraja lenyewe kabla ya kugusa kinga, kwa sababu mabadiliko ya kichujio hayawezi kurekebisha mwenyeji asiye na anwani ya kutuma.

Wapi pa kuangalia wakati ukurasa haupaki kamwe

Ping anwani ya tuneli ya seva ili kuthibitisha kuwa tuneli ipo. Kisha endesha traceroute kutoka kwa mteja hadi anwani ya umma na usome inaposimama: kwenye seva pakiti inafika lakini haipelekwi wala kutafsiriwa; ng'ambo ya seva tatizo liko juu na nje ya mikono yako.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Amri ya kwanza inathibitisha kuwa tuneli inabeba trafiki hadi kwa seva yenyewe, na ya pili inaonyesha pakiti inafika mbali kiasi gani kwenda nje. Alama inayoishia kwenye anwani ya tuneli inaonyesha upelekaji au tafsiri kwenye seva, wakati alama inayosimama hatua moja baadaye inaonyesha mtoa huduma au njia ya kurudi ya kipanga njia cha juu.

Kwenye seva, angalia kiolesura cha nje wakati mteja anapakia ukurasa. Trafiki inayotoka na anwani ya chanzo cha faragha ina maana kwamba tafsiri inakosekana, na kutokuwepo kabisa kwa jibu kuna maana kwamba njia ya upelekaji au njia ya kurudi ya juu inaitupa.

Ikiwa wateja wa mbali wanahitaji pia kufikia wenyeji kwenye LAN ya seva, kumbuka kuwa LAN inahitaji njia ya kurudi hadi subneti ya tuneli. Hii ni uelekezaji na si tafsiri, na ni hatua inayosahaulika mara nyingi zaidi baada ya njia ya intaneti kufanya kazi hatimaye.