మార్క్ ఆధారిత VPN ఫైర్వాల్ బ్లాక్ చేసిన libvirt అతిథి DNSని పరిష్కరించడం

డిఫాల్ట్ libvirt నెట్వర్క్లోని అతిథులు WireGuard ఇంటర్ఫేస్ వచ్చే వరకు పేర్లను పరిపూర్ణంగా పరిష్కరిస్తారు, ఆ తర్వాత ప్రతి శోధన అదే చోట ఆగిపోతుంది. dnsmasq ఇంకా 192.168.122.1:53 లో వినిపిస్తోంది, అతిథి ఇంకా ఆ చిరునామానే పరిష్కర్తగా కలిగి ఉంది, ప్రశ్న ఇంకా వస్తూనే ఉంది. మారినది ఏమిటంటే, హోస్ట్ యొక్క స్వంత ఎగువ ప్రశ్న, లేదా దానికి వచ్చే ప్రతిస్పందన, ఇప్పుడు మీరు సవరించాలని అనుకునే ఏ ఫిల్టర్ చైన్ కంటే ముందే మూల్యాంకనం చేయబడే నియమం ద్వారా పడవేయబడుతోంది. బయటపడే మార్గం తగినంత ముందుగా వేయబడిన మార్క్, ప్రతిస్పందన వారసత్వంగా పొందే కనెక్షన్పై.

టన్నెల్ లేచిన క్షణమే అతిథులకు DNS పోతుంది

ఏదైనా మార్చే ముందు ఆకృతిని నిర్ధారించండి. టన్నెల్ దింపండి, అతిథి నుండి dig @192.168.122.1 example.com ను అమలు చేసి అది సమాధానం ఇస్తున్నట్లు చూడండి. టన్నెల్ ఎక్కించండి, పునరావృతం చేయండి, అది సమయం మించిపోతున్నట్లు చూడండి. ఆ రెండు ఫలితాలు పాడైన libvirt నెట్వర్క్, తప్పు పరిష్కర్త చిరునామా, చనిపోయిన dnsmasq లను ఒకే అడుగులో తీసివేస్తాయి.

తర్వాత హోస్ట్ వైపు చూడండి. dnsmasq ప్రశ్నను, దాని ఎగువ ఫార్వార్డింగ్ను లాగ్ చేస్తే, ప్యాకెట్ చేరింది మరియు వైఫల్యం బయటకు పంపే వైపున ఉంది. dnsmasq ఏమీ లాగ్ చేయకపోతే, అతిథి ప్రశ్న లోపలికి వచ్చే వైపునే పడవేయబడుతోంది, మినహాయింపు ఈ వ్యాసం గుర్తించే హుక్ కంటే వేరే హుక్పై ఉండాలి.

తర్వాతి చైన్లోని accept నియమం ఎందుకు ఎప్పటికీ రాదు

మార్క్ ఆధారిత VPN ఫైర్వాల్ మీ మూల చిరునామాను కాకుండా ప్యాకెట్ మార్క్ లేదా కనెక్షన్ మార్క్ను చూసి నిర్ణయించుకుంటుంది. భౌతిక ఇంటర్ఫేస్పై ఆశించిన మార్క్ లేకుండా వచ్చేది ఏదైనా తిరస్కరించబడుతుంది, ఆ తిరస్కరణ మార్క్ పరీక్షను కలిగి ఉన్న నియమ సమితిలో జరుగుతుంది. ip saddr 192.168.122.0/24 accept పంక్తిని తర్వాతి ఏ చైన్కైనా జోడించినా ఆ ప్యాకెట్ కోసం అది ఎప్పటికీ పరిగణించబడదు, అందుకే స్పష్టంగా కనిపించే నియమం సరిగ్గా ఉన్నట్లు అనిపిస్తుంది కానీ ఏమీ మార్చదు.

ఏదో పనిచేసే వరకు దాన్ని విస్తరించడం రెండవ ఉచ్చు. హోస్ట్ యొక్క input మార్గంలో మొత్తం libvirt సబ్నెట్ను అంగీకరించడం అతిథులకు హోస్ట్ యొక్క ప్రతి సేవను తెరుస్తుంది, అసలు అవసరం ఒకే పోర్టు అయినప్పుడు.

ఇరుకైన మినహాయింపును సాధ్యం చేసే యంత్రాంగం కనెక్షన్ ట్రాకింగ్. మీరు ప్యాకెట్పై ct mark సెట్ చేసినప్పుడు, విలువ ప్యాకెట్పై మాత్రమే కాకుండా conntrack ఎంట్రీపై నిల్వ చేయబడుతుంది, కాబట్టి ఆ కనెక్షన్లోని ప్రతి ప్యాకెట్ తర్వాత దాన్ని మోస్తుంది, హోస్ట్ నుండి అతిథి వైపు తిరిగి వెళ్లే ప్రతిస్పందనతో సహా. అదే మొత్తం ఉపాయం: అభ్యర్థనను ఒకసారి గుర్తించండి, తిరిగి వెళ్లే మార్గం ఇప్పటికే గుర్తించబడి ఉంటుంది.

VPN పట్టిక చూసే ముందే ప్రశ్నను గుర్తించండి

తర్వాతి పాఠకుడు VPN నియమాలను విశ్లేషించకుండా కనుగొనగలిగేలా మినహాయింపును దాని స్వంత పట్టికలో ఉంచండి:

table inet allowedLocal {
  chain guest_dns {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
      th dport 53 ct mark set 0x00000f41
  }
}

