Kipanga njia cha LAN na mteja wa VPN: vifaa viwili, majedwali mawili ya njia

Vifaa viwili vinasambaza pakiti na kila kimoja kinashikilia jedwali lake. Kipanga njia cha LAN kinajua kwamba kiambishi cha mbali ni cha mteja wa VPN, na mteja wa VPN anajua jinsi ya kufikia kiambishi hicho kupitia handaki lake. Sanidi jedwali la kwanza pekee na pakiti itafika kwenye mashine isiyo na njia inayolingana, kwa hivyo itatoka tena kwa njia ya chaguo-msingi. Hiyo ndiyo hitilafu yote, na kwa upande wa LAN inaonekana kama kitanzi cha njia, kwa sababu karibu ni hivyo.

Chora hatua mbili kabla ya kugusa njia

Chukua mpangilio wa mfano: watoa-huduma wa LAN kwenye 192.168.50.0/24, kipanga njia cha kawaida kwenye 192.168.50.1, mteja maalum kwenye 192.168.50.15, na LAN ya mbali kwenye 10.60.0.0/24 inayofikika kwa handaki pekee ambalo mteja huyo anashikilia. Hakuna moja ya safu mbili za kibinafsi inayopishana na nyingine, na handaki lina mpango wake wa anwani.

Safu zote mbili za kibinafsi ni muhimu kwa sababu zinaamua kifaa gani kinaweza kujibu. Upande wa mbali utaona pakiti ikija kutoka anwani ya handaki ya mteja, na jibu lake lazima lipate njia ya kurudi 192.168.50.0/24. Ikiwa mwelekeo wa kutoka pekee umesanidiwa, ombi linaweza kufanya kazi wakati jibu linatoweka.

Hatua 1: elekeza kipanga njia kwa mteja, sio kwa handaki

Kwenye kipanga njia cha LAN, ongeza njia ya lengo ambayo hatua yake inayofuata ni anwani ya LAN ya mteja:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Rekodi hiyo inasema “wasilisha kwa mashine inayoweza kufanya handaki”. Haisemi chochote kuhusu jinsi handaki linavyojengwa, na haichukui nafasi ya njia ya mteja mwenyewe. Kwenye kipanga njia kinachosimamiwa, kifanani kinaishi kwenye ukurasa wa njia tuli za kifaa; kwenye kipanga njia cha Linux ni mali ya usanidi wa kiungo kinachomiliki LAN, sio shell utakayofunga.

Angalia jibu la amri ya pili. Ikiwa inaripoti mteja kama gateway na kiungo cha LAN kama device, hatua ya kwanza ni sahihi na kazi iliyobaki iko kwenye mashine nyingine.

Hatua 2: mpe mteja njia yake mwenyewe upande wa handaki

Mteja sasa anapokea pakiti ya 10.60.0.0/24 na anaangalia jedwali lake. Ikiwa usanidi wake wa handaki ulisakinisha njia ya kiambishi hicho, pakiti inaendelea ikiwa imesimbwa. Ikiwa haikusakinisha, pakiti inalingana na chaguo-msingi la kawaida na inarudi 192.168.50.1, ambalo linampeleka tena mteja.

Angalia kabla ya kuongeza kitu:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Kukosekana kwa njia ya kiambishi katika majedwali yote ndiyo ugunduzi unaoutafuta. Ongeza kupitia usanidi wa handaki lenyewe, ili muunganisho unaofuata uisakinishe tena; ip route add ya mkono hutoweka pamoja na kipindi na kurudisha hitilafu wakati usiofaa zaidi. Hatua inayofuata ni kiungo cha handaki au anwani ambayo VPN inagawa kama mwenza wake, kulingana na mteja, na anwani ya mwenza inapaswa kutoka kwenye wasifu wa sasa badala ya noti ya zamani.

Kitanzi, kinapotokea, kwa vitendo hakina mwisho: TTL hupungua kila kupita na pakiti hufa kwa ujumbe wa muda kupita. Ndio sababu traceroute inayorudiwa inaweza kupendekeza mzunguko wakati mteja asiyesambaza hutuacha pakiti hiyo hiyo kimya kimya.

Hatua 3: ruhusu usambazaji na chagua njia ya kurudi

Kupokea na kusambaza ni ruhusa tofauti. net.ipv4.ip_forward=1 kwenye mteja huruhusu upitishaji katika ngazi ya kernel, na sheria ya firewall bado inapaswa kuuruhusu kati ya kiungo cha LAN na handaki. Sheria inayoruhusu ufikiaji wa ukurasa wa usimamizi wa mteja mwenyewe haitaruhusu upitishaji kwa LAN ya mbali, na tofauti hiyo ni rahisi kuikosa wakati mtoa-huduma yuleyule anajibu ping kwa ndani.

Upande wa mbali una tatizo la kioo. Lazima ujue kwamba 192.168.50.0/24 inafikika kupitia mteja huyu aliyethibitishwa. Kwa OpenVPN hii kwa kawaida inamaanisha njia ya kila mteja inayosukumwa na usanidi wa seva, au faili maalum ya mteja kwenye seva inayotangaza LAN iliyo nyuma ya mteja. Bila hiyo, LAN ya mbali ama inatupa jibu au inalipeleka kwa lango lake la chaguo-msingi, yaani intaneti.

Tafsiri ya chanzo ndiyo mbadala wakati kiambishi cha LAN hakiwezi kutangazwa. Sheria ya masquerade yenye upeo kwenye mteja huandika upya chanzo kwa anwani ya handaki, na majibu hurudi kwa njia ya asili. Pia huficha mtoa-huduma yupi wa LAN aliyefanya ombi, na yenyewe hairuhusu upande wa mbali kuanzisha miunganisho kuingia ndani. Chagua maafikiano hayo kwa makusudi badala ya kuongeza masquerade ya jumla na kugundua athari ya pembeni baadaye.

Hatua 4: fanya maamuzi yote mawili ya kudumu, kisha jaribu njia halisi

Kila njia ina mmiliki, na mmiliki ni usanidi unaozalishwa upya wakati wa kuwasha au wa kuunganisha tena. Kwenye kipanga njia inaweza kuwa ingizo la njia tuli; kwenye mteja inaweza kuwa wasifu wa VPN, NetworkManager au systemd-networkd. Thibitisha kwa kuunganisha tena handaki na kuwasha upya mteja, kisha soma jedwali tena badala ya kuamini uhariri.

Weka salama njia ya chaguo-msingi inayobeba muunganisho wa nje wa handaki. Kuibadilisha ili “kurahisisha” usanidi huvunja njia iliyosimbwa kabla trafiki yoyote ya ndani kuweza kuitumia, na dalili ni handaki lisiloweza kuanzishwa tena baada ya mabadiliko.

Jaribu kutoka kwa mtoa-huduma wa kawaida wa LAN, sio kutoka kwa mteja, kwa sababu ombi linalotokea kwenye mteja haliutumii kamwe hatua ya kwanza ya kipanga njia. Lete huduma inayopatikana kwenye LAN ya mbali pekee na uthibitishe mwili wa jibu, kisha angalia vihesabu au kumbukumbu za mteja ili kuona upitishaji ukifanyika. traceroute ya ndani inayoonyesha hatua za kibinafsi inathibitisha usambazaji, sio usimbaji: njia ya nje ni uchunguzi tofauti, na vihesabu vya kiungo cha handaki pekee vinaonyesha kilichotoka ndani yake.