Шлюз или препратен клиент? Как да четем адреса на източника

Уеб сървърът записва един адрес и всички предполагат, че той принадлежи на процеса на самия шлюз. Възможно е да принадлежи на препратен клиент, чийто частен адрес е изчезнал при транслацията. Дестинацията вижда видимия мрежов източник и нищо повече. Това е твърдение за граница, а не заявление, че произходът никога не може да бъде установен.

Какво всъщност вижда дестинацията

Вземете клиент на 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 може да бъде зададена от приложението, а сходството по време може да отразява споделена инфраструктура, а не споделен човек. Няколко потребители могат да споделят един изход и един потребител може да сменя пътищата между сесиите. Събрани заедно, няколко слаби сигнала може да оправдаят по-внимателен поглед към записите на шлюза, но те не стават силни доказателства чрез натрупване.

Оторизирайте по идентичност, не по адрес

Ако дестинацията трябва да разделя администрирането на шлюза от дейността на отдалечен потребител, дайте на тези роли отделни удостоверени идентичности и разрешени операции. Споделен публичен източник все още може да служи като мрежово ограничение, но той не замества удостоверяването на потребителя или устройството.

Пазете доказателствата обозначени: наблюдавания източник, удостоверения акаунт, времето и разглеждания извод. Не превеждайте „тук не се вижда вътрешен източник“ като „приписване никъде не е възможно“. Обозначението е важно, когато месеци по-късно записа прочете човек, който не е участвал в разследването.

Запишете датата на наблюдението и системата, която го е създала. Фрагмент от журнал без приписване е труден за защита по-късно.