Mteja wa OpenVPN anafikia seva lakini si wenyeji wa LAN: orodha ya ukaguzi

Mteja anasema ameunganishwa, anwani ya handaki inajibu ping, na hakuna kitu kwenye LAN ya ofisi kinachojibu. Ninaona hili baada ya karibu kila sasisho la mteja, na hisia ya kwanza ni kufungua firewall, jambo ambalo kwa kawaida ni hatua isiyo sahihi: handaki iko sawa, na kuvunjika kuko kwenye mojawapo ya hatua tatu ambazo pakiti lazima ipite. Pitia njia kwa mpangilio ambao pakiti inachukua, kwanza njia ya mteja, kisha uwasilishaji wa seva, kisha safari ya kurudi, na utampata mwenye hitilafu ndani ya dakika chache.

Hatua ya kwanza: tazama uamuzi wa uelekezaji wa mteja

Kabla ya kugusa seva, thibitisha kwamba mteja anatuma pakiti ndani ya handaki. Muulize kernel ni kiolesura kipi kingetumia kwa mwenyeji mmoja maalum wa LAN, badala ya kusoma jedwali lote:

ip route get 192.168.50.10

Ikiwa jibu linataja adapta yako ya kimwili na lango la ofisi, hakuna mabadiliko upande wa seva yanayoweza kusaidia. OpenVPN husambaza njia tu wakati seva inazisukuma, kwa hiyo tafuta push "route 192.168.50.0 255.255.255.0" kwenye usanidi wa seva, kisha unganisha mteja tena baada ya hapo. Wateja wengi hutumia njia zilizosukumwa wakati wa kuunganisha, si wakati unapopakia wasifu upya.

Kwenye Windows swali lile lina amri tofauti. Find-NetRoute -RemoteIPAddress 192.168.50.10 huchapisha kiolesura na hatua inayofuata ambayo tabaka lingechagua, na route print -4 huonyesha kama kiambishi kilichosukumwa kipo kabisa.

Hatua ya pili: thibitisha kwamba seva itawasilisha pakiti

Ikiwa njia ya mteja ni sahihi, pakiti inafikia seva na seva lazima ikubali kuiwasilisha. Swichi ya kernel ni lango la kwanza, na sysctl net.ipv4.ip_forward lazima irudishe 1. Kuiweka kwa echo 1 > /proc/sys/net/ipv4/ip_forward hufanya kazi hadi kuwasha upya kunakofuata, na ndiyo sababu malalamiko yale yale hurudi baada ya wiki.

Andika mahali panapostahimili kuwasha upya:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Lango la pili ni jedwali la vichujio. Mwenyeji aliye na Docker imewekwa mara nyingi hubeba sera ya FORWARD ya DROP, na handaki hurithi uamuzi huo. iptables -L FORWARD -v -n huonyesha sera na vihesabu vya pakiti; ikiwa sera ni DROP, uwasilishaji unahitaji idhini dhahiri kwa mwelekeo kutoka handaki kwenda LAN na nyingine kwa jibu.

Hatua ya tatu: fuatilia pakiti hadi LAN na utafute jibu

Tazama pande zote mbili za seva kwa wakati mmoja. Nasa kwenye handaki na kwenye kiolesura cha LAN, ukichuja kwa mteja mmoja na mwenyeji mmoja ili matokeo yabaki yakieleweka:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Maombi yanayotokea kwenye tun0 na tena kwenye eth0 yenye chanzo 10.8.0.x, yakifuatiwa na ukimya, yanamaanisha pakiti ilifika na jibu lilienda mahali pengine. Mwenyeji wa LAN hujibu lango lake chaguo-msingi, lango hilo halina njia ya dimbwi la VPN, na jibu hufa kwenye kipanga njia cha LAN. Kupiga ping kwa mwenyeji wa LAN kutoka seva hakuthibitishi chochote kuhusu njia hii, kwa sababu trafiki hiyo haivuki handaki kamwe.

Hatua ya nne: chagua kati ya tafsiri na njia ya kurudi

Matengenezo mawili hufunga shimo, na chaguo lina athari zaidi ya kama ping inafanya kazi. Tafsiri ya chanzo humfanya seva kuwa mtumaji anayeonekana:

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

Weka kanuni kwa dimbwi na kiolesura cha LAN, kisha ifanye ya kudumu, vinginevyo upakiaji wa firewall unaofuata utaondoa marekebisho yako kwa kimya. Gharama ni utambulisho: kila mteja anaonekana kama seva ya VPN kwenye kumbukumbu za LAN na kanuni za ufikiaji, na per-client policy becomes guesswork.

Njia tuli ya 10.8.0.0/24 kwenye kipanga njia cha LAN, inayoelekea seva ya VPN, huweka anwani za wateja zionekane na ni jibu bora la muda mrefu wakati kipanga njia hicho ni chako. Maeneo mengi huendesha zote mbili kwa muda, NAT kwa marekebisho ya haraka na njia pindi sera ya firewall inapoandikwa. Ikiwa seva ni mwenza wa tovuti-kwa-tovuti na si dimbwi, upande wa seva pia unahitaji iroute kwa subnet ya mbali, vinginevyo njia ya mwenza ipo lakini trafiki ya wateja haiunganishwi nayo kamwe.

Hatua ya tano: thibitisha kutoka kwa mteja na uandike kilichobadilika

Funga mzunguko kutoka kwa mteja, si kutoka kwa seva. Unganisha na huduma halisi kwenye mwenyeji wa LAN, kisha thibitisha kwamba vihesabu vya tafsiri vimesogea kwa iptables -t nat -L POSTROUTING -v -n, kwa sababu kanuni isiyo na pakiti ni kanuni ambayo haikulingana kamwe. conntrack -L -s 10.8.0.5 huonyesha mtiririko na hali yake wakati unahitaji uthibitisho kwamba mwelekeo wa kurudi unafuatiliwa.

Acha kumbuka kwenye usanidi wa seva: subnet ipi, kiolesura kipi, kanuni ipi, na kama kipanga njia cha LAN kina njia ya kurudi. Wakati ujao sasisho la mteja litakapofuta njia iliyosukumwa, kumbuka hilo hubadilisha kikao cha kuzima moto kuwa marekebisho ya mstari mmoja.