Далечински SSH преку VPN: што тунелот не прави

VPN му дава на SSH серверот приватен пат и ја отстранува потребата од јавен слушател на портата 22. Тој не го автентицира домаќинот, не го авторизира корисникот и не одлучува кои сметки можат да се најават. Тоа останува работа на SSH. Дали VPN е вистинскиот начин да се стигне до серверот зависи од три услови, а тунелот е само еден од можните одговори.

Што менува тунелот и што SSH сѐ уште одлучува

Тунелот ја менува достапноста: кои адреси можат да се достигнат и од каде. Тој не го менува она што се случува откако TCP врската ќе пристигне, каде серверот претставува клуч на домаќин и бара идентитет на корисник.

Држете ги двата слоја одделно во главата и во документацијата. Најавувањето на VPN докажува кој може да ја користи мрежата. Тоа не кажува ништо за тоа кои сметки постојат на целта и не е дозвола да се најавите на секоја достапна машина.

И режимите на неуспех се одделни, и токму тоа ја прави поделбата корисна за време на инцидент.

Три услови што го одредуваат моделот на пристап

Прво, дали серверот треба да биде достапен за луѓе надвор од вашата мрежа? Ако не, приватен пат плус бастион или мрежа е помалиот дизајн. Второ, дали клиентската популација навистина може да го изврши VPN клиентот, вклучително и оние на управувани уреди со ограничувања?

Трето, дали ви е потребна контрола по услуга или контрола по корисник? VPN дава мрежен дофат; SSH дава пристап до сметка. Ако барањето е изведувачот да достигне еден домаќин и ништо друго, тоа е барање за авторизација и само тунелот не може да го изрази.

Одговорете на тие три и моделот се избира сам. Прескокнете ги и на крајот ќе го изложите SSH јавно за да го избегнете распоредувањето на клиентот.

Потврдете го приватниот пат пред да го обвините SSH

Поврзете се на одобрениот VPN и користете го документираното приватно име или адреса на целта. Потоа проверете ја избраната рута, дозволата на портата и повратниот пат до клиентот. Името што се решава правилно не е доказ дека адресата го зема предвидениот тунел, бидејќи преклопувачките локални и далечински префикси можат да го испратат барањето сосема на друго место. Таа разлика вреди да се запише во runbook.

Ако врската никогаш не пристигне, потврдете дека серверот слуша на интерфејсот што го очекувате и дека неговиот домаќински firewall го дозволува изворот што тој навистина го гледа. NAT на портата може да го препише тој извор, така што списокот со дозволи напишан за тунелската адреса на клиентот може никогаш да не се совпадне.

Тоа несовпаѓање е најчестиот самонанесен SSH неуспех преку VPN.

Читајте ја фазата на неуспех, не комбинираната грешка

Три фази произведуваат три различни пораки, и само една од нив е за акредитиви.

Користете ја точната грешка и сопствениот лог на серверот наместо истовремено ресетирање на VPN и SSH акредитивите. Ресетирањето на двете е начинот на кој петминутна дијагноза станува дводневен инцидент со идентитет.

Деталниот излез покажува до која фаза стигнавте:

ssh -vv [email protected]

Зачувајте ги клучевите на домаќинот и авторизацијата

Валидирајте го клучот на домаќинот преку предвидениот доверлив процес, особено по замена на серверот. Неочекувано предупредување за променет клуч е единствената порака што не треба да ја отфрлите само затоа што VPN се поврза, бидејќи приватен тунел не ја прави дестинацијата машината што ја мислите. Проверете го отпечатокот против извор на кој му верувате независно од врската.

Од страната на серверот, потврдете дека сметката е авторизирана и дека методот на автентикација што сте го конфигурирале е оној што се нуди. Клучот што е присутен но се игнорира обично е проблем со дозволи или конфигурација, а не со мрежата.

Ограничете го пристапот до услугите на потребните идентитети и задржете авторизиран пат за обновување за мрежните промени.