Преместване на VPN сървър на нов публичен IP: какво да проверите първо
Подмяната на място и паралелното превключване се чупят на различни места. Проверете конфигурациите, NAT и сертификатите, после вижте как всеки клиент разрешава името.
Преназначаването на адрес отнема минута. Следващата седмица е мястото, където преместването се чупи, и рядко там, където подсказва конзолата на доставчика. Новият публичен IP се споменава на четири места: сокетът, на който слуша демонът, котвата на доверие, която клиентите проверяват, всяко правило, което назовава стария адрес, и DNS записът, който ги свързва. Две премествания изглеждат еднакви от контролния панел, но се държат съвсем различно: преназначаване на адреса на машината, която управлявате, или изграждане на втори endpoint и преместване на клиентите върху него. Проверките по-долу поставят евтините откази първи, а всеки раздел посочва за кое преместване се отнася.
Подмяната на място и паралелното превключване са различни задачи
Подмяната на място запазва хоста, ключовете, таблицата за маршрутизация и списъка с потребители; променя се само адресът. Това прави преназначаването на плаващ IP, и при няколко доставчика гостът не забелязва, защото транслацията се случва пред инстанцията. Преизграждане или преназначаване от доставчика е по-сурово: гостът вижда промяната и всичко, което е кеширало старата стойност, го научава в същия момент.
Паралелният endpoint е втори хост, който върши същата работа. Изградете го, тествайте го с един профил и оставете стария да отговаря, докато новият се докаже по реален път. Цената е състояние. Без споделени записи за peer, отменяния и логване имате две мрежи, които случайно споделят име.
| Question | In-place swap | Parallel endpoint |
|---|---|---|
| Rollback in one step? | Only if you can get the old address back | Point DNS back; old host still up |
| Blast radius | Every client at once | Only the clients you moved |
| Best when | The address is yours to reassign | The old address is gone for good |
Намерете всяко място, където е записан старият адрес
Започнете с текстово търсене, защото конфигурационните файлове са лесната половина. Търсете в конфигурацията на демона, фрагментите на защитната стена, целите за мониторинг и всеки генериран клиентски пакет на диска. Включете адреса IPv6, ако публикувате такъв; преместване, което следва само A записа, оставя клиентите с двоен стек на стария път.
OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpointsПосле прегледайте ядрото, защото работещата система държи адреса на места, които никой файл не споменава. Статично правило за NAT на източника, запис в ipset, адрес за свързване и запис в conntrack надживяват конфигурационната промяна, която ги е премахнала, а някои надживяват и рестарт, защото са се върнали от запазен набор от правила. Едно ниво по-горе, групите за сигурност на доставчика, целите на балансьора на натоварване и проверките за мониторинг изобщо не са във вашата файлова система.
Запишете инвентара, преди да промените нещо; той служи и като скрипт за връщане назад.
Клиентите с име на хост се възстановяват; клиентите с литерален IP замлъкват
Ако клиентите достигат сървъра по име на хост, превключването е предимно DNS проблем и TTL, който сте задали вчера, решава колко лошо ще стане. Resolver-ите кешират, stub resolver-ите кешират отново и много клиенти търсят името само при нова връзка, така че установен тунел запазва началния си адрес.
Ако endpoint е литерален адрес, нищо не се разрешава наново и нищо не записва оплакване. WireGuard пази разрешен адрес на сокет: Endpoint = vpn.example.net:51820 става IP в момента, в който се изпълни wg-quick up, и остава този IP, докато не го смените. OpenVPN е по-отстъпчив: разрешава името на хоста remote при свързване и с resolv-retry infinite опитва DNS отново при повторно свързване. При литерален IP и двете продължават да набират машина, която вече не съществува.
Това, което заблуждава хората, е огледалният образ. Клиент, вече насочен към новия адрес, докато старият слушател още отговаря, минава всеки тест, който правите от бюрото си. Бил съм заблуждаван така: новият endpoint се вдигна на телефон от първия опит, а клиент със стар профил се появи едва когато старият слушател беше изключен много по-късно.
Доверието не се мести с адреса
WireGuard разделя идентичността от достъпността, което прави преместването на адрес почти безплатно. Peer-ите се идентифицират с публичен ключ, а endpoint е само мястото, където пакетите отиват в момента; хостът обновява endpoint на peer от адреса на източника на последния удостоверен пакет. Бездеен peer все пак се нуждае от причина да говори с новото място и научава адреса само когато сесията му остарее и повторните опити за handshake се провалят на видимо място. Бързото ръководство на WireGuard покрива полето endpoint.
Сървърите на TLS са обратният случай. Сертификатът е вързан към име и клиент, който набира адрес, сравнява набраното с алтернативните имена на субекта. Свържете се по IP към сертификат, който носи само DNS SAN, и проверката се проваля: името, което клиентът е използвал, не е в сертификата. Преиздаване с IP SAN оправя тази една връзка и прави следващото преместване по-лошо. Запазването на име на хост в профила и оставянето на verify-x509-name на мястото му държи проверката строга, докато адресът под нея се променя.
После проверете към какво е вързан демонът; сокет, закрепен към стария адрес, се проваля тихо. OpenVPN сървър, стартиран с local 203.0.113.10, отказва да се вдигне, щом този адрес изчезне, докато слушател на 0.0.0.0 следва промяната безплатно. NAT се разделя по същия начин: MASQUERADE следва какъвто адрес има машината сега, а статичен SNAT --to-source 203.0.113.10 продължава да преписва към адрес, който вече не притежавате, така че връщащият трафик изчезва. Ако новият адрес идва с различен upstream шлюз, проверете rp_filter: филтрирането по обратен път изхвърля връщащ трафик, пристигащ на интерфейс, който ядрото не е очаквало.
Ред на превключването и доказателствата, че е проработило
Намалете TTL ден по-рано, вдигнете новия слушател и го докажете с профил, който само вие държите. Тест отвътре в същата мрежа не доказва почти нищо, затова използвайте телефон в мобилна мрежа и тествайте нещо, което тунелът трябва да пренася, а не ping към endpoint.
Наблюдавайте двата адреса през прозореца. wg show all latest-handshakes на новия хост или файлът за състояние на OpenVPN ви казва колко peer-а действително са се преместили. Когато новият endpoint има peer-ите, които очаквате, а старият има само изоставащи, изведете стария слушател от експлоатация, премахнете остарялото NAT правило и махнете адреса от защитната стена на доставчика. Премахването на стария слушател е стъпката, която се пропуска, и тя затваря процепа, в който стар профил все още достига старата мрежа.
Задайте тригера за връщане назад писмено преди да започнете: ако новият endpoint не получи handshake от нито един реален клиент след договорения прозорец, възстановете стария адрес и спрете раздаването на профили. После пуснете търсенето отново и потвърдете, че никой слушател не е вързан към изведен адрес. Две неща преминават към следващото преместване: име на хост в клиентския профил, за да е следващата промяна DNS редакция, и инвентарът, съхранен до бележките за възстановяване на сървъра.