Защо адресът на вашия VPN тунел не отваря входящ порт
Адресът на тунела идентифицира вашия клиент пред партньори, които могат да маршрутизират до него, и никога не създава слушател. Проверете свързването, обратния маршрут, после политиката.
Свържете се с офис VPN, стартирайте малка услуга на порт 8443, изпратете адреса на тунела на колега и наблюдавайте как връзката се проваля, докато клиентът все още съобщава, че е свързан. В тунела нищо не е счупено: адресът е раздаден, сесията е активна, а пакетите, които биха носили отговора, просто никога не се допускат. Изпълнете трите проверки по-долу по ред и спрете на тази, която се провали, защото всяка има различна поправка и само една от тях е за VPN.
Започнете от това къде всъщност е свързан сокетът
Преди нещо да бъде маршрутизирано, нещо трябва да слуша на адрес, до който извикващият може да достигне. Сървърите за разработка са обичайният виновник, защото много от тях по подразбиране се свързват към loopback и приемат само връзки, произхождащи от същата машина. Адресът на тунела не променя това свързване и операционната система ще откаже връзката много преди VPN да се включи.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Четете колоната с локалния адрес, а не състоянието. 127.0.0.1:8443 означава само loopback и поправката е свързване към 0.0.0.0 или към самия адрес на тунела. 0.0.0.0:8443 приема на всички интерфейси, което е по-широко, отколкото повечето хора имат предвид, когато машината има и публичен адрес; 10.64.7.15:8443 е тясната версия, която слуша само там, където колегата може да достигне. Отбележете и името на процеса в същия изход, защото заблуден екземпляр от по-ранен тест е обичайна причина портът да изглежда отворен и да отговаря с грешно съдържание.
После попитайте дали нещо може да маршрутизира до този адрес
Адресът на тунела има смисъл само за партньори, конфигурирани да изпращат този префикс в тунела. Машината на колегата има своя таблица и ако няма маршрут до подмрежата на тунела, пакетът отива към шлюза по подразбиране и умира на място, което няма представа, че адресът съществува. Това е въпрос на маршрутизация от страна на извикващия, не разрешение от ваша страна.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
Сървърът между двата клиента е също толкова важен. В обичайния дизайн за отдалечен достъп всеки клиент отваря изходяща връзка към шлюза и шлюзът поддържа състояние за тези потоци, така че отговорите се връщат по път, който той вече познава. Връзка от един клиент към друг е нов поток, който шлюзът трябва да приеме и препрати, а много внедрявания го изключват умишлено, за да държат клиентите изолирани един от друг. Потребителските VPN услуги обикновено изолират по подразбиране; корпоративните шлюзове понякога го разрешават за група.
Проверете посоката, преди да промените нещо на хоста. Ако адресът на тунела отговаря от самия шлюз, но не от партньор, разликата е настройката на шлюза за клиент към клиент и никакво редактиране на локалната защитна стена няма да я замести.
Накрая намерете политиката, която разрешава потока
Между маршрутизирания пакет и услугата, която отговаря, стоят три слоя политика: решението за препращане на VPN сървъра, защитната стена на хоста и всяка облачна група за сигурност пред инстанцията. И трите трябва да са съгласни и те се провалят по различен начин, затова симптомът в таблицата по-горе е по-полезен от съобщението за грешка в браузъра.
Защитната стена на хоста е слоят, който хората забравят след успешно свързване, защото правило, което разрешава порта на интерфейса LAN, не го разрешава автоматично на интерфейса на тунела. Правилата, ограничени до интерфейс, са правилен дизайн и също обичайната причина услуга да работи от офиса, а не от дома. Четете обхвата на правилото, а не номера на порта.
Филтрирането със състояние обяснява обратния случай. Изходяща връзка от вашия лаптоп създава състояние и отговорите към нея се допускат без входящо правило. Връзката на колегата е чисто нов поток без състояние зад себе си, затова се нуждае от изрично разрешение. Тази асиметрия е цялата причина работеща сесия в браузъра на вашата машина да не казва нищо за това дали услугата е достъпна отвън.
Когато една проверка се провали, променете дизайна, а не тунела
Ако изискването е колега да отвори вашата локална услуга, честният отговор обикновено е механизъм, изграден за входящ достъп. Обратен SSH тунел е най-малкият: вашата машина се свързва навън към хост, до който колегата вече има достъп, и слушателят съществува на този хост.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Ретранслаторът се нуждае от GatewayPorts clientspecified в конфигурацията на SSH сървъра си, иначе препратеният слушател се свързва към loopback на ретранслатора и колегата получава същия отказ като преди. За всичко, което живее по-дълго от следобед, балансьор на натоварването или ingress с проверка на състоянието и сертификат за публикуваното име е по-добрият инструмент, а тунел между сайтове с маршрути за двете подмрежи е правилният отговор, когато две мрежи наистина трябва да говорят.
Всеки от тези дизайни прави експозицията явна и това е смисълът. VPN пренася пакети между мрежи, които вече ви е разрешено да използвате; той не публикува услуга и не превръща лаптопа в хост, обърнат към интернет. Задачата е да решите кой от трите слоя да промените, а тунелът рядко е един от тях.