Недавно я изменил модель своего виртуального сервера на Hetzner. У нового есть внешний IPv4-адрес, по которому он доступен из Интернета (как и должно быть). Но я не могу использовать этот внешний IP в конфигурации: iptables правила не действуют, openvpn сервер не может привязать слушателя к любому порту, используя этот IP-адрес и т. д. Я нашел «локальный» IP-адрес (172.31.x.x) в ifconfig вывод, и если я использую его в конфигурации, все работает как шарм.
На моем старом сервере я мог использовать его где угодно. Поэтому мне просто интересно: почему внешний IP-адрес может не работать для моего нового сервера? ОС есть Ubuntu 15.04
Hetzner прекратил назначать публичные IPv4-адреса виртуальным серверам. Насколько я могу судить, это изменение произошло, когда они изменили название продукта с VQ на CX. Однако использование NAT не упоминается в описании продукта.
В конце концов Hetzner представила новую облачную платформу, в которой виртуальные машины получают реальные общедоступные IPv4-адреса и маршрутизируемый префикс IPv6 / 64. Обе версии разделяют имя CX.
Виртуальные серверы, заказанные в 2012 и 2013 годах, сохранят свой общедоступный IPv4-адрес до 2019 года, когда линия VQ будет прекращена. Но виртуальные серверы, заказанные в 2016 году, имеют только адрес RFC1918, и Hetzner не будет направлять общедоступный IPv4-адрес на такой виртуальный сервер.
Они по-прежнему выделяли выделенный общедоступный IPv4-адрес каждому виртуальному серверу, который они преобразовывали в назначенный адрес RFC1918. Хетцнер считал, что это не проблема, потому что это был NAT 1: 1.
Как вы выяснили, это подвержено ошибкам при настройке сервера. Вы должны знать об этом NAT. И вам нужно искать сопоставление всякий раз, когда вы что-то настраиваете. Для первого виртуального сервера, который мы получили в такой конфигурации, он дважды неправильно настраивался за первые пару дней из-за этого.
Любое программное обеспечение, которое полагается на знание общедоступного IPv4-адреса, либо сломается, либо потребует специальной настройки. Кроме того, некоторые VPN и IP-туннели могут иметь проблемы, потому что туннелированные пакеты не будут преобразованы в NAT.
Если вы установили, что эти потенциальные проблемы не влияют на ваше предполагаемое использование, и если вам удобно принимать во внимание сопоставление между общедоступными и частными адресами при внесении изменений в конфигурацию, вы можете принять ситуацию.
Однако имейте в виду, что большинство реализаций NAT поддерживают состояние. Если NAT действительно сохраняет состояние, вы можете столкнуться с остановкой TCP-соединений при потере состояния.
Я не знаю, является ли NAT, используемый Hetzner, с отслеживанием состояния или без него. Самый очевидный способ, который я мог придумать для тестирования состояния, - это установить туннельное соединение и отключить туннель после установления TCP-соединения. Увы, именно такое туннелирование не сработает, поэтому для проведения этого эксперимента необходимо сначала реплицировать их конфигурацию 1: 1 NAT. Я не делал этого довольно сложного эксперимента.
У вас есть следующие варианты:
Поскольку вы арендуете жилье у Hetzner, я предполагаю, что вы говорите по-немецки, поэтому вот ответ прямо от Вики поддержки Hetzner:
Warum hat meine VM die IP 172.31.1.100?
oder auch:
Warum hat meine VM eine andere IP als im Robot angegeben?
Warum hat meine VM eine private IP?
Bei den CX Modellen ist die IPv4-Adresse im vServer eine private IP, die 1: 1 per NAT auf deffentliche IPv4 Adresse umgesetzt wird. Aktuell ist die private IP bei allen gleich: 172.31.1.100. Открытые IP-адреса в Hetzner Robot angezeigt.
Почему у моей виртуальной машины IP 172.31.1.100?
Или также:
Почему у моей виртуальной машины IP-адрес отличается от того, который показан в роботе?
Почему у моей виртуальной машины частный IP-адрес?
В моделях CX IPv4-адрес виртуального сервера является частным IP-адресом, который настроен 1: 1 через NAT на общедоступном IP-адресе. В настоящее время частный IP-адрес для всех одинаков: 172.31.1.100. Общедоступный IP-адрес отображается в Robot.