Преместување на 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, bind адреса и запис во conntrack го надживуваат конфигурациското менување што ги отстранило, а некои го надживуваат и рестартот бидејќи се вратиле од зачуван сет правила. Едно ниво погоре, безбедносните групи на давателот, целите на балансерот на оптоварување и проверките за мониторинг воопшто не се на вашиот датотечен систем.
Запишете го инвентарот пред да промените нешто; тој служи и како скрипта за враќање.
Клиентите со име на домаќин се возобновуваат; клиентите со буквална IP замолчуваат
Ако клиентите стигнуваат до серверот преку име на домаќин, префрлањето е претежно DNS проблем, и TTL-от што го поставивте вчера одлучува колку лошо ќе биде. Решавачите кешираат, stub решавачите кешираат повторно, и многу клиенти го бараат името само на нова врска, така што воспоставен тунел ја задржува почетната адреса.
Ако endpoint е буквална адреса, ништо не се решава повторно и ништо не запишува жалба. WireGuard чува решена адреса на сокет: Endpoint = vpn.example.net:51820 станува IP во моментот кога се извршува wg-quick up и останува таа IP додека не ја смените. OpenVPN е попопустлив: го решава името на домаќин remote при поврзување и, со resolv-retry infinite, повторно обидува DNS при повторно поврзување. Со буквална IP, двете продолжуваат да ѕвонат на машина што повеќе не постои.
Она што ги збунува луѓето е огледалната слика. Клиент веќе насочен кон новата адреса, додека стариот слушател сѐ уште одговара, поминува секој тест што го правите од своето биро. И мене ме измамиле така: новиот endpoint се крена на телефон од прв обид, а клиент со застарена конфигурација се појави дури кога стариот слушател беше исклучен многу подоцна.
Довербата не се преместува со адресата
WireGuard го одделува идентитетот од достапноста, што го прави преместувањето на адреса речиси бесплатно. Peers се идентификуваат со јавен клуч, а 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, ви кажува колку peers навистина се преместиле. Кога новиот endpoint ги има очекуваните peers, а стариот ги има само заостанатите, повлечете го стариот слушател, отстранете го застареното NAT правило и извадете ја адресата од огнениот ѕид на давателот. Отстранувањето на стариот слушател е чекорот што се прескокнува, и тој ја затвора пукнатината каде застарена конфигурација сѐ уште стигнува до старата мрежа.
Пред да започнете, писмено определете го тригерот за враќање: ако по договорениот прозорец новиот endpoint не добие handshake од ниту еден вистински клиент, вратете ја старата адреса и престанете да делите профили. Потоа повторно пуштете го пребарувањето и потврдете дека ниту еден слушател не е врзан за повлечена адреса. Две работи преминуваат во следното преместување: име на домаќин во клиентскиот профил за следната промена да биде DNS уредување, и инвентарот чуван до белешките за возобновување на серверот.