Gateway of geforwardeerde kliënt? Lees die bronadres

Die webbediener teken een adres aan, en almal aanvaar dat dit aan die gateway se eie proses behoort. Dit kan aan 'n geforwardeerde kliënt behoort wie se private adres by die vertaaling verdwyn het. Die bestemming sien die sigbare netwerkbron en niks meer nie. Dit is 'n grensverklaring, nie 'n bewering dat die oorsprong nooit vasgestel kan word nie.

Wat die bestemming werklik sien

Neem 'n kliënt by 10.20.0.7, 'n gateway met buite-adres 198.51.100.10, en 'n bestemming op die internet. As die gateway die kliënt se bron vertaal, teken die bestemming se socket 198.51.100.10 aan. Die private adres is uit die pakket weg, en die bestemming kan dit nie uit daardie pakketkop teruglees nie. Daardie getalle is illustratief, nie 'n opname uit jou netwerk nie.

Die waarneming is steeds nuttig: dit identifiseer die netwerkbron wat die bestemming moet toelaat of blokkeer. Dit identifiseer bloot nie die persoon of die proses agter dit nie. Vir die bestemming se operateur bepaal daardie onderskeid of 'n blokkade 'n netwerkbesluit of 'n rekeningbesluit is.

Vertaaltoestand is nie vir die bestemming sigbaar nie

Die gateway hou die kartering tussen die vertaalde verbinding en die oorspronklike kliënt, en daardie toestand is presies wat die bestemming kort. Die tradisionele NAT-beskrywing skei die vertaalrekord van die koppe wat daarna sigbaar is. Om een kant te lees gee jou nie die ander nie.

Verskillende ontwerpe lewer verskillende bewyse. Gerouteerde verkeer met behoue bronadresse wys die kliënt se werklike adres, terwyl 'n toepassing-proxy die verbinding beëindig en 'n nuwe een skep. 'n Behoue-bron-roete vereis ook dat die kliënt se adres van die bestemming af teruggeroeteer kan word, wat nie elke ontplooiing bied nie. Vra watter ontwerp ontplooi is voordat jy 'n loglyn interpreteer.

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

TTL en vingerafdrukke is leidrade, nie bewys nie

Die TTL van 'n IPv4-pakket hang af van die beginwaarde wat die sender kies en die aantal spronge wat die pakket oorgesteek het. Sonder albei feite kan 'n waarde nie bewys dat 'n VPN-sprong plaasgevind het nie. 'n Bekende ekstra gerouteerde sprong slaag ook nie daarin om 'n LAN-roeteerder, 'n tonnelpad of 'n ander forwarderingsreëling te onderskei nie. Behandel 'n TTL-verskil as 'n vraag, nie 'n gevolgtrekking nie.

Ander seine gedra hulle dieselfde. 'n User-Agent-kop kan deur die toepassing gestel word, en tydsimilariteit kan gedeelde infrastruktuur eerder as 'n gedeelde persoon weerspieël. Verskeie gebruikers kan een uitgang deel, en een gebruiker kan tussen sessies van pad verander. Saam versamel, kan verskeie swak seine 'n nouer kyk na 'n gateway se rekords regverdig, maar hulle word nie sterk bewyse deur op te hoop nie.

Magtig op identiteit, nie op adres nie

As die bestemming gateway-administrasie van afgeleë-gebruikeraktiwiteit moet skei, gee daardie rolle aparte geauthentiseerde identiteite en toegelate bewerkings. 'n Gedeelde openbare bron kan steeds as 'n netwerkbeperking dien, maar dit is geen plaasvervanger vir die verifiëring van die gebruiker of die toestel nie.

Hou die bewyse gemerk: waargenome bron, geauthentiseerde rekening, tydsberekening en die afleiding ter sprake. Moenie geen innerlike bron hier sigbaar nie vertaal in geen toeskrywing elders moontlik nie. Die etiket maak saak wanneer iemand wat nie deel van die ondersoek was nie, die rekord maande later lees.

Teken die datum van die waarneming en die stelsel wat dit opgelewer het, aan. 'n Onverbonde logboek-uittreksel is later moeilik om te verdedig.