Блокирајте еден OpenVPN клиент од LAN без да го запрете тунелот

Еден клиент на вашиот OpenVPN сервер мора да го загуби пристапот до LAN додека сите други тунели остануваат активни. Ако го побарате ова, најдобриот одговор обично вели дека демонот не може, што е само половина точно: OpenVPN нема firewall по клиент, но домаќинот што го завршува тунелот веќе филтрира пакети. Двете одлуки што се важни се идентитетот што го блокирате и позицијата на правилото. Направете ги правилно и промената станува една линија што можете да ја тестирате и отстраните.

Закачете го клиентот пред да го напишете правилото

OpenVPN изнајмува тунелски адреси од базен, така што 10.8.0.6 е место, а не личност. Кога сесијата завршува, закупот се враќа и може да му се даде на следното поврзување, што значи дека правило напишано против таа адреса го следи местото, а не корисникот. Затоа прво одлучете што навистина блокирате: адреса за краток експеримент или сертификат за некој што сакате да го држите надвор.

За да ја врзете адресата со сертификатот, создајте датотека во директориумот што го именува client-config-dir и дајте ѝ точно common name на сертификатот. Ставете една директива во неа, ifconfig-push 10.8.0.6 255.255.255.0, и тој клиент ја задржува истата тунелска адреса при повторни поврзувања. За да дејствува ова, мора да постојат две поставки: client-config-dir мора да биде деклариран во конфигурацијата на серверот, а адресата што се праќа мора да биде во подмрежа што серверот може да ја рутира. Ако недостига една, датотеката се игнорира без грешка, што го прави следниот тест на firewall доведен во заблуда.

Привремено блокирање може да користи адреса од базенот, доколку тикетот запишува која сесија ја држела во тој момент.

Редоследот одлучува дали отфрлањето ќе се изврши

На Linux портал што препраќа меѓу тунелот и LAN, пакетите ја поминуваат веригата FORWARD. Прочитајте ја командата подолу како реченица: вметнете на чело на FORWARD, совпаднато со сообраќај што влегува од tun0, од тој еден домаќин, упатен кон подмрежата на LAN, и отфрлете го.

iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP

-I е она што го пушта правилото. Додадено со -A, тоа паѓа под секое широко одобрување за тунелската подмрежа и никогаш не гледа пакет. Проверете ја позицијата со iptables -vnL FORWARD --line-numbers и прочитајте ги и бројачите: отфрлање на врвот што ништо не брои значи дека сообраќајот пристигнува по друг пат.

Сопствената LAN адреса на порталот е друг пат. Пакетите испратени до самата кутија одат во INPUT, не во FORWARD, така што клиентот може да загуби LAN домаќин и сепак да ја отвори административната страница на рутерот. Додајте го соодветното правило INPUT кога тоа е важно.

Што филтерот не може да види

Филтрирањето се случува кога пакетот се оценува, така што воспоставена TCP сесија може да продолжи додека не се затвори или ресетира. Ако блокирањето мора да дејствува веднаш, исчистете ги следените текови за тој извор со conntrack -D -s 10.8.0.6 откако правилото ќе влезе. Ако неколку секунди преклопување се прифатливи, запишете го тој избор наместо да го оставите имплицитен. Во секој случај, следната личност треба да знае дали правилото го запира живиот сообраќај или само новите врски.

Сообраќајот меѓу партнерите никогаш не го допира firewall-от на домаќинот. Кога client-to-client е овозможен, OpenVPN ги препраќа тие пакети внатре во демонот, така што ниту FORWARD ниту INPUT не ги гледа. Единствените решенија се исклучување на client-to-client или прифаќање дека партнерите можат да се достигнат; правило на iptables нема да го види тој сообраќај.

IPv6, firmware и преживување по рестартирање

Правилото IPv4 не кажува ништо за IPv6. Ако тунелот и LAN носат двете фамилии, еквивалентното правило мора да постои во ip6tables, или во множеството правила nftables што ја поседува политиката на тој домаќин. Firmware-от на рутерот често го крие netfilter зад сопствената апстракција, така што синтаксата и имињата на табелите копирани од форум може да не важат.

На OpenWrt, документираниот пат е запис во конфигурацијата на firewall, а не рачно напишана линија на iptables, и рачно напишаната линија може да исчезне кога firewall-от се вчитува повторно. Другите дистрибуции ги враќаат правилата преку netfilter-persistent, единица за подигање или продавничко складиште, и тие механизми не се заменливи. Докажете го избраниот со рестартирање, бидејќи повторното вчитување вежба друг пат.

Проверете по пат, потоа вратете чисто

Тестирајте го секој пат одделно, бидејќи една успешна проверка ги крие другите. Блокираниот клиент треба сепак да достигне интернет преку тунелот, но да не успее кон LAN домаќин, вториот клиент треба да го достигне истиот домаќин, а адресата на порталот и патот кон партнерот бараат секој свое набљудување. Запишете ги резултатите до правилото за да има следната промена основа. Табелата подолу е множеството што вреди да остане во тикетот.

Враќањето е бришење по спецификација, не flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP го отстранува точно тој запис и го остава остатокот од веригата недопрен. Отстранете ја истата линија од која било датотека што ги враќа правилата при подигање, вчитајте ја повторно и потврдете дека клиентот повторно го достигнува LAN домаќинот. Flush на FORWARD би ги поништил и правилата што не сте ги напишале, што враќањето го претвора во втор инцидент.

Пред да го затворите тикетот, потврдете три работи: закачената адреса се совпаѓа со сертификатот, правилото е над одобрувањата со бројач различен од нула, и датотеката за постојаност го содржи истото правило што сте го тестирале. Ако нешто од тоа недостасува, блокирањето е илузија во shell сесија.