Шлюз ці перанакіраваны кліент? Як чытаць адрас крыніцы

Вэб-сервер запісвае адзін адрас, і ўсе мяркуюць, што ён належыць працэсу самога шлюза. Ён можа належыць перанакіраванаму кліенту, прыватны адрас якога знік на этапе перакладу. Прызначэнне бачыць бачную сеткавую крыніцу і нічога больш. Гэта сцвярджэнне пра мяжу, а не заява, што паходжанне немагчыма ўстанавіць ніколі.

Што прызначэнне насамрэч бачыць

Вазьміце кліента з адрасам 10.20.0.7, шлюз, знешні адрас якога 198.51.100.10, і прызначэнне ў інтэрнэце. Калі шлюз перакладае крыніцу кліента, сокет прызначэння запісвае 198.51.100.10. Прыватны адрас знікае з пакета, і прызначэнне не можа прачытаць яго назад з гэтага загалоўка. Гэтыя лікі ілюстрацыйныя, а не здымак з вашай сеткі.

Назіранне ўсё яшчэ карыснае: яно вызначае сеткавую крыніцу, якую прызначэнне павінна дазволіць або заблакаваць. Яно проста не вызначае чалавека або працэс за ёй. Для аператара прызначэння гэтае размежаванне вырашае, ці блок — гэта рашэнне па сетцы, ці рашэнне па ўліковым запісе.

Стан перакладу не бачны прызначэнню

Шлюз захоўвае суаднясенне паміж перакладзеным злучэннем і зыходным кліентам, і менавіта гэтага стану прызначэнню не хапае. традыцыйнае апісанне NAT аддзяляе запіс перакладу ад загалоўкаў, бачных пасля. Чытанне аднаго боку не дае вам другога.

Розныя схемы даюць розныя доказы. Маршрутызаваны трафік з захаванымі адрасамі крыніцы паказвае сапраўдны адрас кліента, а праксі прыкладанняў завяршае злучэнне і стварае новае. Маршрут з захаванай крыніцай таксама патрабуе, каб адрас кліента быў маршрутызуемы назад ад прызначэння, чаго не забяспечвае кожнае разгортванне. Спытайце, якая схема разгорнута, перш чым тлумачыць радок журнала.

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

TTL і адбіткі — гэта падказкі, а не доказы

Значэнне TTL у IPv4 залежыць ад пачатковага значэння, абранага адпраўніком, і колькасці пераходаў, якія прайшоў пакет. Без абодвух фактаў значэнне не можа даказаць, што адбыўся пераход праз VPN. Вядомы дадатковы маршрутызаваны пераход таксама не дазваляе адрозніць маршрутызатар LAN, шлях тунеля або іншую схему перанакіравання. Стаўцеся да розніцы TTL як да пытання, а не высновы.

Іншыя сігналы паводзяць сябе гэтак жа. Загаловак User-Agent можа задаць прыкладанне, а падабенства часу можа адлюстроўваць агульную інфраструктуру, а не агульнага чалавека. Некалькі карыстальнікаў могуць дзяліць адзін выхад, і адзін карыстальнік можа змяняць шляхі паміж сесіямі. Сабраныя разам, некалькі слабых сігналаў могуць апраўдаць бліжэйшы погляд на запісы шлюза, але яны не становяцца моцнымі доказамі ад назапашвання.

Аўтарызацыя па ідэнтычнасці, а не па адрасе

Калі прызначэнне павінна аддзяляць адміністраванне шлюза ад актыўнасці аддаленага карыстальніка, дайце гэтым ролям асобныя аўтэнтыфікаваныя ідэнтычнасці і дазволеныя аперацыі. Агульная публічная крыніца ўсё яшчэ можа служыць сеткавым абмежаваннем, але яна не замяняе аўтэнтыфікацыі карыстальніка або прылады.

Трымайце доказы пазначанымі: назіраная крыніца, аўтэнтыфікаваны ўліковы запіс, час і разгляданая выснова. Не перакладайце «тут не бачна ўнутранай крыніцы» як «атрыбуцыя немагчымая нідзе». Пазнака важная, калі праз месяцы запіс чытае чалавек, які не быў часткай расследавання.

Запішыце дату назірання і сістэму, якая яго стварыла. Фрагмент журнала без атрыбуцыі пазней цяжка абараніць.