Umeunganishwa na OpenVPN lakini hakuna kinachopakiwa: safari kutoka kwa mteja kwenda nje
Tunnel iko juu na kivinjari bado kinazunguka. Toka kwa mteja kwenda nje: vikamatizo viwili, swichi moja ya kernel, kiolesura halisi cha kutoka, kisha DNS.
Dirisha la mteja linasema Connected, anwani ya tunnel ipo, na kivinjari bado kinazunguka. Mchanganyiko huo ni wa kawaida, kwa sababu kusalimiana kwa mafanikio kunathibitisha tu kwamba tunnel ilijengwa; haisemi kama seva itapeleka pakiti zako mbele, itaandika upya chanzo chao, au itajibu maswali yako ya DNS. Kosa ambalo wengi hufanya ni kufungua usanidi wa seva kwanza. Badala yake fanya kazi kutoka kwa mteja kwenda nje, kwa sababu kila hatua hapa chini inasema kama inayofuata inafaa kuangaliwa.
Anza kwa mteja na uende nje
Fanya majaribio matatu kwa mpangilio huu na uandike wapi la kwanza linashindwa. Pinga anwani ya tunnel ya seva, ambayo inathibitisha kwamba tunnel yenyewe inabeba trafiki. Pinga anwani ya umma kwa namba, ambayo inathibitisha upelekaji na utafsiri bila kuhusisha utatuzi wa majina. Kisha jaribu kutatua jina la mwenyeji, ambayo ni jaribio pekee linalotumia DNS. Kila matokeo huondoa tabaka zima kutoka kwa mashaka.
Usiruke kwenda jaribio la tatu kwa sababu kivinjari kinaonekana kikiwa na kasi zaidi. Upakiaji wa ukurasa ulioshindwa hufunika matabaka yote matatu kwa mara moja, na hapo ndipo watu huanza kisha kujenga upya tunnel iliyokuwa ikifanya kazi. Ukurasa unaoshindwa hausemi ni tabaka gani kati ya matatu lilivunjika.
Vikamatizo viwili vinaonyesha wapi pakiti zinasimama
Wakati ping kwa anwani ya umma inaenda kutoka kwa mteja, chukua kikamatizo kimoja kwenye kiolesura cha tunnel na kingine kwenye kiungo cha juu kinachopaswa kufikia intaneti. Endesha vyote kwa wakati mmoja ili alama za muda zioane.
sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp
Ikiwa maombi yanaonekana kwenye tunnel na kamwe hayanaonekani kwenye kiungo cha juu, seva iliyaangusha kati ya tunnel na waya, na sababu ni upelekaji au sera ya ukuta wa moto ya upelekaji, si NAT. Ikiwa yanaonekana kwenye vyote viwili, seva ilifanya sehemu yake na jibu linakosekana mbali zaidi, jambo linaloelekeza kwa utafsiri, kichujio cha juu au kizuizi kutoka kwa mtoa huduma.
Chukua jina la kiungo cha juu kutoka kwa jedwali la uelekezaji, si kutoka kwa mafunzo. Picha za wingu na adapta zilizobadilishwa jina mara chache huoana na kiolesura cha mfano kwenye mwongozo, na kikamatizo kilichochukuliwa kwenye kifaa kisichofaa kinaonekana kama seva isiyopeleka:
ip -4 route get 9.9.9.9
Sehemu ya dev kwenye matokeo hayo ni jina ambalo kanuni ya NAT itahitaji baadaye, kwa hiyo ihifadhi.
Upelekaji ni swichi ya kernel na sera ya ukuta wa moto
Kernel inapaswa kukubali kupeleka kabisa. Soma thamani ya sasa, kisha fanya mpangilio uwe wa kudumu badala ya kuandika kwenye kernel inayoendesha pekee:
sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system
Upelekaji ni nusu tu. Kwenye mwenyeji anayetumia UFW sera ya upelekaji huwekwa katika /etc/default/ufw na lazima iwe ACCEPT kabla upakiaji upya haujaanza kutumika. Uangushaji wa chaguo-msingi kwenye njia ya upelekaji huacha kusalimiana kukiwa chema kabisa huku ukiondoa kwa kimya kila pakiti inayojaribu kutoka kupitia tunnel, na hiyo ndiyo dalili uliyoanza nayo.
Wenyeji wanaosimamia nftables moja kwa moja wana swali lile lile kwa sintaksia nyingine. Angalia vihesabu kwenye mnyororo wa upelekaji wakati jaribio la mteja likiendelea, kwa sababu mnyororo unaoulizwa na mnyororo unaoangusha huonekana sawa katika faili ya usanidi.
Taja kiolesura halisi cha kutoka kwenye kanuni ya NAT
Utafsiri wa chanzo unapaswa kuwa kwenye kiolesura kinachoondoka kwenye mwenyeji kweli, pamoja na bwawa ambalo seva hugawanya. Nusu zote mbili za kanuni hiyo lazima zieleze ukweli, na hakuna hata moja ni ya hiari.
iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE
Kushindwa kwa kawaida ni kanuni iliyonakiliwa kutoka mwongozo inayosema -o eth0 kwenye mashine ambayo adapta yake inaitwa jina lingine. Kanuni hiyo inasakinishwa bila tahadhari, haioani na kitu, na mteja bado hana intaneti. Bwawa ni nusu nyingine ya kosa lile lile: ikiwa seva inagawa 10.44.0.0/24 na kanuni inashughulikia 10.8.0.0/24, hakuna kitu kitakachooana kamwe.
Angalia vihesabu badala ya kuamini maandishi ya kanuni. Orodha huripoti pakiti kwa kila kanuni, na kanuni isiyooana kamwe hubaki sifuri jinsi inavyoonekana sawa. Ipe dakika moja ya trafiki halisi ya mteja kabla ya kusoma chochote kwenye namba hiyo:
iptables -t nat -L POSTROUTING -v -n
Hesabu ya pakiti sifuri baada ya jaribio halisi la mteja inamaanisha ulinganifu ni mbaya, si kwamba tunnel imevunjika. Mara inapooana, hifadhi seti ya kanuni ili idumu baada ya kuwasha upya; marekebisho yanayoishi katika historia ya shell yako pekee hupotea kwenye kuwasha upya kwa kwanza.
Ikiwa seva pia ni mfano wa NAT wa wingu, jukwaa pia lina sauti. Mfano unaotafsiri anwani kwa kawaida unahitaji ukaguzi wa chanzo na lengwa umezimwa pale mtoa huduma anapotoa mpangilio huo, na bandari ya VPN yenyewe lazima ifikike kutoka nje.
DNS ni kushindwa kwa pili nyuma ya kwa kwanza
Ping kwa anwani inayofanya kazi wakati majina yanashindwa ni tatizo la kitatuzi, na lina sababu yake. Mteja anayebakiza kitatuzi chake cha ndani hutuma maombi hayo ndani ya tunnel kamili na kusubiri jibu ambalo haliji kamwe, kwa sababu kitatuzi cha ndani sasa kiko upande usiofaa wa njia.
Sukuma kitatuzi kutoka kwa seva ili mteja ajue wapi pa kuuliza. Maingizo mawili humpa mteja mbadala ikiwa la kwanza halifikiki, na yote mawili yanapaswa kuwa vitatuzi ambavyo tunnel inaruhusu kweli.
push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"
Wateja wa Windows wanaweza kisha kurudi kwa kitatuzi cha ndani hata hivyo, na ndiyo hasa block-outside-dns ipo kuzuia, kwa gharama ya kupoteza majina ambayo ni mtandao wa ndani pekee unaoweza kuyatatua. Wateja wa Linux wanaotumia systemd-resolved mara nyingi hupuuza kitatuzi kilichosukumwa isipokuwa skripti iisakinishe, kwa hiyo angalia resolvectl status kwa kifaa cha tunnel kabla ya kuhitimisha kwamba usukumi ulipuuzwa.
Maliza safari kama mtumiaji anavyoisikia. Pakia ukurasa halisi kutoka kwa mteja, thibitisha anwani inayotoka nayo, washa upya seva, unganisha tena na urudie majaribio matatu. Mzunguko huo wa pili pekee unathibitisha kwamba kanuni zilizohifadhiwa, sera ya ukuta wa moto na kitatuzi kilichosukumwa vyote viliokoka pamoja.