Wateja wa chini nyuma ya VPN ya juu: njia au NAT?

Lango moja linaendesha WireGuard kwa vifaa vyako mwenyewe na mteja wa OpenVPN kuelekea mtandao wa mtu mwingine. Upelekaji kati ya violesura viwili vya ndani unafanya kazi, na ni rahisi kuhitimisha kwamba subnet ya chini sasa ni sehemu ya huduma ya juu. Sivyo. Njia ambayo mteja anavuta inaiambia lango lako wapi kutuma maombi; haisemi chochote kuhusu jinsi mtandao wa mbali unavyorudisha trafiki kwa vifaa ambavyo haujawahi kusikia. Chagua mtindo wa urudishaji ambao upande wa juu unausaidia kweli kabla ya kuongeza kanuni moja.

Amua mtindo wa urudishaji kabla ya kugusa uelekezaji

Katika mwongozo huu, wateja wa chini hutumia 10.90.0.0/24, anwani ya handaki ya juu iliyopewa lango ni 10.80.0.6, na rasilimali ya mbali iliyoidhinishwa ni 172.20.0.30. Mitindo miwili inafaa umbo hilo: kuhifadhi chanzo cha chini na kufanya upande wa mbali uielekeze, au kutafsiri chanzo kwenye anwani ya handaki ya lango lenyewe. Kila kitu baada ya uamuzi huu ni cha kiufundi, na uamuzi wenyewe unahitaji mmiliki wa huduma. Mstari mmoja juu ni makubaliano ya uelekezaji na upande wa mbali; mwingine ni mabadiliko ya sera ya ndani unayoweza kufanya peke yako. Kuchanganya haya mawili ndiko kunakobadilisha mabadiliko ya dakika kumi kuwa majadiliano.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Chagua mstari mmoja na ushikamane nao. Mistari ni njia mbadala, si hatua, na kuichanganya huzalisha muundo ambao hakuna mtu anayeweza kuueleza kwenye ukaguzi.

Uhifadhi wa chanzo kwa njia

Upande wa mbali hupokea ombi kutoka anwani ya chini, kwa hiyo unahitaji njia inayosaidiwa na umiliki wa peer kwa subnet hiyo, pamoja na idhini ya kuikubali. Hizi ni mipangilio ya mbali, na hakuna njia ya Linux ya ndani inayozizalisha. Ziombe kwa uwazi na kwa maandishi, pamoja na kiambishi na peer wa handaki atakayeibeba, na utegemee jibu kutegemea kama huduma inaunga mkono mipango ya tovuti-kwa-tovuti hata kidogo.

Ikiwa jibu ni ndiyo, usanidi wa ndani ni mdogo: upelekaji umewezeshwa, allowed-ips za peer wa WireGuard zinazofunika safu ya chini, na sera ya firewall inayoruhusu kuvuka kwa pande zote mbili.

Tafsiri ya chanzo kwa makusudi

Ikiwa huduma inarudisha trafiki kwenye anwani ya mteja aliyeunganishwa pekee, tafsiri chanzo kwenye anwani hiyo wakati wa kutoka na uhifadhi hali ya conntrack inayoigeuza kwa majibu. Weka kanuni kwa vyanzo vya chini vilivyokusudiwa, maeneo ya mbali yaliyokusudiwa na kiolesura cha juu. Kanuni inayotafsiri kila kitu kinachotoka kwenye kila kiolesura ni sera kubwa zaidi kuliko hitaji hili, na itakushangaza baadaye.

IPv6 inahitaji muundo wake yenyewe; kunakili mstari wa masquerade wa IPv4 si usanifu. Jaribu njia iliyotafsiriwa kwa muunganisho mpya badala ya ule uliohifadhiwa kwenye kashe.

Njia ya data ya ndani bado inapaswa kufanya kazi

Tafsiri haiondoi kazi ya ndani: lango bado linahitaji njia kuelekea maeneo ya chini, umiliki sahihi wa chanzo wa peer wa WireGuard, upelekaji umewezeshwa na sera nyembamba ya firewall kati ya violesura. Ombi linalozalishwa kwenye lango lenyewe halijaribu idhini yoyote kati ya hizo, ndiyo sababu majaribio ya ndani kwenye lango hupita huku vifaa vya chini bado vikishindwa.

Jaribu kutoka kwa kifaa halisi cha chini, si kutoka kwa lango. Anwani ya chanzo ndiyo lengo lote la zoezi hili.

Chanzo kimoja kinamaanisha utambulisho mmoja wa kipindi

Huduma ya mbali inaona kipindi kilichothibitishwa cha lango na anwani yake iliyotafsiriwa, si uthibitishaji huru kwa kila kifaa cha chini. Weka idhini kwa kila kifaa na utambulisho wa programu wazi, na thibitisha na mmiliki wa huduma kwamba lango linalofanya kazi kwa vifaa kadhaa linaruhusiwa hata kidogo. Tafsiri si njia ya kukwepa sharti la usajili kwa kila kifaa; ikiwa huduma inahitaji kila kifaa kujisajili, tumia mtindo huo au jadiliana mpango wa tovuti-kwa-tovuti.

Andika uthibitisho huo kwenye runbook kando ya kanuni, kwa sababu mkaguzi anayefuata atauliza kama muundo uliidhinishwa au ulikuwa wa kurahisisha tu.

Fafanua hali ya kukatika, kisha jaribu maombi matatu

Amua kinachotokea handaki ya juu inapoanguka. Trafiki ya mbali iliyoidhinishwa haipaswi kufuata kimyakimya njia ya akiba ya WAN ya kawaida mahali ambapo ni marufuku, kwa hiyo sera ya firewall inayoruhusu kuvuka inapaswa pia kushindwa ikiwa imefungwa. Kisha jaribu hali tatu kutoka kwa kifaa halisi cha chini: ombi lililoidhinishwa linalofanya kazi, ombi lisiloidhinishwa linaloshindwa, na hitilafu ya juu inayosimamisha lile lililoidhinishwa.

Rekodi urudishaji kwa mstari mmoja kwa kila kanuni, ili mabadiliko yaweze kutenduliwa bila kujenga upya nia.