Kiambishi cha umma kupitia OpenVPN: rekebisha njia ya kurudi

Tazama handaki linapoinuka na mteja akifanya ping upande wa pili, kisha anwani ya umma iliyo nyuma ya VPN inajibu kutoka mahali pengine, au haijibu kabisa. Dalili hii kwa kawaida haina uhusiano wowote na siri au vyeti. Kiambishi kinachopitishwa na mtoa huduma huwasilishwa kama njia ya IP, na kuibeba kupitia OpenVPN kunamaanisha kuzalisha tena njia hiyo kwa ngazi mbili na kuhifadhi anwani ya chanzo kwenye njia ya kurudi. Hakuna haja ya kuunganisha WAN kwa daraja, na kuongeza anwani kwenye kiolesura hakuundi njia ya juu.

Kiambishi lazima kwanza kipitishwe kuelekea kwako

Uliza mtoa huduma jinsi kizuizi kinavyowasilishwa. Kiambishi kilichopitishwa kwenye anwani kuu ya seva yako ni kitu tofauti na anwani ambazo mtoa huduma anatarajia kufikia moja kwa moja kwenye sehemu ya WAN. Mfano wa kwanza pekee ndio unafanya kazi na muundo hapa.

Iwapo mtoa huduma anapitisha 198.51.100.64/28 kwenye seva yako ya kuingia, pakiti za anuwai hiyo hufika kwenye seva na kusimama hapo isipokuwa ukiwasilisha mbele. Iwapo mtoa huduma badala yake anaunganisha anuwai hiyo kwa daraja kwenye uplink yako, seva lazima ijibu ARP kwa ajili yake, ambayo ni tatizo lingine.

Jaribu mfano wa uwasilishaji kabla ya kugusa OpenVPN: kutoka nje, ping anwani ndani ya kizuizi na uone kiolesura kipi kinaipokea. Iwapo hakuna kinachofika, usanidi wowote wa handaki hautasaidia. Iwapo anwani inajibu moja kwa moja kwenye WAN, mtoa huduma anaunganisha kwa daraja badala ya kupitisha, na muundo ulio hapa chini hautumiki.

Ngazi mbili za upitishaji: njia ya kerneli na iroute

OpenVPN inahitaji kiambishi katika sehemu mbili. Kerneli lazima ijue kwamba kiambishi ni cha kifaa cha handaki, ili pakiti zinazowasilishwa mbele ziingie OpenVPN badala ya njia ya kawaida. OpenVPN pia lazima ijue mteja aliyethibitishwa anayemiliki kiambishi, na hiyo ni ingizo la iroute katika saraka maalum ya mteja.

Njia ya upande wa seva inaonekana hivi, na kiambishi na maski lazima vilingane na mgao:

ip route add 198.51.100.64/28 dev tun0

Usanidi maalum wa mteja unagawa umiliki. Weka kwenye faili ya CCD iliyopewa jina la jina la kawaida la cheti cha mteja, na uthibitisha kwamba saraka hiyo ndiyo seva inayosoma kweli:

iroute 198.51.100.64 255.255.255.240

Nyaraka za OpenVPN kuhusu mitandao iliyopitishwa zinaeleza ngazi zote mbili na kwa nini zimetenganishwa. Njia ya kerneli bila iroute hutuma pakiti kwenye handaki bila mmiliki, na OpenVPN huzitupa. iroute bila njia ya kerneli huacha pakiti kwenye njia ya kawaida ya seva. Makosa yote mawili yanaonekana kama handaki lililovunjika kutoka upande wa mteja.

Anwani ya huduma inapoishi

Kiambishi kilichokaimishwa si kitu kimoja na anwani za handaki yenyewe. Nambari kiungo kutoka nafasi ya kibinafsi ikiwa unataka, na weka anwani ya huduma ya umma mahali huduma inafanya kazi kweli.

Kwenye mteja wa Linux anayemaliza huduma ndani, anwani moja ya mwenyeji inatosha:

ip address add 198.51.100.70/32 dev lo

Iwapo kiambishi kinapitishwa mbele kwenye mwenyeji wa VM au LAN nyingine, sanidi njia hiyo ya chini na njia yake ya kurudi badala yake. Kugawa kila anwani ndani ya kizuizi kwa mteja wa VPN hakuhitajiki na huunda migongano baadaye.

Hifadhi chanzo cha umma kwenye njia ya kurudi

Jibu kutoka kiambishi kilichokaimishwa lazima litoke kwenye handaki na lifikie njia ya mtoa huduma. Iwapo mwenyeji wa mbali analituma kupitia ISP yake mwenyewe, anwani ya chanzo inaonekana ya kughushi, na mtoa huduma au lengwa hulitupa. Suluhisho ni kanuni inayotegemea chanzo au jedwali maalum la upitishaji, si NAT pana zaidi. Bila hiyo, huduma inafanya kazi kutoka kwa mwenza wa handaki na inashindwa kutoka kila mahali pengine.

Kwenye seva ya kuingia, kanuni pana ya masquerade ndiye mkosaji wa kawaida. Inaandika upya chanzo cha umma kuwa anwani kuu ya seva, na mteja haoni ile halisi kamwe:

iptables -t nat -S POSTROUTING

Punguza NAT kwa wateja wa kibinafsi wa VPN wanaouhitaji na uache kiambishi kilichokaimishwa bila kutafsiriwa. Kisha uthibitisha kwamba seva inawasilisha mbele kiambishi hata kidogo, kwa sababu mnyororo wa uwasilishaji wenye kukataa kwa kawaida hukitupa kimya kimya.

Thibitisha mwelekeo wote mawili kabla ya kuamini

Uthibitishaji ni uchunguzi nne, si mmoja. Thibitisha kwamba njia ya mtoa huduma inafika, kerneli inatuma kiambishi kwenye handaki, OpenVPN inakihusisha na mteja sahihi, na jibu linarejea na chanzo cha umma kikiwa salama. Uchunguzi wowote una amri yake, kwa hivyo kushindwa kunaonyesha tabaka na si muundo wote. Zifanye kwa mpangilio huo baada ya kila mabadiliko ya usanidi.

Uliza kerneli ni njia gani anwani iliyokaimishwa inachukua, na tazama handaki wakati ombi linaendesha:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Uchujaji wa njia ya kurudi unaweza kubatilisha njia sahihi. Angalia mpangilio unaofaa kwenye handaki na kwenye uplink, na kumbuka kwamba hali kali hukataa trafiki ambayo chanzo chake hakiendani na kiolesura ilichoingia:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Mwishowe, jaribu hali ya kushindwa. Simamisha handaki na uthibitisha kwamba kiambishi cha umma hakivuji kupitia uplink ya kawaida. Kurejesha VPN kunapaswa kurudisha huduma bila kupanua bandari ambazo mwenyeji anafichua.