Wateja wa VPN wanafika kwenye seva lakini si kwenye LAN: suluhisho gani?

Mteja anapiga ping kwa anwani ya mfereji wa seva ya OpenVPN na kupata jibu, kisha anajaribu mwenyeji katika LAN ya seva na hapati kitu. Mgawanyo huu unapunguza hitilafu sana: mfereji uko juu, upelekaji unawezekana unafanya kazi, na jibu linatoka kwa mlango usiorudi. Kuna suluhisho tatu, na sahihi inategemea unachodhibiti na kile ulicho tayari kuachia. Jibu maswali matatu hapa chini kwa mpangilio na uchaguzi hautakuwa suala la ladha tena.

Kwanza thibitisha ni upande gani umevunjika

Ombi linafika kwenye kiolesura cha mfereji na anwani ya chanzo kutoka dimbwi la VPN. Seva inalipeleka kwa mwenyeji katika LAN, na mwenyeji huyo anajibu lango linalotajwa na jedwali lake mwenyewe, kwa kawaida kipanga njia cha LAN. Ikiwa kipanga njia hakina njia kuelekea dimbwi, jibu linakufa hapo au linazurura kuelekea mtandao.

Jaribu mashine zote mbili kabla ya kubadilisha yoyote. Uliza jedwali la njia kwenye seva litafikaje kwa mteja; uliza mwenyeji katika LAN atafikaje kwenye anwani hiyo hiyo. Utafutaji wa kwanza kwa kawaida huelekeza kwenye mfereji na wa pili kwenye kipanga njia cha LAN, na tofauti hiyo ni hitilafu katika mstari mmoja. Utafutaji mbili ni nafuu kuliko ukaguzi wa ngome na huamua mwelekeo wa tatizo.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Ikiwa mwenyeji katika LAN tayari anaelekeza kwenye seva ya VPN, tatizo lako ni kanuni ya ngome au kikomo cha MTU, si njia ya kurudi iliyokosekana. Usiongeze njia kurekebisha chujio.

Swali la kwanza: unaweza kuhariri kipanga njia cha LAN ya mbali?

Wakati kipanga njia cha LAN ni chako, jibu safi ni njia tuli kuelekea dimbwi la VPN ikiwa na anwani ya LAN ya seva ya VPN kama hatua inayofuata. Inahifadhi anwani za chanzo za wateja bila kuharibika, jambo muhimu wakati wenyeji wa LAN wanarekodi, wanachuja au wanapunguza kasi kwa anwani. Pia haihitaji tafsiri kwenye seva, kwa hivyo mfereji unabaki njia safi ya upelekaji. Wajibu unaouleta ni nyaraka, kwa sababu dimbwi, njia na usanidi wa seva lazima zilingane.

Inashindwa kimyakimya siku ambayo mtu anabadilisha dimbwi. Andika thamani mara moja na chukulia mabadiliko katika mojawapo ya maeneo matatu kama mabadiliko katika yote matatu.

NAS au swichi ya tabaka la Layer 3 inayohifadhi huduma inahitaji njia hiyo hiyo, isipokuwa inatuma kila kitu kupitia kipanga njia kilicho nayo. Kagua kifaa kinachomaliza subneti, si kile kinachoelekea mtandao pekee. Mitandao midogo mara nyingi huwa na vifaa vitatu vyenye maoni kuhusu upelekaji njia.

Swali la pili: LAN inaweza kuacha kuona anwani za wateja?

Wakati kipanga njia ni cha mtu mwingine, tafsiri kwenye seva ya VPN haiitaji ushirikiano. Mwenyeji katika LAN anaona anwani ya LAN ya seva, anajibu kwake, na seva inatafsiri kurudi. Ndiyo sababu vifaa na majukumu ya ufikiaji wa mbali yanayotegemea NAT hufanya hivyo.

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

Gharama ni uhusishaji: anwani kwa kila mteja zinapotea kutoka kumbukumbu za LAN. Orodha yoyote ya ruhusa kwenye mwenyeji katika LAN basi lazima itaje seva badala ya dimbwi.

Chagua tafsiri wakati ushirikiano haupatikani, si wakati unatatiza tu. Inamficha mteja kutoka kila uchunguzi wa baadaye, ikiwa ni pamoja na ule unaohitaji kujua ni kompyuta ndogo ipi ilifungua muunganisho. Inaweza pia kuvunja itifaki zinazoweka anwani kwenye mzigo, kwa sababu tafsiri inaishi kwenye kichwa. Hakuna chaguo lililo juu zaidi; zote mbili zinajibu maswali tofauti kuhusu umiliki.

Swali la tatu: seva yenyewe ni mteja wa mfereji mwingine?

Fikiria topolojia nyingine: seva ya VPN pia hupiga simu kwa mtoa huduma wa kibiashara, kwa hivyo ina mifereji miwili na seti mbili za anwani. Trafiki inayoipeleka kwa wateja wake inatoka kupitia mtoa huduma, na huyo hataelekeza majibu kurudi kwenye anwani za dimbwi. Ndiyo sababu majibu hupotea ingawa mifereji yote miwili ni nzuri.

Suluhisho ni kuficha pia mfereji wa kutoka, ili mtoa huduma aone tu anwani ya mfereji wa seva. Upande kinyume unahitaji kanuni yake, kwa sababu seva inayoanzisha muunganisho kwa mmoja wa wateja wake ni mtiririko tofauti. Bila kanuni hiyo mteja anajibu anwani ambayo hawezi kuielekeza. Weka kanuni nyembamba kabla ya ufichaji wowote mpana ili tafsiri mahususi ishinde.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Wenyeji wenye violesura vingi huongeza hitilafu inayohusiana inayoonekana sawa kutoka kwa mteja. Jibu linatoka kupitia kiolesura chenye kipimo cha chini kwa sababu anwani ya chanzo ilichaguliwa kutoka jedwali lingine. Kagua njia ya kurudi kwa utafutaji badala ya kudhani njia ya kwenda inaihusisha.

Kisha thibitisha pande zote mbili na ukubwa wote mbili

Baada ya mabadiliko, piga ping kutoka kwa mteja hadi kwa mwenyeji katika LAN na kisha kutoka kwa mwenyeji katika LAN hadi kwa mteja. Upande wa pili ndio watu wanauacha, na ndio unaofichua kanuni ya tafsiri isiyokamilika. Rekodi matokeo yote mawili na muhuri wa muda ili kurudi nyuma baadaye kulinganishe.

Kisha hamisha data halisi, kwa sababu ping ndogo inayofaulu wakati uhamishaji mkubwa umekwama ni dalili ya MTU. Hitilafu hiyo inaonekana mara moja baada ya kujipongeza kwa kurekebisha njia.

Mwisho, jaribu tena baada ya kuwasha upya. Amri za njia na ngome za wakati wa utekelezaji hazipiti hilo, na marekebisho yanayotoweka kwenye uanzishaji unaofuata yatagunduliwa tena na mtu mwenye muktadha mdogo. Fanya mabadiliko ya kudumu kwa njia ambayo mfumo wako tayari hufanya, kisha washa upya mara moja kwa makusudi.