Блокирати једног OpenVPN клијента из LAN-а без заустављања тунела
Причврстите тунелску адресу клијента на његов сертификат, одбаците његов LAN саобраћај на челу FORWARD, затим проверите IPv6, праћене сесије и преживљавање након поновног покретања.
Један клијент на вашем OpenVPN серверу мора да изгуби приступ LAN-у док сви остали тунели остају активни. Ако то потражите, најбољи одговор обично каже да демон то не може, што је само пола истине: OpenVPN нема заштитни зид по клијенту, али домаћин који завршава тунел већ филтрира пакете. Две одлуке које су важне су идентитет који блокирате и позиција правила. Урадите их исправно и промена постаје један ред који можете тестирати и уклонити.
Причврстите клијента пре него што напишете правило
OpenVPN изнајмљује тунелске адресе из базена, па је 10.8.0.6 место, а не особа. Када сесија заврши, закуп се враћа и може се дати следећој вези, што значи да правило написано против те адресе прати место, а не корисника. Зато прво одлучите шта заиста блокирате: адресу за кратак експеримент или сертификат за некога кога желите да држите напољу.
Да бисте адресу везали за сертификат, направите датотеку у директоријуму који именује client-config-dir и дајте јој тачно common name сертификата. Ставите у њу једну директиву, ifconfig-push 10.8.0.6 255.255.255.0, и тај клијент задржава исту тунелску адресу при поновним повезивањима. Морају постојати две поставке да би то деловало: client-config-dir мора бити декларисан у конфигурацији сервера, а адреса која се шаље мора бити у подмрежи коју сервер може да рутира. Ако једна недостаје, датотека се игнорише без грешке, што следећи тест заштитног зида чини обмањујућим.
Привремена блокада може користити адресу из базена, докле год тикет бележи која је сесија тада држала ту адресу.
Редослед одлучује да ли ће одбацивање бити извршено
На 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 након што правило уђе. Ако је неколико секунди преклапања прихватљиво, запишите тај избор уместо да га оставите имплицитним. У сваком случају, следећа особа мора да зна да ли правило зауставља живи саобраћај или само нове везе.
Саобраћај између партнера никада не дотиче заштитни зид домаћина. Када је client-to-client омогућен, OpenVPN прослеђује те пакете унутар демона, па их ни FORWARD ни INPUT не виде. Једина решења су искључивање client-to-client или прихватање да партнери могу да достигну једни друге; правило iptables неће видети тај саобраћај.
IPv6, фирмвер и преживљавање након поновног покретања
Правило IPv4 не говори ништа о IPv6. Ако тунел и LAN носе обе фамилије, еквивалентно правило мора постојати у ip6tables, или у скупу правила nftables који поседује политику на том домаћину. Фирмвер рутера често крије netfilter иза сопствене апстракције, па се синтакса и имена табела копирани са форума можда неће применити.
На OpenWrt-у је документовани пут запис конфигурације заштитног зида, а не ручно написана линија iptables, и ручно написана линија може нестати када се заштитни зид поново учита. Друге дистрибуције враћају правила преко netfilter-persistent, јединице за подизање или складишта произвођача, и ти механизми нису заменљиви. Докажите изабрани поновним покретањем, јер поновно учитавање вежба други пут.
Проверите по путу, затим се чисто вратите
Тестирајте сваки пут засебно, јер једна успешна провера крије остале. Блокирани клијент треба и даље да достигне интернет кроз тунел, али да не успе против LAN домаћина, други клијент треба да достигне исти домаћин, а адреса пролаза и пут ка партнеру захтевају сваки своје посматрање. Запишите резултате поред правила да би следећа промена имала основу. Табела испод је скуп који вреди задржати у тикету.
| Пут | Очекивано са правилом | Када не успе |
|---|---|---|
| Блокиран клијент ка LAN домаћину | Нема одговора | Правило је испод одобрења, или извор се не подудара |
| Блокиран клијент ка интернету | Ради кроз tun0 | Правило је прешироко, без подударања одредишта |
| Други клијент ка истом LAN домаћину | Ради | Правило се подударило са више од предвиђеног домаћина |
| Блокиран клијент ка LAN адреси пролаза | Блокирано само са одговарајућим правилом INPUT | Недостаје правило INPUT |
| Блокиран клијент ка тунелској адреси партнера | Још увек ради | client-to-client је омогућен и изван домета заштитног зида |
Враћање је брисање по спецификацији, а не flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP уклања тачно тај запис и оставља остатак ланца нетакнут. Уклоните исти ред из датотеке која враћа правила при подизању, поново је учитајте и потврдите да клијент поново достиже LAN домаћина. Flush FORWARD би поништио и правила која нисте написали, што враћање претвара у други инцидент.
Пре затварања тикета потврдите три ствари: причвршћена адреса се подудара са сертификатом, правило је изнад одобрења са бројачем различитим од нуле, и датотека постојаности садржи исто правило које сте тестирали. Ако нешто од тога недостаје, блокада је илузија у shell сесији.