Vi enlistigis la VPN-adreson kaj ĝi restas blokita? Spuru ĝin

Meti la adreson, kiun montras VPN-aplikaĵo, en la blankan liston malofte riparas blokitan pordon, kaj la paketo klarigas kial. La fajroŝirmilo ne ignoras vian regulon; ĝi taksas fontan adreson, kiun nenio sur la klienta ekrano montras. Ĝis la celo raportos tiun valoron, ĉiu redakto de regulo estas konjekto.

Komencu per la peto, kiu atingas la servon. La tunela adreso, la elira adreso kaj ajna traduko inter ili restas hipotezoj ĝis la celo konfirmas unu el ili.

La adreso en la aplikaĵo ne estas tiu, kiu alvenas

VPN-konekto portas almenaŭ kvar adresojn, kiujn indas nomi aparte: la servila finpunkto, la interna tunela adreso atribuita al via kliento, la loka Wi-Fi aŭ Ethernet-adreso, kaj la publika adreso, kiun retejo vidas post kiam trafiko forlasas la provizanton. Klienta fenestro eble montras nur la duan. Nomu ĉiujn kvar antaŭ ol nomi regulon. Kun dividita tunelado, petoj al publika celo povas tute preterpasi la tunelon, do la malsukcesa seanco ne estas tiu, kiun la uzanto kredas, ke li komencis.

Decidu, kiun el tiuj kvar la regulo celas permesi, poste kontrolu ĝin de la alia flanko. Se la postulo estas vere oficeja adreso, la kondiĉo estas la itinero plus la elira aranĝo de tiu retejo, kaj konekto etikedita Office VPN mem provizas nek unu nek la alian.

Spuru unu peton ĝis ĝia filtrada limo

Konfirmu la celan adreson kaj pordon, kiujn la kliento uzas, poste kontrolu, ĉu tiu celo sekvas la vojon, kiun vi supozas. Publikigita ujuja pordo, inversa prokurilo aŭ pordoadapto povas movi la decidon al gastiganto, kiun vi neniam redaktis. Ĉiu el tiuj saltoj povas porti sian propran politikon. Antaŭe establi la vojon ŝparas al vi korekti regulon, kiun neniu paketo iam atingas.

Sur rajtigita Linux-gastiganto, legu la aktivajn regulojn laŭ ordo antaŭ ol ŝanĝi ilin. Plusenditaj kaj ujujaj servoj ofte saltas en sian propran ĉenon, do inspektu la saltocelon same kiel la finan verdikton.

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

Citu la respondan regulan numeron en la bileto. Sen ĝi la sekva leganto ne povas scii, kiu redakto ŝanĝis la rezulton. Regula numero sen tempostampo ankoraŭ estas ambigua.

Kontrolu la vojon per unu limigita kapto

Unu sendanĝera peto kaj unu mallarĝa kapto solvas la demandon, kiu daŭre revenas. Filtru laŭ la cela pordo kaj la gastiganto esplorata, limigu la pakaĵkvanton kaj haltigu la kapton tuj kiam la peto finiĝos.

tcpdump -ni any 'tcp dst port 9443' -c 20

Komparu tri valorojn flanke unu apud la alia: la fonto en la kapto, la fonto, kiun nomas la responda regulo, kaj la malakcepto, kiun la aplikaĵo registris. Ĉiuj povas malsami, kaj nur la unua klarigas falon deciditan de IP-regulo. Plusendita HTTP-kapo apartenas al la prokurila tavolo, do protokolo, kiu citas tiun kapon, ne priskribas la fonton, kiun la fajroŝirmilo taksis.

Legu la ĉenan ordon, ne nur la regulon

La iptables-referenco dokumentas ordan trairon, kaj tial permeso kuŝanta sub responda fina malakcepto neniam savas la paketon. Pli frue akceptita konekto ankaŭ povas konduti alie ol nova, do malnova sukceso diras nenion pri la nova regulo. Trovu la malakcepton aŭ falon super via permeso antaŭ ol supozi, ke la permeso malĝustas. Po-regulaj nombriloj ankaŭ diras al vi, kiu regulo vidis la paketon.

Forigi regulon por vidi, kio okazas, estas ŝanĝo, ne observado. Legu la nombrilojn, notu la regulan numeron kaj konservu la originalan politikon en la ŝanĝprotokolo. Se testo estas neevitebla, rulu ĝin sur kopio de la ĉeno.

Ŝanĝu la regulon, kiun kontrolas ĝia posedanto

Ĝisdatigu nur la celatan fontan kaj servan politikon, per tiu, kiu posedas ĝin. Komunigita tradukita eliro povas reprezenti multajn uzantojn samtempe, do permesi tiun adreson aŭtentikigas neniun, kaj la aplikaĵaj permesoj malantaŭ ĝi restas tie, kie ili estas.

Kiam la adreso daŭre moviĝas, la daŭra respondo estas stabila eliro aŭ aŭtentikigita kanalo, ne pli longa esceptlisto. Registru la observitan fonton, la celan pordon kaj la regulan numeron.