VPN порта на Raspberry Pi: една мрежна карта или посебен клиентски порт
Еден порт на Pi може да опслужува избрани клиенти, или втор порт може да ги затвори уредите внатре. Изберете распоред според изолацијата, политиката при пад и тоа чиј е DNS.
Имате едно Pi, еден работен излезен VPN профил и два уреда што треба да стигнат до интернет преку него. Прашањето што ја решава целата поставка не е кое упатство да се следи, туку колку изолација ви треба. Еден порт му дозволува на Pi да стои покрај тие уреди на LAN-от на рутерот и да дејствува како дополнителна порта; втор порт ви дозволува да ги ставите во сегмент каде Pi е единствениот излез. Сѐ по тој избор — DHCP, обемот на огнениот ѕид, DNS, случајот со прекин — произлегува од него.
Во што всушност се разликуваат двете поставки
Двете поставки рутираат. Разликата е кој друг стои на кабелот и што се случува кога политиката ви е погрешна.
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
Изолацијата е вистинската оска. Поставката A е советодавна: уред што ја игнорира портата дадена од DHCP и го избира рутерот сѐ уште работи, но без шифрирање. Поставката B се наметнува со топологија, зашто нема друг следен чекор што може да се избере.
Поставка A: Pi како дополнителна порта на постоечкиот LAN
Да претпоставиме дека рутерот на ISP е 192.168.50.1, Pi е 192.168.50.2, а избраните клиенти покажуваат кон Pi. Важно е што два различни текови на пакети делат еден кабел. Внатрешниот пакет на клиентот пристигнува во Pi и мора да излезе низ тунелот; сопствениот шифриран пакет на Pi кон VPN партнерот мора да излезе низ истиот кабел кон рутерот. Тие патуваат во спротивни насоки по истиот интерфејс и бараат различен третман.
Дајте му ја адресата на Pi преку инсталираниот мрежен менаџер, а не преку стар рецепт со датотека за интерфејс што се бори со него за уредот. Потоа поставете ги клиентите: статична порта на еден уред или DHCP резервација што дава 192.168.50.2 како рутер. Не менувајте го целиот DHCP опсег на рутерот поради два уреда и не претпоставувајте дека клиентот ја почитува опцијата — проверете го тоа.
Слабоста е структурна, а не поправлива. Секој клиент во тој сегмент може да покаже кон 192.168.50.1 и да излезе без шифрирање, а уред со втор интерфејс или мобилно радио целосно ја напушта вашата патека на спроведување. Ако таа реченица е неприфатлива за конкретниот уред, одговорот веќе го имате: користете ја поставката B.
Поставка B: посебен порт ги затвора уредите внатре
Овде Pi ја задржува 192.168.50.2 на нагорната врска со порта 192.168.50.1 и на вториот интерфејс зема 10.20.0.1/24 за поврзаните уреди. Сега Pi е рутер со две мрежи, а поврзаниот сегмент има точно еден излез.
Проверете го опсегот наспроти сѐ друго пред да се обврзете: сопствената подмрежа на тунелот, други префикси меѓу локации и сѐ што е достапно преку VPN. 10.20.0.0/24 што се судира со оддалечен LAN го дава тој полуработен резултат чија диагностика трае цела вечер. Ако вториот порт е USB адаптер, потврдете дека е поддржан и закачете го неговото име во мрежниот менаџер за да не ја помести вашата LAN адреса прередувањето по рестарт.
Стартувајте го DHCP слушателот само на тој интерфејс. Сервер што одговара на нагорната врска се натпреварува со рутерот на ISP и ги дава адресите на вашиот сегмент на остатокот од домот. Врзете го за LAN интерфејсот, ограничете го на објавениот опсег и држете ја сопствената адреса на Pi надвор од базенот.
Проследување, превод и правилото за затворање при дефект
Четири работи често се опишуваат како една и не се. Вклучувањето на проследувањето (net.ipv4.ip_forward=1) само му кажува на јадрото дека смее да преместува пакети меѓу интерфејси; само по себе не дозволува ништо и не гарантира никаква патека. Изборот на излезот е одлука за рутирање. Дозволувањето на пакетот е одлука за политика во forward синџирот. Препишувањето на неговиот извор е одлука за postrouting. Поставка што го прави само првото дава Pi што весело проследува клиентски сообраќај надвор по нагорната врска.
Ограничете ја дозволата на изворите што ги мислевте и на интерфејсот што сообраќајот треба да го користи, и вклучете го повратниот пат и сопствените потребни одредишта на Pi. Потоа преведувајте на излезот на тунелот ако давателот не го рутира вашиот LAN префикс назад кон вас. прирачникот за nftables ги третира проследувањето, локалниот излез и преводот на изворот како одделни операции, што е вистинскиот мисловен модел овде.
Вообичаениот дефект е широко masquerade правило на физичкиот интерфејс. Тогаш сообраќајот стигнува до интернет по патеката на ISP, додека од страната на клиентот изгледа точно како работен VPN. Тоа не докажува ништо. Држете го преводот врзан за објавениот излез и држете ги правилата во огнениот ѕид што домаќинот веќе го користи, наместо да додадете конкурентен сет правила што испразнува заеднички postrouting синџир.
Потоа справете се со отсуството на тунелот. Клиентски профил што инсталира широк стандарден маршрут исто така значи дека кога тунелот ќе падне, обичниот стандарден може да се врати и клиентскиот сообраќај тивко се враќа на нагорната врска. Онаму каде враќањето на отворен текст не е прифатливо, forward политиката мора експлицитно да го одбие сообраќајот од клиент кон нагорната врска, во состојбата кога VPN маршрутот го нема. Напишете го тоа како правило за одбивање, не како претпоставка. Сопствениот шифриран транспорт на Pi кон VPN партнерот е одделен local-output тек и мора да остане дозволен, инаку тунелот никогаш не може да се врати.
DNS и IPv6 бараат свој одговор
Ако клиентите го користат Pi како резолвер, тие стигнуваат до локален слушател и Pi започнува ново барање. Тоа нагорно барање ја следи сопствената патека на Pi, а не forward правилото што го напишавте за клиентите, затоа клиентска патека само низ тунелот плус резолвер што излегува директно е истекување без никаква порака за грешка. Одлучете свесно: резолвер достапен низ тунелот, или локален што го прифаќате како директен, и усогласете ја сопствената излезна политика на Pi со таа одлука.
IPv6 е повторно посебен случај. Forward правило за IPv4 не ограничува ништо во врска со IPv6, а објавите на рутерот на нагорната врска можат да му дадат на Pi, и преку него на поврзаниот сегмент, втор стандарден маршрут што ја заобиколува вашата политика. Или дајте му на IPv6 сопствена заштитена патека по истиот принцип, или експлицитно ограничете го на клиентскиот сегмент и кажете го тоа.
Тестирајте ја границата пред да ѝ верувате
Прифатете ја поставката само по четири одделни проверки, зашто примамливиот единечен тест — отворање прелистувач на еден клиент — поминува во неколку скршени состојби.
Потврдете дека еден вистински клиент стигнува до интернет низ тунелот, потоа потврдете дека истиот клиент не може да стигне до интернет кога тунелот е паднат. Потврдете дека DNS резолуцијата работи и дека барањето излегува каде што мислевте. Потврдете дека сопствениот транспорт на Pi сѐ уште работи по рестартирање на тунелот и дека закрепнувањето не бара рестартирање на машината. На крајот проверете уред што не сте го избрале: во поставката A треба да продолжи нормално да работи, а во поставката B не треба воопшто да постои во тој сегмент.
- Два порта и правило за одбивање даваат спроведување; еден порт и DHCP опција даваат совет.
- Преводот на погрешниот интерфејс изгледа како успех и не е.
- Сопствениот сообраќај на Pi, DNS и IPv6 секој бара одлука, не заклучок.