VPN konektita sed fajroŝirmilo ankoraŭ blokas: kiel scii kiun

La kliento diras konektita, la rimedo ankoraŭ rifuzas, kaj la kutima sekva paŝo estas malŝalti ion. La du kontroloj en tiu frazo faras malsamajn taskojn: la VPN konstruas vojon por la kovrita trafiko, kaj fajroŝirmilo decidas por ĉiu konekto ĉu la trafiko rajtas pasi. Funkcianta tunelo kun rifuzanta politiko aspektas ekzakte kiel rompita tunelo de la seĝo de la uzanto, do la tasko estas trovi, kiu tavolo respondas. Jen la ordo, kiun mi sekvas, kun la legado, kiu diras al vi halti.

Apartigu la vojon disde la politiko

Komencu per la formo de la malsukceso, ĉar tio estas senpaga informo. Forĵeto de pako produktas tempolimon: la kliento reprovas, nenio revenas, kaj la komando pendas ĝis ĝi rezignas. Rifuzo produktas malakcepton aŭ restarigon: io respondis kaj diris ne. Servo, kiu ne aŭskultas, rifuzas sur la gastiganto mem, tute sen fajroŝirmilo.

Tiuj tri rezultoj montras al malsamaj tavoloj. Tempolimo signifas, ke ie politiko silente forĵetas, aŭ ke la vojo neniam forlasas la maŝinon. Rifuzite signifas, ke vi atingis la gastiganton kaj ĝia stako aŭ ĝia loka fajroŝirmilo rifuzis. Tute neniom, kun la tunela interfaco aktiva kaj sen vojo al la celo, signifas, ke la vojo malĝustas kaj neniu fajroŝirmila regulo tion riparos.

Legu la vojon en unu paŝo

Konfirmu, ke la tunelo kovras la celon antaŭ ol rigardi eĉ unu regulon. Dividita tunelo, kiu portas nur la oficejan subreton, ne enkursigos peton al alia gamo, kaj la malsukceso tiam aspektas kiel fajroŝirmila blokado, kiu ĝi ne estas:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

La eligo de la vojo nomas la interfacon, per kiu la pako foriros, kaj la fontan adreson, kiun ĝi portos. Se tiu interfaco estas via fizika retkarto kaj ne la tunelo, la problemo estas en enkursigo aŭ en la permesitaj gamoj de la tunelo, kaj ĝi apartenas al la VPN-agordo kaj ne al la fajroŝirmilo.

Unu kaptilo specifa al VPN meritas propran kontrolon. En WireGuard, AllowedIPs de paro estas samtempe vojo kaj kriptografia filtrilo: pako, kies fonta adreso ne kongruas kun la permesita aro de la paro, estas forĵetita antaŭ ol iu ajn fajroŝirmila regulo estas konsultita. Do tute ĝusta gastiganta fajroŝirmilo povas stari malantaŭ silenta forĵeto, kiu aspektas kiel politiko, kaj la korekto estas agorda linio por la ŝlosilo, ne regulo.

Legu la politikon ĉe la tavolo, kiu respondas

Kiam la vojo ĝustas, trairu la politikon de la gastiganto eksteren kaj atentu la solan tavolon, kies nombriloj moviĝas:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

La aŭskultanta ingo respondas al alia demando ol la reguloj. Se nenio aŭskultas ĉe la pordo, la kerno rifuzas la konekton kaj neniu envena regulo gravas. Se la ingo ekzistas kaj la konekto de fora kliento tempolimiĝas, forĵeto okazas ie sur la vojo, kaj la nombriloj de la reguloj diras al vi ĉu ĝi okazas ĉi tie.

Ŝaltu protokoladon por la profilo aŭ ĉeno, kiun vi suspektas, anstataŭ diveni de ekstere. Unu protokolita forĵeto, kiu nomas fonton, celon kaj pordon, identigas la tavolon kaj la regulon, kaj ĝi ankaŭ pruvas, ke la pako alvenis, kion neniu testado ĉe la klienta flanko povas konstati.

Legu la decidon de la enirejo, kiam la tunelo finiĝas tie

Ĉe reteja aŭ fora-aliro enirejo, la VPN aŭtentikigas uzanton kaj la politiko rajtigas rimedon, kaj tiuj estas apartaj permesoj. Uzanto enlasita en la tunelon ne aŭtomate rajtas al ĉiu interna gastiganto, kaj la rifuzo ofte venas de enkursiga regulo dum la tunelo mem estas sana. La sama apartigo aperas en IPsec, kie la sekureca politiko, kiu elektas trafikon, diferencas de la filtrilo, kiu enlasas ĝin, kaj tial ambaŭ estas dokumentitaj kiel malsamaj mekanismoj en RFC 4301.

Kontrolu la revenan vojon same zorgeme kiel la eliran. Stata filtrado devas vidi la respondon, do malsimetria enkursigo tra la tunelo en unu direkto kaj ĉirkaŭ ĝi en la alia produktas forĵetojn, kiuj aspektas hazardaj kaj reproduktiĝas nur ĉe iuj klientoj. Se la trafiko atingas la enirejon kaj haltas, legu la enkursigan regulon kaj la revenan vojon kune antaŭ ol larĝigi ion ajn.

La enirejo ankaŭ estas la loko, kie regulo pri NAT aŭ maskado povas kaŝi la veran fonton. Se internaj gastigantoj vidas la adreson de la enirejo anstataŭ tiun de la kliento, iliaj gastigantaj fajroŝirmilaj reguloj, kiuj devas kongrui kun la klienta baseno, neniam kongruos, kaj la korekto apartenas al la enirejo, ne al ĉiu servilo.

Ŝanĝu la plej mallarĝan tavolon, poste kontrolu

Rezistu la ampleksan riparon. Malŝalti la gastigantan fajroŝirmilon, aldoni regulon, kiu permesas ĉion, aŭ devigi ĉiun interfacon en fidindan profilon forigas ĉiufoje la kontrolon, kiu faris sian laboron, kaj la ŝanĝo postvivas la incidenton. Regulo limigita al la fonta gamo kaj la koncerna pordo estas pli facile revidebla, pli facile forigebla, kaj lasas la reston de la maŝina politiko sendifekta.

Kontrolu per la sama testo, kiu malsukcesis, de la sama kliento, kaj poste ankoraŭfoje post rekonekto, ĉar regulo, kiu kongruas antaŭ ol la tunelo denove intertraktas, povas ĉesi kongrui poste:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Antaŭ ol vi fermos ĝin:

• La vojo al la celo foriras per la tunela interfaco, kaj la fonta adreso kongruas kun tio, kion la politiko atendas.
• Io aŭskultas ĉe la pordo, kaj la rifuzo aŭ tempolimo estas atribuata al nomita regulo anstataŭ supozata.
• La enirejo plusendas en ambaŭ direktoj, kaj la celo vidas la fonton, por kiu viaj reguloj estis skribitaj.
• Neniu kontrolo estis malŝaltita por ke la testo pasu, kaj la ŝanĝo, kiun vi faris, nomas unu fontan gamon kaj unu pordon.