Из линукс определить внешний ip адрес компьютера.

уже было

Твой внешний айпи, в общем случае, никто кроме этих самых «разных сайтов» и не знает, так что без них не обойтись. Если у тебя разный результат - значит на разные сайты ты ходишь через разные внешние айпи.

внешний ip адрес компьютера

Ну и да, это понятие некорректно. У компьютера есть только свой собственный адрес, в твоём случае он, как я понимаю, внутренний. А внешний адрес - у роутера, прокси-сервера (твой протонвпн тут) или ещё чего-то кто тебе посредник до интернета.

Реальный даже если компьтер за VPN? Есть вариант через WebRTC, но он не всегда работает https://browserleaks.com/webrtc

В общем случае никак.

Опять же смотря что понимать под внешним IP адресом компьютера. Внутренний ‘серый’ IP или внешний, по которому можно определить страну

curl 2ip.ru

На debian установил и настроил web сервер с сайтом. Продали самописный клиент vpn, через 2ip.ru определял внешний ip, на роутере делал нужный форвардинг и сайт открывался через постоянный внешний ip. Теперь этого клиента vpn нет, пытаюсь использовать клиент proton vpn.

как по мне самый удобный: https://icanhazip.com/

ничего лишнего, только ip.

Широкий выбор бесплатных VPN-серверов

https://freevpn4you.net/ru/locations/russia.php

Я не совсем понимаю что ты хочешь, попробую объяснить как это работает с точки зрения веб-сервера, на котором висит сайт который показывает IP коннектящихся к нему клиентов.

Самый простой случай - прямое соединение без прокси и VPN. IP клиента (Client IP) - IP машины, которая установила TCP соединение с вебсервером (назовем его Peer IP). Для получения есть готовые функции во всех языках программирования. Прямое соединение значит все просто, Client IP == Peer IP. Достоверно понять прямое соединение или нет - нельзя, Обычно считают прямым если нет доказательств обратного. А доказательств обратного можно найти кучу, в зависимости от паранойи вебмастера, вплоть до того что сравнивать врмя в браузере с временем в стране которое бьется по GeoIP этого самого IP, или анализировать опять же GeoIP и языки бразера из заголовка accept-language.

Дальше, допустим посредине стоит прокси (один или несколько) и/или клиент лезет через VPN. В общем случае определить Client IP невозможно. Иногда прокси (добровольно) используют HTTP-заголовок x-forwarded-for, в который через запятую (или точку с запятой, забыл уже) записывают IP (Peer IP), с которого шло соединение к самой прокси или иногда даже домен вместо IP, и на сервере этот заголовок можно распарсить и вытащить из него самый первый IP - это и будет реальный IP клиента. Проблема в том, что ВПН и нормальные анонимные прокси этот заголовок не заполняют, и его легко подменить на что угодно на любом из прокси или на самом клиенте, поэтому доверять ему или нет - каждый решает сам.

Дальше. Допустим сайт сконфигурировали работать за Cloudflare. В этом случае Peer IP будет один из IP Cloudflare. Cloudflare при этом добавляет заголовок x-real-ip в котором передает Peer IP с которого шел коннект к Cloudflare (это тоже может быть IP прокси!). Этому заголовку можно доверять, если на вебсервере Peer IP бьется как IP Cloudflare (они публикуют список). x-forwarded-for при этом никуда не девается, его тоже нужно анализировать, Cloudflare ничего не знает о том, как шел запрос до Cloudflare.

Еще бывает так, что перед веб-сервером стоит один или несколько reverse proxy типа nginx, и если их неправильно сконфигурировать - на сервере Peer IP будет пределяться как IP одного из твоих же собственных reverse proxy.

Сами прокси и VPN могут выбирать каждый раз новый маршрут до сервера (хотя обычно так не делают) так что Peer IP может быть каждый раз новый.

Еще есть вариант с утечкой IP через WebRTC, о котором я написал выше. Можно показать клиенту страничку с жаваскриптом и попытаться определить Client IP через этот хак, который пробивает и прокси и некоторые VPN. Но он работает далеко не всегда, не во всех браузерах, ос и не со всеми ВПН.

Чтобы попытаться угадать настоящий Client IP - надо проанализировать все эти заголовки и Peer IP и сделать вывод. Подводных камней при этом достаточно и на каждом шаге можно словить слепо обработанный эксепшн (в x-forwarded-for попалось имя домена или IPv6, код рассчитан что там будет только IPv4, падает, считает что там мусор и игнорирует весь заголовок) или вообще пропустить часть из этих проверок, и соответственно все эти комбинации могут каждый раз возвращать разные Client IP если коннект идет через ВПН или прокси. Разные IP могут быть также просто потому, что Cloudflare каждый запрос может раутить через свои разные исходящие IP, а сервер не определяет заголовок x-real-ip Cloudflare, типа программисты поленились или прописали у себя список IP CLoudflare когда-то давно, а с тех пор у CF добавились новые IP. ВПН точно так же может раутить траф через разные исходящие IP вообще никак не сигнализируя об этом в заголовках.

И каждый вебмастер соответственно сам принимает решение что считать Client IP, потому что достоверно определить это в общем случае нельзя, а тот кто продает такой сервис не предупреждая об этом - врет.

В общем как-то так. Что знал - рассказал.

Если же тебя интересует не течет ли твой IP через ВПН - ну просмотри как можно больше таких сервисов и если хотя бы один определит географию твоего IP, значит или твой ВПН течет или браузер через WebRTC.

Вот еще вспомнил, в копилку, еще есть заголовок via, в котором помимо прочего передается url публичного прокси через который шел траф, а иногда и не передается. Но если этот заголовок есть можно считать что траф шел через прокси, хотя и его можно подменить как x-forwarded-for, только незачем.

И там где у меня выше написано домен следует читать как hostname.