Kial rezultoj de pordoskanado ŝanĝiĝas malantaŭ VPN-eliro?

Rulu la saman pordokontrolon de oficeja linio kaj de VPN-eliro, kaj la du respondoj povas malkonsenti pri adreso, kiun neniu ŝanĝis. Tiu breĉo venas de la vojo kaj de tio, kiu gastiganto respondis, ne de tio, ĉu la servo funkcias. Tri demandoj apartigas tiujn klarigojn: kion la sondilo efektive demandis, kiu gastiganto respondis ĝin, kaj kion via propra servilo registris. Trairu ilin laŭ tiu ordo kaj skribu ĉiun respondon antaŭ ol iri al la sekva.

Riparu la sondilon antaŭ ol kompari du rulojn

Stata vorto estas komparebla kun alia stata vorto nur kiam ambaŭ venis el la sama eksperimento. Kvin kampoj fiksas tion: la fontadreso, kiun vidis la malproksima flanko, la solvita celo, la pordo, la skantipo kaj la tempo. Ŝanĝu iun ajn el ili kaj vi faris duan eksperimenton anstataŭ mezuri la unuan dufoje.

Kontrolu la fonton antaŭ ĉio alia, ĉar VPN-kliento povas esti aktiva dum trafiko ankoraŭ eliras tra la fizika interfaco. Demandu la malproksiman flankon, kion ĝi vidas, poste demandu la kernon, kiun interfacon ĝi elektis:

curl -s https://ifconfig.me
ip route get 203.0.113.20

Du adresoj en malsamaj retoj signifas, ke la klarigo jam estas en la mano, kaj la resto de ĉi tiuj kontroloj nur konfirmos ĝin. Kiam ili kongruas, kaptu la sondilon kun la kaŭzo-flago ŝaltita, por ke la stato revenu ligita al klarigo anstataŭ stari sola kiel nuda vorto. La skantipo ankaŭ apartenas al tiu registro, ĉar ĝi priskribas, kion oni demandis, ne kion oni ricevis. Stato sen fonto, sen metodo kaj sen tempomarko ne povas esti komparata kun io ajn:

nmap -sT -p 443,8443 --reason 203.0.113.20

Konservu tiun eligon apud la registro anstataŭ en ruluma bufro, kiun la sekva persono ne povas vidi. Du honestaj skanadoj, kiuj malkonsentas, estas argumento nur kiam neniu skribis la kondiĉojn. Kun la kondiĉoj fiksitaj, aŭ la rezultoj kongruas kaj la demando estas fermita, aŭ ili diferencas kaj la diferenco estas fakto pri la vojo.

Eltrovu, kiu gastiganto finis la manpremon

Kompletigita manpremo pruvas, ke iu gastiganto kompletigis ĝin, kaj tiu gastiganto ne devas esti la procezo, kiun vi havas en la kapo. Ŝarĝobalancilo, inversa prokurilo aŭ SYN-prokurilo povas respondi antaŭ ol la reala servilo partoprenas, kio estas ordinara dezajno, ne simptomo. Valida atestilo por la atendata nomo ankaŭ ne mallarĝigas tion, ĉar atestilo priskribas servorilaton kaj diras nenion pri tio, kiu maŝino finis la konekton.

La Nmap-referenco pri pordostatoj konsideras tion baza: stato registras, kion sondilo povis observi de kie ĝi estis sendita, ne econ de la pordo. Legu statan vorton tiel kaj du ruloj, kiuj malkonsentis, komencas aspekti konsistaj anstataŭ kontraŭdiraj, dum la demando translokiĝas de ĉu la pordo estas malfermita al kiu staris antaŭ ĝi.

Respondu la duan demandon ĉe la backend anstataŭ de ekstere. Frontend, kiu akceptas konektojn kaj poste ne atingas sian upstream, produktas ĝuste la eksteran bildon de sana servo kun malrapida aplikaĵo. Nur la propra registro de la upstream apartigas la du kazojn:

tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'

La protokola linio montras la klientan adreson, kiun la aplikaĵo vere vidis, kaj la dua komando montras, ĉu la procezo tenanta pordon 443 estas via aplikaĵo aŭ io antaŭ ĝi. Se la du malkonsentas pri tio, kiu adreso konektiĝis, vi rigardas du krurojn de unu peto kaj la bileto devus tion diri.

Kontrolu viajn proprajn regulojn antaŭ ol kulpigi la tunelon

Intenca politiko estas la plej ofta kialo, ke pordo respondas en unu reto kaj ne en alia, kaj ĝi estas la malplej interesa havebla klarigo. Alirreguloj ekzistas por permesi unu fonton kaj forĵeti la reston, do ŝanĝo de eliro estas ĝuste la okazaĵo, por kiu ili estis skribitaj. Tial malsama stato tra VPN ne montras, ke la provizanto inspektas trafikon. Ĝi montras, ke via fontadreso nun estas malsama, kio estas multe pli malgranda aserto.

Tiuj reguloj estas legeblaj sur la servilo, do legu ilin anstataŭ spekuli pri la mezo de la reto. Listigu la filtrajn regulojn, kiuj mencias iun ajn el la du adresaj gamoj, poste kontrolu, ĉu la konekto entute atingis la demonon:

nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113

Malplena dua rezulto estas informa, ĉar nenio atingis la demonon kaj la demando apartenas al filtro, sekureca grupo aŭ la vojo mem. Trafo signifas, ke la servo vidis vian fonton kaj elektis sian respondon, kaj tiu decido kutime estas skribita en regulo, kiun vi povas legi. Neniu el la du rezultoj subtenas rakonton pri la provizanto, kaj ambaŭ estas pli malmultekostaj kontroli ol pakaĵkaptado.

Legu transporton, atestilon kaj respondon aparte

Tri tavoloj produktas tri observojn, kaj sondilo, kiu testas unu el ili, ne povas raporti pri la aliaj du. Tenu ilin kiel apartaj linioj en la registro anstataŭ faldi ilin en unu verdikton, ĉar ĉiu linio malsukcesas laŭ sia maniero kaj la malsukcesa reĝimo diras al vi, kien rigardi poste.

Unu komando produktas la unuajn tri vicojn kontraŭ servo, kiun vi kontrolas. Metu ĝian eligon en la registron apud la skanado anstataŭ en babilan mesaĝon:

curl -v --resolve office.example:443:203.0.113.20 https://office.example/

Legu la eligon laŭvice: la manpremo respondas la transportan demandon, la atestila subjekto respondas la demandon pri la nomo, kaj la responda korpo respondas la demandon pri la aplikaĵo. Kiam la manprema linio sukcesas kaj la responda linio ne, vi havas frontend kun rompita upstream anstataŭ blokita pordo. Tio estas alia bileto ol tiu, kiun vi malfermis, kaj indas diri ĝin klare.

Finu skribante kvar faktojn en la bileton: fontadreso, skantipo, la gastiganto, kiu respondis, kaj la tempo. Ĉio, kion posta komparo bezonas, vivas en tiuj kvar, kaj kiu ajn prenos la kazon sekve ne havos vian terminalan historion. Se vi ne povas plenigi ĉiujn kvar, la rulo ne estas finita.