priority mangle ఋణాత్మకం, ఇది ఈ చైన్ను VPN ప్యాకేజీ సున్నా ప్రాధాన్యతలో ఇన్స్టాల్ చేసే సాధారణ ఫిల్టర్ చైన్లకు ముందు ఉంచుతుంది. హుక్ క్రమమే నియమాన్ని ప్రభావవంతం చేస్తుంది; VPN చైన్ తర్వాత వచ్చే చైన్లో అదే నియమం కేవలం అలంకారం.

మార్క్ సంఖ్య స్వయంగా అన్నిచోట్లా వర్తించదు. ఇన్స్టాల్ చేసిన VPN నియమాలు తమ సొంత ట్రాఫిక్ కోసం అంగీకరించే విలువను తీసుకోండి, దాన్ని నడుస్తున్న నియమ సమితి నుండి చదవండి, అదే ఉపయోగించండి. తప్పు మార్క్ శుభ్రంగా లోడ్ అయ్యే, ప్రతి ప్రశ్నతో సరిపోలే, ఏదీ లోపలికి పంపని నియమాన్ని సృష్టిస్తుంది.

రంధ్రాన్ని పోర్టు 53 వెడల్పుతోనే ఉంచండి

రాసినట్లుగా, ఇది libvirt సబ్నెట్ నుండి హోస్ట్కు TCP లేదా UDP పోర్టు 53 ద్వారా DNSని అనుమతిస్తుంది, మరేమీ కాదు. ఇది అతిథులను టన్నెల్ వెలుపల ఇంటర్నెట్కు చేరనివ్వదు, హోస్ట్ అతిథుల వైపు కనెక్షన్లు తెరవనివ్వదు. తర్వాత అతిథికి మరో హోస్ట్ సేవ అవసరమైతే, ఈ నియమాన్ని సడలించడం కాకుండా ఆ గమ్యస్థాన పోర్టును పేర్కొనే ప్రత్యేక నియమాన్ని జోడించండి.

మీరు ఏమి మారుస్తున్నారో దానిపై నిజాయితీగా ఉండండి. పరిష్కర్తను చేరగల అతిథి DNS ప్రశ్నల ద్వారా ఏకపక్ష డేటాను కూడా టన్నెల్ చేయగలడు, ఈ మినహాయింపు VPN సరిహద్దులో ఉద్దేశపూర్వకంగా పెట్టిన రంధ్రం, స్థానిక నెట్వర్క్ విశ్వసనీయం అనే ప్రకటన కాదు. మూలాన్ని 192.168.122.0/24 వరకు పరిమితం చేయడం ఆ రంధ్రాన్ని మిగతా ప్రతి స్థానిక సబ్నెట్ నుండి దూరంగా ఉంచుతుంది, ముప్పు మీకు ముఖ్యమైతే ఆ మూలంపై ప్రశ్నలను లెక్కించడం చవకైనది.

పునఃప్రారంభం తర్వాత కూడా నిలిచేలా చేయండి, రెండు భాగాలను నిరూపించండి

shell ప్రాంప్ట్లో టైప్ చేసిన నియమం తదుపరి బూట్లో అదృశ్యమవుతుంది, VPN ఇంటర్ఫేస్ ఇప్పటికే ట్రాఫిక్ పంపుతున్న తర్వాత లోడ్ అయ్యే నియమం మొదటి కనెక్షన్లోనే పరుగును ఓడిపోతుంది. పట్టికను హోస్ట్ యొక్క శాశ్వత nftables కాన్ఫిగరేషన్లో ఉంచండి, లేదా VPN సేవకు ముందు క్రమంలో ఉన్న యూనిట్లో ఉంచండి, క్రమాన్ని ఊహించకుండా తనిఖీ చేయండి.

ధృవీకరణకు మూడు వేర్వేరు సమాధానాలు కావాలి. చైన్ లోడ్ అయి మొదట క్రమబద్ధీకరించబడినట్లు నిర్ధారించండి, conntrack ఎంట్రీ రెండు దిశల్లో మార్క్ చూపుతున్నట్లు నిర్ధారించండి, అతిథి శోధన చిరునామాను తిరిగి ఇస్తున్నట్లు నిర్ధారించండి. తర్వాత రెండో సగాన్ని నిర్ధారించండి: టన్నెల్ దిగినప్పుడు లేదా బ్లాక్ చేస్తున్నప్పుడు పబ్లిక్ హోస్ట్కు సాధారణ అతిథి వెబ్ ట్రాఫిక్ ఇప్పటికీ విఫలమవుతుంది. DNS పనిచేసి మిగతావన్నీ లీక్ అయితే, మీ నియమం పైన ఉన్న దాని కంటే విస్తృతం.

మార్క్ పెట్టిన తర్వాత కూడా శోధనలు విఫలమవుతుంటే, మూలాన్ని విస్తరించాలనే కోరికను అణచుకోండి. dnsmasq ఎక్కడికి పంపుతుంది, అతిథి పరిష్కర్త 192.168.122.1 వైపు చూపుతోందా లేదా ఎవరో టైప్ చేసిన పబ్లిక్ చిరునామా వైపు, ప్రశ్న హోస్ట్ను చేరుతోందా అని తనిఖీ చేయండి. గుర్తించడం ప్యాకెట్ను లోపలికి పంపుతుంది, మరేమీ కాదు, కాబట్టి చెడ్డ ఎగువ మార్గం లేదా పాడైన వర్చువల్ నెట్వర్క్ ఎన్ని నియమాలు జోడించినా పాడైనట్లే ఉంటుంది.