Gateway apo klient i përcjellë? Leximi i adresës burimore

Serveri web regjistron një adresë, dhe të gjithë supozojnë se i përket procesit të vetë gateway-t. Ajo mund t'i përkasë një klienti të përcjellë, adresa private e të cilit u zhduk në hapin e përkthimit. Destinacioni sheh burimin e dukshëm të rrjetit dhe asgjë më shumë. Ky është një pohim kufiri, jo pretendimi se origjina nuk mund të përcaktohet kurrë.

Çfarë sheh në të vërtetë destinacioni

Merrni një klient në 10.20.0.7, një gateway me adresë të jashtme 198.51.100.10 dhe një destinacion në internet. Nëse gateway-i përkthen burimin e klientit, socket-i i destinacionit regjistron 198.51.100.10. Adresa private zhduket nga paketa, dhe destinacioni nuk mund ta lexojë më nga ai header. Këto numra janë ilustrues, jo një kapje nga rrjeti juaj.

Vëzhgimi është ende i dobishëm: identifikon burimin e rrjetit që destinacioni duhet të lejojë ose të bllokojë. Thjesht nuk identifikon personin ose procesin pas tij. Për operatorin e destinacionit, ky dallim vendos nëse një bllokim është vendim rrjeti apo vendim llogarie.

Gjendja e përkthimit nuk është e dukshme për destinacionin

Gateway-i mban hartëzimin midis lidhjes së përkthyer dhe klientit origjinal, dhe pikërisht kjo gjendje i mungon destinacionit. përshkrimi tradicional i NAT ndan regjistrin e përkthimit nga header-at e dukshëm më pas. Leximi i njërës anë nuk ju jep tjetrën.

Dizenjimet e ndryshme prodhojnë prova të ndryshme. Trafiku i rrugëtuar me adresa burimore të ruajtura tregon adresën e vërtetë të klientit, ndërsa një proxy aplikacioni përfundon lidhjen dhe krijon një të re. Një rrugë me burim të ruajtur kërkon gjithashtu që adresa e klientit të jetë e rrugëtueshme mbrapsht nga destinacioni, gjë që jo çdo vendosje e ofron. Pyetni cili dizenjim është vendosur përpara se të interpretoni një rresht logu.

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

TTL dhe gjurmët e gishtave janë të dhëna, jo prova

TTL në IPv4 varet nga vlera fillestare e zgjedhur nga dërguesi dhe nga numri i kërcimeve që ka kaluar paketa. Pa të dy faktet, një vlerë nuk mund të provojë se ka ndodhur një kërcim VPN. Një kërcim shtesë i rrugëtuar i njohur gjithashtu nuk arrin të dallojë një router LAN, një shteg tuneli ose një rregullim tjetër përcjelljeje. Trajtoni një ndryshim TTL si pyetje, jo si përfundim.

Sinjalet e tjera sillen njësoj. Një header User-Agent mund të vendoset nga aplikacioni, dhe ngjashmëria e kohës mund të pasqyrojë infrastrukturë të përbashkët dhe jo një person të përbashkët. Disa përdorues mund të ndajnë një dalje, dhe një përdorues mund të ndryshojë shtigjet midis sesioneve. Të mbledhura së bashku, disa sinjale të dobëta mund të justifikojnë një vështrim më nga afër të regjistrave të një gateway, por nuk bëhen prova të forta duke u grumbulluar.

Autorizoni sipas identitetit, jo sipas adresës

Nëse destinacioni duhet të ndajë administrimin e gateway-t nga aktiviteti i përdoruesve në distancë, jepini këtyre roleve identitete të veçanta të vërtetuara dhe operacione të lejuara. Një burim publik i përbashkët mund të shërbejë ende si kufizim rrjeti, por nuk zëvendëson vërtetimin e përdoruesit ose të pajisjes.

Mbani provat të etiketuara: burimi i vëzhguar, llogaria e vërtetuar, koha dhe përfundimi në shqyrtim. Mos përktheni «asnjë burim i brendshëm i dukshëm këtu» si «asnjë atribuim i mundur askund». Etiketa ka rëndësi kur dikush që nuk ishte pjesë e hetimit lexon regjistrin muaj më vonë.

Regjistroni datën e vëzhgimit dhe sistemin që e prodhoi. Një fragment logu pa atribuim është i vështirë për t'u mbrojtur më vonë.