Кой адрес се записва в DNS за сървър, свързан през VPN?
Хостван сървър държи три адреса и те не са взаимозаменяеми. Изберете стойността, която всяка услуга изисква, и след това я потвърдете отвън машината.
Хостван сървър с инсталиран VPN в крайна сметка държи три адреса и само един от тях принадлежи на всяко място, което ще конфигурирате. Копирането на номера от панела на доставчика в DNS, в слушател или в списък с разрешения е начинът, по който работещ тунел се превръща в услуга, до която никой не може да стигне. Това ръководство подрежда работата така, че всеки адрес да бъде избран за заявена цел. То също изброява командите, които потвърждават какво всъщност сте публикували.
Нанесете трите адреса на карта, преди да публикувате каквото и да е
Наречете ги по функция. Адресът underlay е това, което машината използва, за да достигне крайната точка на VPN през интернет, и често е частен зад NAT на доставчика. Адресът на тунела живее вътре във VPN и се дава от сървъра или от клиента в зависимост от продукта. Публичният изход е адресът, който отдалечен сайт записва след превода, и не е нужно да съществува на нито един интерфейс, който можете да запитате.
Панел, който показва един публичен адрес за машина, ви казва много малко за другите две роли. Достижимостта на underlay е изискване, а не покупка: лаптоп зад домашен маршрутизатор може да достигне хоствана крайна точка на VPN, без да притежава публичен адрес IPv4. Това, което не можете, е да измислите входящ път, като напишете име, което се разрешава до адрес, който никой не препраща.
Изберете адреса според услугата, а не според етикета
Запишете какво трябва да прави сървърът, преди да изберете номер. Изходящите API извиквания се нуждаят от стабилен изход, когато другата страна поддържа списък с разрешения. Частният достъп се нуждае от адрес на тунела, към който клиентите могат да маршрутизират, и слушател, обвързан с него. Публичното хостване се нуждае от входящо съпоставяне, което доставчикът наистина предлага, и само адресът на изхода не го осигурява.
Една машина може да обслужва и трите цели и въпреки това да използва три различни адреса. Това, което се чупи, е предположението, че една стойност покрива всички тях:
| Requirement | Value that belongs there | What you see when the roles are swapped |
|---|---|---|
| Outbound allowlisting | Public exit | Requests reach the service but are rejected |
| Private client access | Tunnel address | Client connects, nothing answers |
| Inbound web service | Provider mapping | Name resolves, connection times out |
Входящият ред е този, за който хората спорят. Запис, който сочи към адреса на изхода, не създава слушател, отваряне на защитна стена или съпоставяне на порт, и чакането не променя това. Когато доставчикът продава отделен адрес заедно с входящо правило, този пакет е възможността, която сте купили; адресът сам по себе си не е право.
Команди, които показват кой адрес кой е
Четете машината, а не панела. Имената на интерфейсите се различават между системите, затова свързвайте адресите с устройствата, вместо да се доверявате на етикет.
Първият ред изброява всеки адрес IPv4 и неговото устройство, а вторият пита ядрото кое устройство би използвало за известно външно местоназначение:
ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'Ако търсенето на маршрут отговаря с устройство на тунел за публичен трафик, пълният ви тунел е в сила. Проверката на слушателя е също толкова важна, защото процес, обвързан само с 127.0.0.1, никога няма да отговори на адреса на тунела, каквото и име да публикувате.
Публикувайте го, след което проверете отвън
Публикувайте стойността, от която услугата се нуждае, и нищо повече: запис A или AAAA за хостване, запис в списъка с разрешения за изходящи извиквания, клиентски профил за частен достъп. След това тествайте от позицията, която има значение, и това никога не е машината, която току-що редактирахте.
Две проверки покриват по-голямата част и двете са достатъчно евтини, за да останат в скрипт:
dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/healthDNS отговор, който доказва, че записът ви съществува, не е доказателство, че заявка пристига, а една успешна заявка доказва само, че един път работи от една мрежа. Повторете проверката през мобилна връзка, когато има списък с разрешения, защото наблюдаваният изход може да зависи от семейството адреси и избрания маршрут. Отбележете кое семейство сте проверили; работещ път IPv4 не казва абсолютно нищо за IPv6.
Ако услугата е входяща, адресът на изхода не е достатъчен
Входящият достъп се нуждае от четири неща в една линия: име или адрес, до който клиент може да стигне, маршрут, който доставя пакета до машината, слушател, който го приема, и политика, която не го изхвърля. VPN променя втория елемент и понякога първия, а за третия и четвъртия не прави нищо. Когато тунелът е пътят за доставка, клиентите се свързват с адреса на тунела, а не с изхода.
Запишете от кой адрес зависи всяка услуга и преглеждайте този запис всеки път, когато доставчикът промени модела си на маршрутизация. Сървър, който отговаря частно и се проваля публично, обикновено не е повреден; той отговаря под грешна идентичност и поправката е решение за съпоставяне, а не промяна на защитната стена.